EVIDIQ Notary: Cryptographic Receipts for Every AI Output

Your agent just spent $0.40 calling an inference API. It got a response. Now what? You have a string of text, a log line at best, and absolutely no proof that what came back is what the model actually said — or that it said it at the time you think it did. That's the gap EVIDIQ Notary closes.

What Is an AI Output Receipt?

An AI output receipt is a cryptographic proof that a specific model produced a specific response to a specific prompt at a specific time. EVIDIQ Notary issues these receipts by hashing the inference inputs and outputs, signing the hash with EIP-191, and anchoring the evidence on 0G Storage so anyone can verify it offline.

Here's the mental model. A credit card receipt proves you paid a merchant a specific amount at a specific time. An AI output receipt proves a model produced a specific response to a specific prompt, signed by a known key, anchored to a verifiable location. It is not a transcript. It is not a screenshot. It is a piece of evidence that survives the agent, survives the API provider, and survives the database.

We built EVIDIQ Notary as an MCP server tool so it slots into any agent runtime that already speaks MCP — Claude Desktop, Cursor, custom agent harnesses, anything. The agent calls notarize_inference, gets back a receipt, and from that moment on the inference is provable to anyone holding the receipt.

What goes into a receipt, concretely:

• The canonical hash of the prompt bytes
• The canonical hash of the response bytes
• The model identifier claimed by the caller
• A timestamp from the notary's clock
• The signature of all of the above, EIP-191 over the EVIDIQ Notary key
• A storageRoot and storageTx pointing to the full evidence on 0G Storage

If you want the longer version, the EVIDIQ Notary docs walk through every field and how to recompute it locally.

Why AI Outputs Need Notarization

Agents generate millions of inferences per day. Almost none of them are provable. A user asks "did this model really say that, and when?" and the honest answer is usually: we have a database row, a chat log, and a vibes-based trust assumption about the API provider. That's not enough anymore.

Consider three questions that come up the moment money, reputation, or regulation enters the picture:

1. Existence — Was this inference actually produced, or did someone write a fake log entry after the fact?
2. Integrity — Has the response been edited, trimmed, or re-translated between the model and the consumer?
3. Provenance — Which model, with which parameters, on which date, produced this exact text?

A receipt answers all three. The timestamp proves existence. The hash proves integrity — any byte change invalidates the signature. The signed metadata plus the storage anchor on 0G Storage proves provenance, because the evidence is reachable by anyone who can read the chain.

We see this pressure already in 2026. Auditors want evidence. Counterparties want evidence. Insurers want evidence. Without notarization, every agent operator is one bad-faith dispute away from being unable to prove what their system actually did. EVIDIQ Notary is the layer that turns "trust me, the model said this" into "here is the signed, anchored receipt."

[IMAGE_PROMPT: A flat illustration showing a stack of translucent paper receipts flowing from a glowing AI model chip on the left into a blockchain anchor on the right, with a small keccak256 hex hash symbol and an EIP-191 signature seal hovering above, developer console aesthetic, dark navy background with cyan and lime accents, no real brand logos, no text]

How EVIDIQ Notary Works End to End

Let's walk a real call. Your agent wants to notarize an inference that used gpt-x to summarize a contract clause.

Step 1 — the agent calls the MCP tool with the hashes it computed locally:

{
  "tool": "notarize_inference",
  "args": {
    "prompt_hash": "0x9f2c…",
    "response_hash": "0x44a1…",
    "model": "gpt-x@2026-04",
    "metadata": { "task": "clause_summary", "request_id": "req_88a2" }
  }
}

Step 2 — the notary returns an HTTP 402 challenge under the x402 v2 spec, with an accepts[] array describing the exact USDT0 payment on X Layer. This is the same payment rail used across EVIDIQ, so wallets, agents, and SDKs you already have will handle it without glue code.

Step 3 — your agent signs an transferWithAuthorization (EIP-3009) for the quoted amount and resubmits the call with the payment header attached.

Step 4 — the notary assembles the canonical evidence object, with payload_hash being keccak256 of the canonicalized JSON of everything inside it:

{
  "version": 1,
  "prompt_hash": "0x9f2c…",
  "response_hash": "0x44a1…",
  "model": "gpt-x@2026-04",
  "timestamp": "2026-04-12T18:22:09Z",
  "metadata": { "task": "clause_summary" },
  "payload_hash": "0xce7b…"
}

Step 5 — the notary signs payload_hash with EIP-191 over the EVIDIQ Notary signer key. The signature is recoverable: anyone with the receipt can run ecrecover and confirm it matches the published EVIDIQ Notary key.

Step 6 — the evidence blob is uploaded to 0G Storage mainnet, which returns a Merkle root and an on-chain transaction hash. Both are appended to the receipt:

{
  "payload_hash": "0xce7b…",
  "signature": "0xab12…",
  "signer": "0xEv1d1Q…Notary",
  "storageRoot": "0x88f0…",
  "storageTx": "0x4d2c…",
  "timestamp": "2026-04-12T18:22:09Z"
}

The agent now holds a complete receipt. Anyone in the world can re-fetch the evidence from 0G Storage using storageRoot, re-hash it, and confirm the signature against the published key. The whole round trip — including the x402 payment — typically lands inside a few seconds. We tuned the EVIDIQ Sentinel docs so monitors can also subscribe to a feed of newly issued receipts and react to them in real time.

Verifying a Receipt Offline

Here's the part we care most about: verification does not require talking to the notary. It does not require an API key, an account, a subscription, or a phone home. It's pure client-side math.

You take a receipt, you run three checks:

1. Recompute keccak256(canonical_json(prompt_hash, response_hash, model, timestamp, metadata)) and confirm it matches payload_hash.
2. Run ecrecover(payload_hash, signature) and confirm the recovered address equals the published EVIDIQ Notary signer.
3. Pull the evidence blob from 0G Storage using storageRoot and confirm the blob hashes to payload_hash under the Merkle proof embedded in storageTx.

If all three pass, the receipt is valid. No contact with EVIDIQ required. The whole point is that a third party — a court, a counterparty, an auditor, a regulator in 2026 or later — can verify without our cooperation. That is the property that makes it evidence and not just a JSON file.

We exposed this in the EVIDIQ Operator docs with copy-pasteable snippets for Node and Python. Operators running fleets of agents can plug the verifier straight into their dispute flow so that a contested inference can be settled in seconds, not weeks of email archaeology.

Worth noting: a receipt proves what the caller declared. If the caller lied about the model identifier, the receipt proves a lie was committed at a specific time, but it does not retroactively prove what the actual model was. Pairing EVIDIQ Notary with the live capability probe in EVIDIQ closes most of that gap — the probe independently confirms what an agent endpoint actually serves, and the receipt proves when it served it.

[IMAGE_PROMPT: A clean flat diagram showing three verification panels in a row: a keccak256 hash icon with a binary stream, an EIP-191 signature shield with a recovered address, and a 0G Storage Merkle tree with a highlighted root node, all connected by subtle verification arrows on a soft off-white background with teal and violet accents, technical blueprint feel, no text, no real brand logos]