EVIDIQ Notary: Cryptographic Receipts for Every AI Output

What Is an AI Output Receipt?

An AI output receipt is a cryptographic proof that a specific prompt, response, and model existed at a given timestamp and were not altered afterward. EVIDIQ Notary is the MCP server that issues these receipts: it hashes the inference, signs it with an EIP-191 signature, and anchors the evidence on 0G Storage so anyone can independently verify it.

A receipt is not a log line. It is not a screenshot. It's a verifiable artifact — small, portable, and mathematically tied to the exact bytes that came out of the model. When an agent says "I asked X, got Y, at time Z," an AI output receipt turns that statement into something a stranger can re-check from a coffee shop with a laptop and no API key.

Most agent stacks today have nothing like this. They have model IDs, request IDs, maybe a database row. None of that survives the trip from the agent's runtime to the verifier's screen. That's the gap EVIDIQ closes: a tamper-evident seal you can hand to a counterparty, an auditor, or a court.

In practice, an EVIDIQ Notary receipt bundles four things: the canonical hash of the inference (prompt ‖ response ‖ model id ‖ timestamp), an EIP-191 signature from the notary key, a Merkle root anchoring that hash to a batch, and an on-chain tx proving the batch hit 0G Storage. Lose any one of those and you've lost the guarantee.

Why AI Outputs Need Notarization

Picture this: an agent books a refund for a customer. The merchant disputes the refund. The customer service team pulls the transcript — but how do they prove the agent actually said what the transcript claims? The transcript is a string in a database. Anyone with database access could have written it.

Now multiply that by a million agent calls a day.

Agents in 2026 generate millions of outputs. Almost none of them are provable. Here's what breaks without notarization:

• A model can deny it ever produced a response.
• A response can be edited after the fact and passed off as original.
• A timestamp can be backdated, forward-dated, or omitted entirely.
• A "this was GPT-4" claim cannot be checked against an external witness.

These aren't theoretical concerns. We've seen disputes over agent advice in finance, healthcare routing, and contract review — and the common thread is always the same: nobody can prove what the model said, or when. The math is simple. If you can't prove the output, you can't enforce the contract that depends on it.

That's why we built the notary layer directly into the EVIDIQ MCP server. The trust score tells you whether to deal with an agent. The EVIDIQ Notary tells you what an agent actually said. They're complementary — one judges the counterparty, the other freezes the conversation. A wallet balance alone tells you nothing about an agent's intent; a notarized receipt tells you nothing about its character. You need both.

If you're already running agents through EVIDIQ Sentinel docs or EVIDIQ Operator docs, notarizing outputs is the next logical step. It's how you turn soft claims into hard evidence.

How EVIDIQ Notary Works End to End

Let's walk a real call. Your agent has just received a response from an upstream model and wants a receipt before it acts on the advice.

Here's the sequence:

1. The agent calls the MCP tool notarize_inference with prompt, response, model_id, and an optional context_hash.
2. The notary canonicalizes the inputs (sorted JSON, fixed timestamp format, keccak256 of the byte string).
3. The notary signs the canonical hash with the EVIDIQ key using EIP-191 personal_sign.
4. The notary batches the receipt into a Merkle tree, computes a storageRoot, and uploads the batch blob to 0G Storage (mainnet).
5. 0G Storage returns an on-chain tx; the notary attaches storageRoot and storageTx to the receipt and returns it.

The receipt object your agent gets back looks roughly like this:

{
  "inference_hash": "0x9f3a...c2",
  "signed_digest": "0xab12...7e",
  "signer": "0xEvidiqNotary...",
  "storage_root": "0x4b71...d0",
  "storage_tx": "0x9c0e...a1",
  "timestamp": "2026-04-12T18:22:31Z",
  "model_id": "gpt-4o-2026-04",
  "scheme": "eip191+merklex0g"
}

That's the whole flow. No long-running session, no custody of your prompt, no replay of your data. We hash and sign — the plaintext leaves your runtime exactly once, and the storage blob on 0G only stores the canonical hash plus metadata unless you opt in to archiving the raw text.

For the payment rail, EVIDIQ Notary follows the same x402 flow as the rest of the EVIDIQ surface. A first call returns HTTP 402 with the accepts[].amount challenge in USDT0 on X Layer. Once the agent sends a valid EIP-3009 transferWithAuthorization, the receipt is minted and returned. If you're just browsing, the EVIDIQ docs page has a copy-pasteable curl example.

A few things worth noting:

• The signer address is fixed and public. Anyone can ecrecover and confirm the signature came from the EVIDIQ Notary key.
• The storage_tx is real. Click it on a 0G explorer and you'll see the Merkle root anchored to mainnet.
• The receipt is small — typically under 600 bytes — so it can travel inside a JSON payload, a smart contract call, or even a tweet.

We deliberately kept the surface narrow. One tool, one job: turn an inference into evidence.

Verifying a Receipt Offline

Here's the part we care about most: you don't need us to verify a receipt.

Anyone with the receipt and 30 seconds of python can confirm it without contacting the notary, opening an account, or trusting a third party. The verifier workflow is:

1. Recompute the canonical hash: keccak256(prompt ‖ response ‖ model_id ‖ timestamp).
2. Run ecrecover on the signed_digest to recover the signer address.
3. Compare the recovered signer to the published EVIDIQ Notary address.
4. Pull the Merkle proof from 0G Storage using storageRoot.
5. Confirm the original inference_hash is in the Merkle tree and the tree root matches storage_tx.

If all five checks pass, the receipt is genuine. If any one fails, it's not.

This is the property that makes EVIDIQ Notary useful in adversarial settings. Two parties can disagree about what an agent said, hand each other a receipt, and resolve the dispute with a deterministic script — no court, no platform, no EVIDIQ involvement required. The receipt is its own witness.

We've heard the same question from builders a few times now: "but couldn't the notary sign a fake receipt before the inference happened?" No — the receipt commits to the bytes of the inference via the canonical hash, and the timestamp is part of that commitment. Pre-signing would require knowing the model output in advance, which collapses the entire premise of the attack.

A second common question: "doesn't the notary see my prompts?" Briefly, to compute the hash. We log zero plaintext, we sign the hash, and we offer a separate notarize_commitment tool that takes a precomputed hash so you never have to ship your prompt to us at all. The full design lives in the EVIDIQ Notary docs.

Third parties — auditors, counterparties, regulators, journalists — can all run the same script. There's nothing proprietary in the verification path. That's deliberate: a receipt you can't verify without paying the issuer isn't a receipt, it's a subscription.