EVIDIQ Notary: Cryptographic Receipts for Every AI Output

What Is an AI Output Receipt?

Your agent just filed a compliance report at 03:47 UTC. Three hours later, the counterparty claims the model never said that. You grep the logs — empty. The model vendor's API returned 200, sure, but no one kept the bytes. Now imagine pulling a single JSON receipt from your storage layer that proves the prompt, the response, the model, and the exact second it happened. That's what an AI output receipt is. And that's what EVIDIQ Notary mints.

An EVIDIQ Notary receipt is a cryptographically signed, timestamped proof that a specific AI output — prompt, response, and model identifier — existed at a moment in time and has not been altered. Issued by the EVIDIQ Notary MCP server, the receipt bundles an EIP-191 signature, a keccak256 hash, and a Merkle anchor on 0G Storage that anyone can verify offline.

Three properties define a real AI output receipt, and most "logging" tools fail at all three:

• Existence — the bytes actually existed at the claimed timestamp, not in some imagined future past.
• Integrity — not a single character of prompt or response has changed since the receipt was minted.
• Provenance — a specific, verifiable signer (an EVM address) stands behind the claim. Anyone can recover it.

A traditional document notary witnesses a wet-ink signature. Our receipt does the same job for a model inference: a third-party assertion that this exact output, from this exact model, signed by this address, was anchored at this block height. We issue the receipt, anchor it on 0G Storage, and let you walk away with something you can defend in a dispute without ever calling us again.

Why AI Outputs Need Notarization

The volume problem is already here. A single mid-size agent fleet — say, twenty-five services doing summarization, classification, and structured extraction — produces somewhere between two and eight million LLM calls a day. Almost none of them are provable. Logs are mutable. Vendor dashboards are screenshot bait. Even signed responses from the model API only prove the vendor signed them, not that you saw them at a particular second.

Three questions show up in every audit, dispute, or insurance claim:

1. Did this model actually produce this output?
2. When — to the second — was it produced?
3. Has anyone touched it since?

A receipt answers all three. Without one, you're arguing from vibes.

The failure modes we keep seeing in the wild:

• The vendor's status page says 200 OK, but a counterparty denies the model ever emitted the text. No third-party anchor exists to settle it.
• Logs were rotated, the on-call engineer left, and now the bytes are gone. The dispute is lost before it starts.
• A subtle prompt-injection altered the response between the model and the consumer. Nobody can prove what the model actually returned.
• A training-data provenance request arrives asking which model produced a summary a year ago. Storage costs money; logs were trimmed.
• An auditor wants a cryptographic trail, not a vendor screenshot. There isn't one.

We've shipped the EVIDIQ Notary MCP tool because we got tired of watching teams lose arguments they should have won. A receipt is cheap — a few hundred milliseconds of overhead and a fraction of a cent in storage — and it converts a "he said, she said" into a verifiable artifact.

How EVIDIQ Notary Works End to End

Let's walk a single notarize_inference call. You'll see the request, the payment challenge, the signature, the storage anchor, and the receipt you get back. No hand-waving.

1. The caller — your agent, or a thin wrapper in your service — invokes notarize_inference on the EVIDIQ Notary MCP server. The payload is plain JSON: {prompt, response, model, timestamp, metadata}.
2. The server returns an HTTP 402 Payment Required challenge in x402 v2 format (accepts[].amount, scheme exact, asset USDT0 on X Layer). No receipt is minted until payment settles.
3. The caller signs an EIP-3009 transferWithAuthorization for the quoted amount and resubmits. Settlement happens on X Layer in USDT0.
4. The server computes keccak256(prompt ‖ response ‖ model ‖ timestamp ‖ metadata) and constructs the canonical receipt payload.
5. The server signs the canonical payload with the EVIDIQ notary key using EIP-191 (personal_sign style). The signing address is public — anyone can recover it from the signature.
6. The receipt is uploaded to 0G Storage (mainnet). The upload returns a storageRoot (Merkle root of the chunk set) and a storageTx (the on-chain anchor transaction hash).
7. The caller receives the final receipt JSON: receiptId, digest, signature, signer, model, timestamp, storageRoot, storageTx, and the x402 settlement tx.

Concrete shape of the returned receipt:

{
  "receiptId": "0x9f3a…",
  "digest": "0x7c1d… (keccak256 of canonical payload)",
  "signer": "0xEVIDIQ…",
  "signature": "0xab12… (EIP-191)",
  "model": "gpt-oss-120b",
  "timestamp": "2026-04-18T03:47:11Z",
  "storageRoot": "0x4e…",
  "storageTx": "0x7a… (0G Storage mainnet tx)",
  "x402SettlementTx": "0x3c… (X Layer USDT0)"
}

That's the whole flow. The cryptographic proof is the EIP-191 signature over the canonical digest, plus the on-chain anchor that places the receipt at a known block height on 0G Storage. The x402 payment is the economic skin-in-the-game that prevents spam and lets the service stay paid without a subscription. We deliberately keep the signer key separate from any user-facing key, and the docs at EVIDIQ Notary docs walk through the exact canonicalization rules so you can reproduce the digest byte-for-byte.

Verifying a Receipt Offline

Here's the part that matters most: you do not need us to verify a receipt. The notary is an issuer, not a gatekeeper. Anyone holding the receipt JSON can re-derive everything cryptographically and confirm it without a network call, an API key, or our blessing.

The offline verification path is three steps:

• Reconstruct the canonical payload exactly as the docs specify — fixed-field ordering, UTF-8 NFC, no trailing whitespace. If your reconstruction differs from the stored digest, you have a tampering signal.
• Hash it. keccak256(payload) should equal receipt.digest. Mismatch means somebody edited a byte.
• Recover the signer. ecrecover(digest, signature) returns the EVM address that produced the EIP-191 signature. It should equal receipt.signer, and that address should match the published EVIDIQ Notary signing key. Mismatch means the signature is forged or the signer rotated without disclosure.

Beyond the signature, you can independently verify the anchor:

• Pull receipt.storageTx from a public 0G Storage explorer.
• Walk the Merkle proof from the storage contract up to receipt.storageRoot.
• Confirm the storageRoot matches what the explorer reports for that tx.

If every check passes, the receipt is real, intact, and was anchored on 0G Storage at the block height recorded in the tx. No contact with the notary service required. This is the property that makes the receipt usable in court, in audit, and in cross-organization disputes — the verifier does not need to trust the issuer's availability.

For agents that need a higher-level verdict on top of this — checking identity, declared capability, and reputation before even invoking a third-party model — the workflow pairs naturally with EVIDIQ Sentinel docs and EVIDIQ Operator docs. Sentinel decides whether to call an agent at all; EVIDIQ Notary proves what came back. Operator handles the policy glue around both. The full surface is documented at EVIDIQ docs, and you can read more about the wider trust stack on EVIDIQ.