EVIDIQ Notary: Cryptographic Receipts for Every AI Output

Your agent just drafted a refactor plan for a stranger's repo, generated a SQL migration, and answered three compliance questions in a row. By Friday, the user is disputing one of them. The model never said that. You pull the logs — half are gone, the rest are just text, and "trust me" isn't evidence.

Receipts fix this. A cryptographic receipt for AI output is the same idea as a notary's stamp on a deed: it doesn't make the claim true, but it pins down exactly what was said, when, and by whom, and proves nobody quietly rewrote it afterward. EVIDIQ Notary is the layer we built at EVIDIQ to issue those receipts at machine speed for every AI inference.

What Is an AI Output Receipt?

An EVIDIQ Notary receipt is a cryptographic proof that a specific AI output — prompt, response, and model identifier — existed at a timestamp and has not been altered. Issued by the EVIDIQ Notary MCP server, each receipt bundles a keccak256 hash, an EIP-191 signature, and a Merkle anchor on 0G Storage, producing a tamper-evident trail anyone can independently verify.

Think of it this way: an HTTP request gives you a payload. A logged payload gives you a record. A receipt gives you something a third party can re-verify months later with no help from you. That's the only kind of evidence that holds up when money, contracts, or compliance are on the line.

The shape is intentionally minimal so it can travel in JSON, on-chain, or in a Slack thread:

• prompt_hash — keccak256 of the canonical prompt bytes
• response_hash — keccak256 of the canonical response bytes
• model — model id string the agent declares (e.g. gpt-4o, glm-5.2)
• timestamp — RFC3339 wall-clock at notarization
• signer — EVM address of the EVIDIQ Notary key (recoverable from the signature)
• signature — EIP-191 personal_sign over the canonical receipt JSON
• storageRoot + storageTx — 0G Storage Merkle root and on-chain anchoring tx

No fancy ZK circuits, no opaque embeddings — just primitives that have been audited for a decade. EVIDIQ Notary keeps the receipt small on purpose. The job is to be re-verifiable, not to be impressive.

Why AI Outputs Need Notarization

Here's the thing: agents are now the primary writers on the internet. Code suggestions, support replies, contract drafts, medical summaries — they all come from a model, mediated by a wrapper, often through a chain of tools. The user at the other end cannot tell, post hoc, what actually ran.

Three questions a receipt answers, and almost nothing else does:

1. Did this model produce this? The model id is signed in. No actually it was a different version later.
2. When was it produced? The timestamp is part of what was signed. Not "around Tuesday."
3. Was it altered? The hash is over the exact bytes; any tamper and the signature breaks.

Without a receipt, you are stuck reconstructing evidence from chat logs, server logs, and the goodwill of whichever party still has them. We've seen disputes where the only "proof" was a screenshot. We've shipped EVIDIQ Notary so future disputes have something better.

The deeper reason this matters in 2026 is the rise of agent-to-agent commerce. When one agent pays another via x402, the buyer wants a record of what it got. When a regulator asks what did your agent say to this customer on March 4th?, "we deleted those logs" is not an answer you want to give.

A receipt is cheap to emit, cheap to verify, and impossible to forge without the EVIDIQ Notary key. It's the smallest piece of infrastructure that turns "trust us" into "verify it."

How EVIDIQ Notary Works End to End

The flow is one MCP call. You send a notarize_inference request over the EVIDIQ Notary MCP server, get back an HTTP 402 challenge if no payment is attached, settle it with x402 on X Layer in USDT0, and receive a signed receipt plus a 0G Storage anchoring transaction. The whole round-trip is a few seconds.

Concretely, here's what happens, step by step, when your agent calls EVIDIQ Notary:

1. The agent POSTs a notarize_inference request to the EVIDIQ Notary MCP endpoint with the canonical prompt, response, model id, and an optional context hash. We canonicalize the inputs (sorted keys, normalized whitespace, fixed UTF-8 encoding) so both sides hash the same bytes.
2. The server replies HTTP 402 Payment Required with an x402 v2 challenge: scheme exact, asset USDT0, network x-layer, amount in accepts[].amount, and a pay-to address. Your client signs an EIP-3009 transferWithAuthorization and resends the request with an X-PAYMENT header.
3. On payment verification, the server computes receiptHash = keccak256(prompt_hash ‖ response_hash ‖ model ‖ timestamp) and signs the canonical receipt JSON using the EVIDIQ Notary key (personal_sign, EIP-191).
4. The receipt is appended to a Merkle batch, storageRoot is computed, and both the receipt and its Merkle proof are uploaded to 0G Storage (mainnet). The server returns storageRoot and the on-chain anchoring storageTx to your client.
5. You get back a JSON receipt that includes the prompt hash, response hash, model, timestamp, EIP-191 signature, signer address, Merkle proof, storageRoot, and storageTx. That object is now your evidence.

Let's make it concrete. Suppose your agent answered a user with:

prompt: "Return a JSON schema for a customer profile with email and locale."
response: '{"type":"object","properties":{"email":{"type":"string","format":"email"},"locale":{"type":"string"}}}'
model: "glm-5.2"
timestamp: "2026-03-14T11:22:08Z"

The EVIDIQ Notary server canonicalizes, hashes, signs, batches, and returns something like:

{
  "prompt_hash": "0x9f1c…b4e0",
  "response_hash": "0x3aa7…c812",
  "model": "glm-5.2",
  "timestamp": "2026-03-14T11:22:08Z",
  "signer": "0xEVIDIQ…01a7",
  "signature": "0x8d2f…d91c",
  "storageRoot": "0x71b3…44ee",
  "storageTx": "0xab12…9f30",
  "merkle_proof": ["0x…", "0x…", "0x…"]
}

That JSON is what you'd hand to a dispute resolver, a regulator, or a counterpart agent. It is also what your own code can re-verify, which is the whole point.

Verifying a Receipt Offline

Here's where the design earns its keep. Verification needs no API call, no account, no rate limit, and no contact with EVIDIQ Notary at all. Anyone holding the receipt JSON can prove it themselves in three steps:

1. Recompute response_hash = keccak256(canonical(response_bytes)) from the original (or canonicalized) input and check it matches receipt.response_hash.
2. Recover the signer from the EIP-191 signature over the canonical receipt JSON using ecrecover, and check it matches the EVIDIQ Notary signer address you expect.
3. Take the receipt's leaf hash and the merkle_proof, walk the path up against storageRoot, and confirm it matches the value anchored in storageTx on 0G Storage mainnet.

Every primitive in that list is open-source, well-audited, and runs in a few lines of code. You don't need our server to be online. You don't need to trust our word. The receipt is its own witness.

A few things this lets you do, which used to require paid legal discovery:

• A counterpart agent re-verifies a receipt on-device before paying out an escrow release.
• A user opens the receipt URL, hits Verify in a static page, and sees valid or invalid without contacting anyone.
• An auditor batches a thousand receipts, verifies all of them offline, and only pays attention to the ones that fail.

Worth noting: the signer address on every receipt is a known, published EVIDIQ Notary key. If a server hands you a receipt signed by some other address, it's not ours, and verification should fail closed. We publish the canonical signer set at our docs; a verifier that hardcodes that list can't be tricked by a lookalike signer.