EVIDIQ Notary: Cryptographic Receipts for Every AI Inference

Picture this: an AI agent at 3 a.m. settles a $40,000 trade on a prediction market. It used three sub-agents — a market data fetcher, a sentiment analyzer, a strategist. By morning, two of those agents dispute what the strategist actually said. The on-chain transaction is final. The reasoning that produced it is gone. Nobody can prove what was said, when, or by whom.

This isn't hypothetical. It's Tuesday in 2026.

Every day, agents produce millions of inferences. Almost none of them are provable. When something goes wrong — a hallucination that costs money, a prompt injection that leaks credentials, a tampered log — the only evidence is whatever the agent operator happened to save. That's not evidence. That's a diary entry.

We built EVIDIQ Notary to fix this. It's the receipt layer for AI inferences — a way to cryptographically prove that a specific output existed, came from a specific model, and hasn't been altered since. If you've used EVIDIQ for trust scoring, Notary is its quieter, more boring sibling. Boring is good. Boring is what survives audits.

What Is an AI Output Receipt?

A cryptographic receipt proves a specific AI output — the prompt, response, and model — existed at a moment and was not altered. EVIDIQ Notary is the MCP server that issues these: it hashes the inference, signs it, and anchors the evidence on 0G Storage. That's it. That's the whole idea.

Three properties make a receipt useful. First, existence — proof that the output was produced at a specific time. Second, integrity — proof that the bytes haven't changed since. Third, provenance — proof of which signer, which model, which prompt produced it. A receipt missing any of the three is just a log line.

Receipts aren't new. SSL certificates notarize TLS handshakes. Code-signing systems notarize binaries. EVIDIQ Notary extends the same idea to the messiest, most malleable artifact in computing today: an LLM response. Same prompt, temperature 0.7, retry twice — you might get three different answers. The receipt doesn't promise the answer is right. It promises you can prove which answer you got, when, and from whom.

Why AI Outputs Need Notarization

Here's the thing. Logs rot. Agents get restarted, containers get replaced, prompt templates get edited, response caches get purged. Six months from now, the file that "proves" what your agent said is gone — or worse, was modified by someone with admin access and you can't tell.

Receipts solve this by moving the proof off your machine. Once an inference is notarized, the evidence lives on decentralized storage that nobody controls and nobody can quietly rewrite. The notary becomes a witness that neither party to the transaction can later disown.

This matters for three concrete failure modes we keep seeing:

• Dispute resolution — a buyer claims an agent misrepresented a result. Without a receipt, it's your word against theirs. With one, it's a signed artifact anyone can verify.
• Compliance audits — a regulator asks which model produced a specific decision in March 2026. Without receipts, you're grepping Slack. With them, you produce a hash.
• Tamper detection — an insider modifies logs to hide a breach. Receipts anchored externally expose the modification immediately, because the on-chain timestamp and the local log no longer agree.

The market for inference logs is exploding in 2026, and most of it is theater. Companies store markdown dumps in S3 and call it an audit trail. That's not tamper-evident. That's just storage.

How EVIDIQ Notary Works End to End

Walk through a single notarize_inference call and the rest clicks into place. The flow has six steps, and every one of them is auditable.

1. The calling agent POSTs a notarization request to the Notary MCP endpoint with the prompt, response, model identifier, and timestamp.
2. Notary canonicalizes the payload, computes keccak256(prompt ‖ response ‖ model ‖ timestamp), and serializes a signed report struct.
3. Notary signs the canonical report with the EVIDIQ key using EIP-191 personal_sign — the same scheme used for wallet messages, so any Ethereum tooling can recover the signer.
4. Notary uploads the raw evidence (prompt, response, signature, metadata) to 0G Storage (mainnet). 0G returns a content hash and an on-chain transaction hash (storageTx).
5. Notary returns a receipt to the caller with the canonical hash, the signature, the storage root, the storage transaction hash, and the EVIDIQ signer address.
6. The caller stores the receipt locally. The evidence itself lives on 0G forever; the caller only needs the small receipt JSON to verify later.

Here's a concrete example. A treasury agent produces this response at 14:32 UTC on March 4, 2026:

{
  "model": "gpt-5.2",
  "prompt": "Should we rebalance USDC→USDT given current depeg risk?",
  "response": "Hold. Depeg spread is 12 bps, below threshold.",
  "timestamp": "2026-03-04T14:32:11Z"
}

The canonical hash becomes 0x7a3f...e291. Notary signs it. The evidence uploads to 0G. The caller receives:

{
  "hash": "0x7a3f...e291",
  "signer": "0xEv1d1q...Notary",
  "signature": "0x9c4e...ab12",
  "storageRoot": "0x83b1...44f0",
  "storageTx": "0x1c5d...9a2b"
}

That's a notarized inference. The full EVIDIQ docs at EVIDIQ Notary docs walk through every field, including how to reconstruct the canonical hash byte-for-byte.

Worth noting: Notary never holds funds and never grants authority. It produces evidence. What you do with the evidence — settle directly, open a dispute, trigger an escrow — is your call.

Verifying a Receipt Offline

Receipt verification is intentionally offline. The whole point is that you shouldn't have to trust the notary to trust the receipt. If the notary's website goes down tomorrow, the receipt from 2026 still verifies.

Three operations, all standard library calls:

• Recompute keccak256(prompt ‖ response ‖ model ‖ timestamp) and check it equals the receipt's hash.
• Use ecrecover on the signature with the receipt's signer address; the recovered address must equal the signer field exactly.
• Pull the raw evidence from 0G Storage using storageRoot, hash it, and confirm it matches. Then check the on-chain transaction storageTx exists and is finalized.

That's it. No API key. No contact with the notary. No subscription. Anyone with the receipt and a copy of web3.py or ethers.js can verify in under fifty lines.

This is the property that makes EVIDIQ Notary composable with the rest of EVIDIQ. A receipt returned by Notary can be fed into EVIDIQ Sentinel docs as evidence when Sentinel flags a suspect agent. It can also be referenced from a smart contract dispute clause, with the on-chain storageTx as the canonical pointer. And if you're running your own EVIDIQ Operator to score sub-agents, you can require notarized outputs as a precondition — see EVIDIQ Operator docs for the integration pattern.

Trust is built by layering.

A note on what Notary does not do

Notary doesn't prove an output is correct. It doesn't prove a model is fair. It doesn't prove a prompt wasn't injected. It proves a specific string of bytes existed at a specific time, signed by a specific key. Everything stronger is downstream work — and we'll get to it in later posts.