EVIDIQ Notary: Cryptographic Receipts for Every AI Inference

Your agent just shipped a million inferences. A customer claims one was wrong. Another claims it never happened. You pull logs. The logs say whatever the database said this morning.

Who actually wins that argument?

That's the gap EVIDIQ Notary fills. We built it because every other layer of the AI stack — the model, the inference server, the agent loop — produces outputs that vanish into a stream. Nothing is provable. Nothing is portable. Nothing survives a subpoena or a smart-contract dispute without a trusted middleman holding the logs.

Notary is the smallest piece of infrastructure we ship, and arguably the most important one. It turns "the model said X" into "here is a signed, anchored, independently verifiable proof that the model said X."

What Is an AI Output Receipt?

EVIDIQ Notary is the cryptographic receipt layer for AI inferences. It hashes the prompt, response, and model identity into a canonical digest, signs it with an EIP-191 signature, and anchors the evidence on 0G Storage. The returned receipt lets anyone — even years later — prove the output existed, was not altered, and came from the claimed model.

A receipt, at its core, is a tiny bundle of three facts plus a signature:

1. Existence — this exact prompt produced this exact response at this timestamp.
2. Integrity — neither side has been tampered with since.
3. Provenance — the signer is the entity you expected (an EVM address, a model registry entry, an agent identity).

Notary issues them as a single MCP tool call. You hand it the inference, it hands you back a JSON receipt with a storage root, a transaction hash, and an EIP-191 signature. Anyone holding the receipt can re-derive the hash, recover the signer, and check the Merkle inclusion proof against 0G Storage — without ever talking to the notary again.

Why AI Outputs Need Notarization

[IMAGE_PROMPT: A flat 3D-style developer illustration showing a stylized AI inference output (a glowing speech bubble with a circuit pattern) trapped inside a transparent glass vault, while a small signed receipt with a cryptographic seal and a storage hash chip emerges to the right. Background of soft blockchain nodes connected by light lines. Modern tech aesthetic, cool indigo and electric teal gradient palette, no text, no real brand logos.]

Here's the uncomfortable math. In 2026, a single mid-sized AI agent service might produce tens of millions of inferences a day. Almost none of them carry any proof that they happened. The only record lives in the vendor's database, which the vendor controls, which the customer has no way to audit beyond "trust us."

Three failure modes hit constantly:

• Disputes — "Your model said the contract was safe" / "It never said that." Without a receipt, it's he-said-she-said and a lot of legal fees.
• Compliance audits — Regulators and enterprise buyers want a verifiable trail of model outputs. Vendor logs are not a trail. Cryptographic receipts are.
• Agent-to-agent settlements — If agent A paid agent B for an inference, and the result was garbage, who arbitrates? You need a third-party-verifiable artifact that neither side controls.

This isn't theoretical. We watched teams try to settle disputes with screenshot exports of chat logs. Honestly? A screenshot is not evidence. A signed receipt is.

EVIDIQ Sentinel docs cover the runtime side of this — Sentinel is what watches an agent's traffic and flags anomalies. Notary sits one layer over: Sentinel flags a bad inference, EVIDIQ Notary proves it actually happened.

How EVIDIQ Notary Works End to End

Walk a single notarize_inference call. Concrete example, no hand-waving.

Your agent calls the MCP tool notarize_inference with three fields — the prompt, the response, and a model identifier string. That's the whole input.

What happens server-side, in order:

1. The server canonicalizes the input: keccak256(abi.encode(prompt, response, model, timestamp)). Same canonicalization every time, deterministic across implementations, so verification is reproducible.
2. It signs the digest using EIP-191 over the EVIDIQ Notary key. The signature is recoverable — anyone holding the digest can recover the signer address from (signature, digest) without a key lookup.
3. It packages the full evidence payload — prompt, response, model, timestamp, signature — and uploads it to 0G Storage (mainnet). 0G returns a content hash and an on-chain transaction hash.
4. It returns a JSON receipt: { digest, signature, signer, timestamp, storageRoot, storageTx, model }.
5. If the caller asked for an AI risk analysis pass, the receipt additionally references a 0G Compute run (provider address + request id) — optional, and only emitted when the receipt is being attached to a trust score.

The whole call is pay-per-use via x402 (HTTP 402, scheme exact, EIP-3009 transferWithAuthorization, settled on X Layer in USDT0). No subscription, no API key escrow, no metered billing surprises.

So the artifact you get back looks roughly like:

{
  "digest": "0x9f3a…",
  "signature": "0x7c2b…",
  "signer": "0xEv1d1q…",
  "timestamp": 1735689600,
  "model": "gpt-x-2026q1",
  "storageRoot": "0xab12…",
  "storageTx": "0x5f0e…"
}

One call, one receipt, one verifiable artifact. Anything you can do with a signed JSON, you can do with this — feed it to a dispute contract, attach it to an invoice, paste it into an audit trail.

Verifying a Receipt Offline

[IMAGE_PROMPT: A flat 3D-style developer illustration of a magnifying glass hovering over a glowing digital receipt floating above a transparent blockchain surface. The receipt shows a hash string fragment, a wax-style cryptographic seal, and a tiny Merkle tree icon with green checkmarks. Background: subtle grid pattern, slate and mint color palette, modern tech aesthetic, no text, no real brand logos.]

Here's the part that matters most, and the part most teams under-invest in: verification must work without the notary.

If you can't verify offline, your "receipt" is just a vendor-side assertion with extra steps. That's the whole game. We built EVIDIQ Notary so verification is a pure function: inputs are the receipt JSON and the evidence payload, outputs are pass/fail plus the recovered signer.

A verifier — your code, an auditor's laptop, a smart contract in Solidity — does three things:

• Recompute the digest. keccak256(canonicalize(prompt, response, model, timestamp)). If the recomputed digest doesn't equal receipt.digest, the receipt is forged. Stop.
• Recover the signer. ecrecover(digest, signature) returns the address that signed. Compare to receipt.signer. If it doesn't match, the signature was made by someone else. Stop.
• Check the Merkle proof. The evidence payload was committed to a specific storageRoot on 0G Storage. 0G returns a Merkle inclusion proof; verify that path-receipt-included. If it does, the evidence existed on-chain at the timestamp.

If all three pass, you have a self-contained proof that the inference happened, was not altered, and was signed by the address you expected. No API key. No account. No contact with EVIDIQ. No trust assumption beyond the EVM signature scheme and 0G Storage's inclusion proofs.

This is also why the Notary's pricing model doesn't matter for verification economics. The notary could disappear tomorrow, charge a million dollars per call, or be run by your worst enemy — and an honest receipt would still verify identically.

Adjacent to this sits the trust score layer. When you call verify_agent, EVIDIQ returns a 0–100 score with an explicit recommendation (proceed, proceed_with_escrow, caution, do_not_proceed). The receipt ties that score back to a specific inference, so the score isn't a vague reputation — it's anchored to an artifact you can re-check anytime. The full operator workflow — including how a Notary receipt feeds into your dispute contract — lives in the EVIDIQ Operator docs. The deeper protocol spec, including the canonicalization rules and the x402 challenge format, is in the EVIDIQ Notary docs.