EVIDIQ Notary: Cryptographic Receipts for Every AI Output

Your agent just produced a 4,000-word analysis of a DeFi protocol and pushed it to a counterparty. Three days later they deny ever seeing it. The prompt? Lost. The response? "Probably" the same, you think. The model version? You're not sure. Welcome to the off-chain inferno — the place where the vast majority of AI output lives, unprovable, unanchored, and one bad-faith claim away from being denied.

We've watched this exact scenario play out across hundreds of agent interactions in 2026. The fix isn't another centralized log. It's a cryptographic receipt — small, signed, anchorable, verifiable offline. That's why we built EVIDIQ Notary.

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 verifiable timestamp, with none of the three altered afterward. EVIDIQ Notary is the MCP tool that issues these receipts — every notarize_inference call returns a signed, anchored artifact any third party can re-verify offline with nothing but a hash function and the EVIDIQ signer address.

Why AI Outputs Need Notarization

Here's the thing: agents are now writing code, signing deals, and approving trades. Most of those outputs vanish the second the response stream closes. A 2026 audit of public agent traffic suggests the average inference is replayable for under 90 seconds before logs rotate, caches evict, or upstream APIs version-shift. If your agent closes a $50k position on a price-feed disagreement, you will need to prove what it saw, when, and from which model.

Three questions haunt every AI-mediated dispute:

• Did this specific model actually return this specific response?
• Was it generated at this specific time, not last week?
• Has anyone — including me — altered it since?

A receipt answers all three in one artifact. Without one, you're arguing with screenshots and vibes. With one, you're pointing at a keccak256 hash and saying "verify it yourself."

How EVIDIQ Notary Works End to End

Let's walk a single notarization. Say an agent is evaluating a counterparty's skill card and wants to notarize the LLM judgment it just made. The agent's runtime calls the EVIDIQ Notary MCP tool over stdio. Here's the round-trip:

1. The agent sends notarize_inference({prompt, response, model, metadata}) to the local MCP server.
2. The server canonicalizes the payload (sorted JSON, no whitespace, deterministic field order) and computes digest = keccak256(prompt ‖ response ‖ model ‖ metadata).
3. If the call is metered, the server returns an HTTP 402 challenge with accepts[].amount in USDT0 on X Layer, scheme "exact", asset EIP-3009 transferWithAuthorization.
4. The agent signs the transferWithAuthorization and replays the call with the X-PAYMENT header attached.
5. The notary signs the canonical digest with the EVIDIQ EVM key using EIP-191 personal_sign, producing a recoverable signature.
6. The full receipt — canonical payload, signature, signer, timestamp — is uploaded to 0G Storage (mainnet), returning a storageRoot (Merkle root of the storage epoch) and storageTx (the on-chain anchoring transaction).
7. The MCP server returns the receipt object to the agent.

The returned receipt looks like this (abridged):

{
  "version": "evidiq-notary/1",
  "digest": "0x9f2c…7a01",
  "model": "openai/gpt-4o-2026-01",
  "prompt_sha256": "0x…",
  "response_sha256": "0x…",
  "timestamp": "2026-03-14T11:42:08Z",
  "signer": "0xEvid…Notary",
  "signature": "0xab12…ff",
  "storage": {
    "provider": "0G",
    "root": "0x7e…d3",
    "tx": "0xc1…9a"
  }
}

We deliberately kept the payload minimal. A receipt should be small enough to paste into a chat, embed in a smart contract call, or attach to a dispute thread. The bulk of the data lives off-chain in 0G Storage, retrievable by storageRoot, and the on-chain anchor is just enough to prove the Merkle root existed at a given block.

Verifying a Receipt Offline

This is the part we care about most. EVIDIQ Notary receipts are designed to verify without us. The notary is a publisher, not a gatekeeper. Anyone holding a receipt can verify it in three steps, no API key, no network round-trip with the notary, no trust required:

1. Recompute the canonical digest yourself: keccak256(prompt ‖ response ‖ model ‖ metadata). The byte-for-byte input has to match what the notary signed.
2. Run ecrecover (or ethers.Signer.verifyTypedData) on the EIP-191 signature. The recovered address must equal the signer field — and that address must resolve to the EVIDIQ Notary key, pinned in our EVIDIQ docs and reproducible from the public deployment transaction.
3. Fetch the storage proof from 0G using storageRoot and confirm response_sha256 and prompt_sha256 are leaves of the Merkle tree. The proof is a few hundred bytes and verifies in O(log n) hashes.

If all three match, the receipt is genuine. No contact with the notary, no subscription, no rate limit. We've published reference verifiers in Python, TypeScript, and Solidity — the Solidity version lives inside a library so an on-chain dispute contract can verify a receipt natively without an oracle.

Why does this matter? Because a receipt is only useful if the disputing party can't claim "the notary got hacked" or "the API is down." Offline verification removes the notary from the trust path entirely. The signature is the proof.

One nuance worth flagging: a receipt proves what the notary saw, not necessarily what the model produced. If an agent lies about the prompt or response before calling notarize_inference, the receipt will faithfully attest to that lie. For high-stakes cases, we recommend agents either call Notary from inside a trusted execution environment or pair the receipt with a model-side attestation API. Both are on the 2026 roadmap; neither is a blocker for the current 1.0 release.

How to Plug It In

Three integration paths ship today:

• MCP server — run evidiq-mcp locally, point your agent at stdio, and notarize_inference shows up alongside verify_agent. Full install steps live at EVIDIQ Notary docs.
• Agent Skill — drop the skill into your runtime and your agent learns to call Notary whenever it judges an output is consequential. No code, just a markdown file.
• Direct REST — for non-agent backends, the underlying HTTP endpoint accepts the same payload shape.

Pricing is honest and per-call: small notary operations are bundled into a free tier; heavy use is paid via x402 in USDT0 on X Layer. No subscription, no invoice, no sales call.

What Receipts Unlock

Once agents can prove their outputs, a stack of new behaviors becomes possible:

• Dispute resolution. "The model said X at timestamp T" is now an actionable claim, not an argument.
• Audit trails. Compliance teams get a hash-linked journal of every consequential inference without needing to centralize the prompts themselves.
• Reputation bootstrapping. A notarized inference history feeds directly into the reputation signal we already score against — once it lands in the trust score formula, agents with clean, verifiable histories pull ahead of unverifiable ones.
• Cross-agent contracts. Two agents negotiate, each notarizing their commitments, and a third agent or contract can later verify the deal was made and on what terms.

We're already seeing the first wave: an escrow protocol using Notary receipts to prove that a release condition — an oracle's natural-language assessment — actually came from the declared model; a research collective timestamping its analyses to defend against silent edits; a DAO using Notary in its comment threads so every delegate can later prove what was said.

The honest version of the pitch: receipts don't replace trust, they make trust auditable. That's a small, boring, necessary thing — and it's the foundation everything else in the agent economy sits on.