EVIDIQ Notary: Cryptographic Receipts Every Agent Can Trust

Picture this. Your autonomous agent books a flight through a third-party booking agent. Two weeks later, the airline denies the booking ever happened. The booking agent insists it confirmed in writing. Both sides are sure they're right.

In 2026, this isn't hypothetical — it's the daily reality across millions of agent-to-agent interactions. The prompt, the response, the model, the timestamp — all of it is vapor. No proof. No signature. Nothing to hand to a counterparty, an auditor, or a regulator when the dispute opens.

We built EVIDIQ Notary to fix exactly this.

An EVIDIQ Notary receipt is a small, verifiable artifact that proves a specific inference happened — with a specific prompt, a specific response, a specific model identifier, and a specific timestamp — and was not altered afterwards. It's the missing receipt layer of the autonomous economy, and it's the natural sibling to the EVIDIQ trust score you may already use to vet counterparties.

What Is an AI Output Receipt?

An AI output receipt is a cryptographic artifact that proves a specific inference — its prompt, response, and model — existed at a given time and has not been altered since. EVIDIQ Notary is the MCP server that issues these receipts, signs them with EIP-191, and anchors the canonical hash on 0G Storage so any third party can verify the inference independently.

The mental model is older than crypto. When you buy a car, you get a title. When you buy a house, you get a deed. When an agent produces an output that someone will rely on — a price quote, a code review, a medical triage suggestion, a booking confirmation — that output deserves a title too. Without it, "the AI said so" is just a story. With an EVIDIQ Notary receipt, it's evidence.

A receipt is not the inference itself. You don't have to publish your prompt or response to get one. The notary captures a canonical hash of the document, signs that hash, and stores the hash on-chain. The content stays with you. Anyone holding the same content can later prove the notary saw it too.

If you've already met our scoring engine in EVIDIQ Sentinel docs or our agent operator surface in EVIDIQ Operator docs, you've seen how seriously we take verifiability. The Notary applies the same discipline to outputs that those systems apply to identity and capability.

Why AI Outputs Need Notarization

The honest answer: because the volume of agent-generated text is exploding and almost none of it is provable.

Consider the failure modes a notarized output eliminates:

• Repudiation. "My agent never said that." A receipt makes this claim impossible.
• Tampering. "You must have changed the response." A receipt's hash makes this detectable.
• Replay. "That was from a different run." A timestamp + model identifier kills this.
• Hallucination disputes. "The model hallucinated this fact." You can re-run the same model against the same prompt and compare hashes.

Without notarization, every AI-mediated decision sits on the honor system. With it, the work product of an agent becomes something you can quote, cite, and litigate. Agents get a paper trail. Operators get confidence. Counterparties get something they can independently check.

We saw this gap clearly while building our trust score at EVIDIQ. A score tells you whether to deal with an agent. A receipt tells you what an agent actually said. Both are necessary, and they're complementary — the score is the front door, the receipt is the audit log.

How EVIDIQ Notary Works End to End

Let's walk through a single EVIDIQ Notary call, because the protocol is short and concrete.

The flow has six steps:

1. The caller hashes the canonical document (prompt ‖ response ‖ model ‖ timestamp) using keccak256.
2. The caller calls the Notary MCP tool notarize_inference with that hash and the metadata fields.
3. The MCP server responds with an HTTP 402 payment challenge via x402 (scheme "exact", USDT0 on X Layer).
4. The caller signs a transferWithAuthorization (EIP-3009) and retries the request with the X-PAYMENT header.
5. The Notary constructs the canonical JSON receipt, signs it with the EVIDIQ key using personal_sign (EIP-191), and uploads the canonical bytes to 0G Storage mainnet.
6. The Notary returns the signed receipt, including storageRoot (Merkle root) and storageTx (the on-chain anchor transaction hash).

The caller now holds an artifact with this shape:

{
  "version": "notary.v1",
  "prompt_hash": "0x...",
  "response_hash": "0x...",
  "model": "openai/gpt-...",
  "timestamp": "2026-...",
  "document_hash": "0x...",
  "storageRoot": "0x...",
  "storageTx": "0x...",
  "signature": "0x...",
  "signer": "0xEVIDIQ..."
}

A concrete example. An agent summarizes a contract clause at 14:03:17 UTC on March 4, 2026. It computes keccak256(prompt ‖ response ‖ model ‖ timestamp) and gets a 32-byte hash. It sends that hash to EVIDIQ Notary. Within a couple of seconds the agent has a signed receipt pointing to a 0G Storage root and an on-chain transaction hash. The agent stores the receipt alongside the inference — same database, same audit trail.

Anyone who later needs to check the inference calls verify_receipt. They get back PASS or FAIL with a reason. No key, no account, no API quota.

If you're wiring this into a larger agent stack, the EVIDIQ docs page shows how Notary slots in next to Sentinel and Operator. The full Notary surface, including the JSON schema, error codes, and the recovery procedure for a corrupt receipt, lives at EVIDIQ Notary docs.

Verifying a Receipt Offline

Here's the part we care most about: EVIDIQ Notary verification does not require us to be online, willing, or even still operating.

Three primitives are enough to check any receipt:

1. Recompute the document hash. Take the original prompt, response, model identifier, and timestamp. Concatenate them with the same canonical byte ordering. Run keccak256. If your hash doesn't match document_hash in the receipt, you stop — the receipt is for a different inference.
2. Recover the signer. ecrecover(keccak256("\x19Ethereum Signed Message:\n" ‖ len ‖ json), signature). The recovered address must equal signer in the receipt. If it doesn't, EVIDIQ didn't sign this.
3. Check the Merkle proof. Fetch the leaf at document_hash from 0G Storage using storageRoot. The Merkle proof must validate against the root, and the root must match the one in the receipt.

That's it. No API key, no rate limit, no need for EVIDIQ to even know you're looking. The receipt is self-contained cryptographic evidence. If 0G Storage ever rotates its nodes, the proof still verifies against any honest archive.

This offline verifiability is the reason we chose EIP-191 plus a content-addressed storage layer instead of a centralized notary database. Anyone who can run a hash function can audit an inference. That's the property that makes the receipt useful in court, in arbitration, and in code review.