EVIDIQ Notary: Cryptographic Receipts for Every AI Output

Your agent just spent $0.40 routing a refund, an LLM produced a 200-word explanation, and a customer is now disputing what the model actually said. You have logs. Logs aren't proof — they're whatever the system felt like writing at the moment someone looked. A cryptographic receipt is different: it binds the exact bytes of a prompt, response, and model identifier to a single signed timestamp, and once written down, nobody — not the agent, not the model provider, not EVIDIQ, not you — can change a character without breaking the signature. That's the gap EVIDIQ Notary closes.

What Is an AI Output Receipt?

An AI output receipt is a cryptographically signed record proving a specific model produced a specific response at a specific timestamp, and has not been altered since. EVIDIQ Notary is the MCP server that issues these receipts, signing each one with EIP-191 and anchoring it on 0G Storage so anyone can verify offline.

Strip away the cryptography for a second. A receipt is just a statement with four fields — what was said, who said it, when, and who vouches for both. The "who vouches" part is what makes it a receipt instead of a log line. Without a third-party signature, you're trusting the agent's own database, which is the entity on trial. EVIDIQ Notary plays that third-party role for the entire agent economy: a neutral notary that signs outputs the way a notary public signs deeds, and never holds custody of anything.

Here's what every receipt our notary produces contains:

• Prompt hash (keccak256) — the exact input the model saw.
• Response hash (keccak256) — the exact output bytes returned.
• Model identifier — provider and model name, e.g. openai/gpt-4o or anthropic/claude-sonnet.
• Timestamp — Unix seconds, recorded at notarization.
• Signer address — the EVIDIQ Notary EVM address that produced the signature.
• Storage root — the 0G Storage Merkle root the receipt was anchored under.
• Storage tx — the on-chain transaction hash anchoring that root.
• Signature — EIP-191 personal_sign over the canonical receipt hash.

That's the whole thing. Eight fields, one signature, one Merkle root, one transaction. Anything claiming to be "AI provenance" needs at least this much.

Why AI Outputs Need Notarization

Here's the thing: agents in 2026 generate millions of inferences per day, and almost none of them are provable. A typical SaaS agent logs {"prompt": "...", "response": "..."} to Postgres. Three months later the row exists, but the row was written by the system under dispute. The customer asks for the model output. The model provider says "we don't store completions." Postgres says "trust us, that's what we saved." Nobody can prove anything, and the merchant eats the chargeback.

Receipts invert that. Instead of asking people to trust a database, you ask them to recompute a hash and check a signature. Three questions an AI output receipt must answer:

1. Did this model actually say this? A prompt hash + response hash + model identifier pinned at signing time leaves no wiggle room.
2. When did it happen? A signed timestamp anchors the output in history. Useful for SLAs, billing windows, and audit trails.
3. Was it altered afterward? Anyone can recompute keccak256 over the original bytes and compare. One bit flipped, the signature breaks.

Without those three answers, "the AI said so" is just hearsay. With them, it's evidence.

[IMAGE_PROMPT: A flat modern illustration showing a chat bubble emerging from a stylized neural network node on the left, traveling through a vertical stack of cryptographic hash blocks with hex characters visible in the center, and arriving at a stamped RECEIPT document with a green checkmark seal on the right. Developer/tech aesthetic, soft blue and teal palette, abstract geometric nodes, no real brand logos, no text labels in the image.]

We see the same pattern across every vertical — trading bots logging fills, support agents logging responses, scraping agents logging what they retrieved. They're all running on trust they haven't earned. EVIDIQ Notary is the part that converts that trust into verifiable evidence.

How EVIDIQ Notary Works End to End

Walk through a single notarize_inference call with us. Your agent has just received a response from anthropic/claude-sonnet, and you want a receipt.

1. Client assembles the canonical document. Your code takes the raw prompt bytes, the raw response bytes, the model string, and the current Unix timestamp, then computes keccak256 over the canonical concatenation. This is the document everyone will later verify against.
2. Client calls notarize_inference on the EVIDIQ Notary MCP server. The call includes the four fields plus your payer address. The notary responds with an HTTP 402 Payment Required challenge (x402 v2, scheme exact, EIP-3009 transferWithAuthorization, USDT0 on X Layer) for the notarization fee.
3. Client signs and re-submits the x402 authorization. The notary verifies the EIP-3009 signature and settles the payment on chain. No accounts, no API keys, no subscriptions.
4. Notary computes the receipt hash and signs it. We compute keccak256 over the canonical receipt fields, then EIP-191 personal_sign the hash with the EVIDIQ Notary signer key.
5. Notary uploads the receipt to 0G Storage. The signed receipt object goes into 0G Storage mainnet, which returns a Merkle root and an on-chain anchoring transaction hash.
6. Notary returns the receipt. You get a JSON object with promptHash, responseHash, model, timestamp, signer, storageRoot, storageTx, and signature — plus the raw receipt bytes so you can store them locally too.

Here's roughly what the flow looks like in pseudocode:

const challenge = await notary.notarize_inference({
  prompt, response, model: "anthropic/claude-sonnet", payer: wallet.address
});
// challenge is 402 with payment requirements

const receipt = await notary.notarize_inference({
  ...challenge.payload,
  paymentAuthorization: signedX402Header
});

console.log(receipt);
// {
//   promptHash: "0x9f2a...",
//   responseHash: "0x4c1e...",
//   model: "anthropic/claude-sonnet",
//   timestamp: 1735689600,
//   signer: "0xEv1d1q...",
//   storageRoot: "0xab12...",
//   storageTx: "0x6f...",
//   signature: "0x7c3a...1f"
// }

At this point you hold a receipt nobody can rewrite. The full MCP reference lives in the EVIDIQ Notary docs, and the broader trust-surface primitives (probe, score, recommendation) sit in the EVIDIQ Operator docs if you want the full picture.

One nuance worth flagging: the response hash locks down bytes, not meaning. If your agent post-processes the model output — trimming whitespace, swapping emojis, reformatting JSON — you need to notarize the post-processed output, not the raw one. Otherwise you'll verify a receipt for a string nobody ever saw.

Verifying a Receipt Offline

This is the part that makes the whole system worth building. Verification needs zero contact with the notary. No API key, no rate limit, no authentication, no EVIDIQ Sentinel probe, no live endpoint. Just a hash function and a secp256k1 signer.

The verification recipe:

1. Recompute the document hash. keccak256 over the canonical concatenation of prompt ‖ response ‖ model ‖ timestamp. Compare to the receipt's claimed promptHash and responseHash — if they match, you have the original bytes; if not, somebody changed something.
2. Recompute the receipt hash. keccak256 over the receipt fields (excluding the signature itself).
3. Recover the signer from the signature. EIP-191 signatures are recoverable — ecrecover gives you the address that signed the hash. Compare to the receipt's signer field. If it matches, the entity that produced the receipt is exactly who it claims to be.
4. Check the Merkle proof against storageRoot. The receipt's bytes were anchored inside 0G Storage at this root. Fetch the Merkle proof and verify the leaf hash is included.
5. Check storageTx on chain. Pull the 0G Storage mainnet transaction, confirm it contains storageRoot, and you've got the timestamp of the anchor itself.

[IMAGE_PROMPT: A flat modern developer-aesthetic illustration of a verification workflow: a JSON receipt document on the left with hex hashes, three arrows branching to the right showing keccak256 recompute, EIP-191 ecdsa recovery, and 0G Merkle proof check, all converging into a green VERIFIED shield on the far right. Cool blue and slate palette, abstract geometric nodes, no real brand logos, no text labels in the image.]

In practice the entire check is one npm install away — we publish a verifier package that does steps 1–5 in roughly 40 lines. Because verification is offline and deterministic, you can run it inside an air-gapped auditor's laptop, inside a regulator's compliance tool, or inside a smart contract that consumes the receipt on chain. The notary doesn't get a vote. The math does.

Worth noting: the trust score from EVIDIQ Sentinel — identity + capability + reputation + risk, combined as identity0.3 + capability0.3 + reputation*0.2 + (100−risk)*0.2 — is independent of Notary. Sentinel answers "should I transact with this agent?" Notary answers "did this specific output happen, unchanged?" They compose; they don't overlap.