EVIDIQ Notary: Cryptographic Receipts for Every AI Output

What Is an AI Output Receipt?

A cryptographic receipt proves a specific AI output — exact prompt, response, and model identifier — existed at a precise timestamp and has not been altered since. EVIDIQ Notary is the MCP tool that issues these tamper-evident receipts by signing the inference with EIP-191 and anchoring evidence on 0G Storage.

The idea of a receipt isn't new — payment systems have shipped them for decades. For an inference, a receipt has to bind four things together:

1. The exact prompt that was sent.
2. The exact response that came back.
3. The model identifier (so a cheaper model can't be quietly swapped in).
4. A timestamp, ideally anchored to a public chain.

…and that binding has to be tamper-evident. A simple log file in Postgres doesn't count — anyone with DB access can rewrite history. EVIDIQ Notary is the tool we built to issue these bindings as cryptographic receipts. You POST an inference, pay via x402, and get back a signed payload anchored to a public storage network.

That's the whole pitch. Everything below is the plumbing.

Why AI Outputs Need Notarization

Picture this: it's 2026, and your AI agent has just produced a financial summary that your compliance team will rely on next quarter. The agent called an LLM, got back a JSON-with-prose response, and forwarded it to a downstream system. Six months later, the auditor asks: "Did this exact model say this exact thing on this exact date?" — and you have nothing. Logs are mutable, screenshots are forgeable, and the model vendor can only attest to broad usage stats.

The math is simple. Agents are already generating millions of inferences per day. Almost none of them carry cryptographic proof of what was produced. If even 0.1% of those outputs ever need to be defended — a refund dispute, a regulatory disclosure, a contract clause — there is currently no neutral third party that can say "yes, this prompt produced this response at this time."

[IMAGE_PROMPT: A modern flat illustration showing a stylized AI agent at left sending a glowing prompt bubble toward a server stack at right, with a sealed envelope or certificate emerging from the server and being anchored into a chain of blocks below; color palette deep navy and cyan with subtle orange accent; clean geometric shapes, developer/tech aesthetic, no real brand logos, no text in the image]

Three things a notarized receipt answers, by the way:

• Existence — was this output actually produced, or is it a fabrication?
• Integrity — has the output been altered since production?
• Provenance — which model produced it, and which Notary signed it?

A receipt that doesn't answer all three is just a log line. We've seen too many "AI audit trails" that turn out to be CSVs the vendor can edit. EVIDIQ Notary is built to make those three answers verifiable offline, by anyone, without contacting us.

Worth noting: the same problem shows up in agent-to-agent commerce. When one agent pays another for an inference, neither party has a neutral witness. Notarization gives them one.

How EVIDIQ Notary Works End to End

Here's a single notarize_inference call, walked step by step. We picked a realistic example: an agent receives a prompt "Summarize Q1 treasury exposure" and gets back a 240-word summary from gpt-x-2026-03.

1. The agent calls the MCP tool notarize_inference with {prompt, response, model, requester, timestamp}.
2. EVIDIQ Notary canonicalizes the payload (sorted JSON, UTF-8 NFC, no whitespace ambiguity) and computes keccak256(canonical_bytes).
3. The server returns an HTTP 402 Payment Required challenge (x402 v2, scheme "exact", USDT0 on X Layer, price pinned at the moment of the request).
4. The agent signs an EIP-3009 transferWithAuthorization for the quoted amount and retries with the X-PAYMENT header.
5. EVIDIQ Notary validates the payment, then signs the keccak256 hash with the EVIDIQ operator key — a real EIP-191 signed message: \x19Ethereum Signed Message:\n32 followed by the 32-byte digest.
6. The canonical payload (prompt + response + model + timestamp + signature + signer) is uploaded to 0G Storage (mainnet). The upload returns a storageRoot and an on-chain transaction hash (storageTx).
7. The agent receives the receipt: { digest, signature, signer, model, timestamp, storageRoot, storageTx }.

In practice, the entire flow takes about 3–5 seconds — the bottleneck is the storage upload, not the crypto. The signing itself is sub-millisecond. We chose this design because it separates concerns cleanly: payment is verifiable on X Layer, evidence is verifiable on 0G Storage, and the signature is recoverable by anyone with an EVM node.

Two things worth calling out, since we get asked a lot:

• The signer is fixed and published. You don't need to trust the signer — the receipt is useless without the matching canonical payload. Anyone can verify the chain end to end.
• The x402 challenge is non-custodial. The 402 challenge happens before signing — payment only settles after you authorize it, and we never hold the receipt in escrow.

If you're wiring this into a real agent, the EVIDIQ docs walk through TypeScript and Python SDK snippets, and the EVIDIQ Notary docs have the full schema for the canonical hash, including how model identifiers are normalized.

Verifying a Receipt Offline

This is the part we care most about. A receipt that requires contacting us to verify it isn't really a receipt — it's a phone call. EVIDIQ Notary is built so verification needs zero network calls to the notary, zero API keys, and zero trust in us.

The offline verifier, which is about 80 lines of Python in the open-source repo, does four things in order:

1. Recompute the digest. Take the canonical payload (prompt + response + model + timestamp, in the same sorted-JSON form). Run keccak256 on it. You should get exactly the digest field in the receipt.
2. Recover the signer. Use ecrecover (or ethers.js verifyMessage) on the EIP-191 prefixed hash. The recovered address must equal the signer field.
3. Check the Merkle proof. Fetch the proof path from storageRoot to the leaf hash. It's a standard 0G Storage Merkle proof — no special library needed.
4. Optionally anchor the proof to the chain. Look up storageTx on the 0G mainnet explorer to confirm the upload actually happened at that block.

If all four pass, you've proven: this exact prompt produced this exact response, this exact model signed it, and the evidence is anchored to a real on-chain storage root. No API call. No subscription. No login.

[IMAGE_PROMPT: A flat modern illustration of a developer laptop screen showing a code verification workflow with a green checkmark pipeline; floating geometric icons representing hash function, signature recovery, Merkle tree, and blockchain explorer; color palette of teal, slate gray, and soft yellow; developer aesthetic with circuit-line accents; no real brand logos, no text in the image]

A concrete reason this matters: imagine two agents are about to settle a $400 invoice via the EVIDIQ Sentinel docs flow. The buyer's agent wants to attach the inference that triggered the payment as evidence. The seller's agent refuses because it doesn't trust Sentinel. The compromise? Both agents independently notarize the inference, exchange receipts, and verify them offline. No third party needed. That kind of peer-to-peer audit trail is the whole reason we built Notary the way we did — it's the missing piece between the EVIDIQ Operator docs verification flow and real-world dispute resolution.

One opinionated take: a notarized receipt is the only thing that survives contact with a counterparty who has an incentive to lie. Logs, screenshots, and screenshots-of-screenshots don't.