EVIDIQ Notary: Cryptographic Receipts for Every AI Output

Picture this: an AI agent just executed a $50,000 trade on behalf of a user. The transaction cleared. Three months later, the user claims the agent hallucinated the signal and demands a refund. Whose word do you take? The agent's logs? The model's API transcript? A CSV exported from a dashboard? In 2026, none of those hold up — they are mutable, unsigned, and easy to forge. EVIDIQ Notary exists to fix exactly this.

What Is an AI Output Receipt?

An EVIDIQ Notary is a cryptographic receipt for an AI inference: a signed, timestamped proof that a specific prompt produced a specific response from a specific model at a specific moment. EVIDIQ Notary is the MCP server that issues, anchors, and lets anyone independently verify these receipts. The result is provable AI output — not just a log line.

Let's pin that down before going further. A receipt is not a screenshot. It is not a row in a Postgres table. It is not a copy of the model's chat completion JSON. Any of those can be edited, backdated, or fabricated. A real receipt has four properties, and missing any one of them makes it worthless:

• Existence — the output existed at a specific time, attested by a third party.
• Integrity — the exact bytes (prompt + response + model identifier + timestamp) have not changed since issuance.
• Provenance — the signer is identified and recoverable via EIP-191 signature recovery.
• Public verifiability — anyone, including people with no relationship to the issuer, can re-check the math and reach the same verdict.

EVIDIQ Notary produces all four. You call it, it signs, it anchors, and you walk away with a receipt you can hand to a court, an auditor, a counterparty, or a future version of yourself.

Why AI Outputs Need Notarization

Here's the thing: agents are not chatbots anymore. In 2026, a typical autonomous agent will fire thousands of inferences per day — for routing decisions, code generation, tool selection, summarization, and summarization-of-summarization. The output of any one of those calls can move money, sign messages, trigger contracts, or get pasted into a regulatory filing. Almost none of it is provable.

Consider three failure modes that show up in production agent fleets constantly:

1. The silent rewrite. A model's output is captured, then a developer tweaks a system prompt, and a new "log" is written. The old one is gone. There is no way to tell which inference actually happened.
2. The denied action. A user insists the agent never warned them about a risk. The agent insists it did. There is a transcript, but transcripts are easy to forge. Disputes go nowhere.
3. The compliance gap. An auditor asks for proof that an LLM-based KYC check produced a specific risk score at a specific time. The vendor can produce a database row. The auditor asks if it was tampered with. Nobody can answer.

A cryptographic receipt answers all three. "Did this model say this?" — yes, here is the signed response. "When?" — here is the timestamp. "Was it altered?" — recompute the hash yourself. That is the entire point of notarization: turning mutable model output into tamper-evident evidence. Our team built EVIDIQ Notary because we kept running into the same trust gap when deploying agents in our own pipelines, and the tooling to close it simply did not exist.

We have already wired EVIDIQ Notary into the broader EVIDIQ trust stack — it complements the trust score returned by EVIDIQ Sentinel docs and the orchestration surface in EVIDIQ Operator docs. The score tells you whether to engage an agent; the receipt tells you what an agent actually said. Both are useless without the other.

How EVIDIQ Notary Works End to End

Let's walk a single notarize_inference call from request to receipt. The whole flow takes a few seconds and leaves the caller with a verifiable artifact.

The caller (an agent, a script, or an MCP host) sends a JSON-RPC request to the EVIDIQ Notary MCP endpoint with three fields: prompt, response, and model. If the call is unauthenticated, the server returns an HTTP 402 challenge with the x402 v2 accepts[] payload — settlement scheme "exact", asset USDT0, network X Layer. Pay, retry with the X-PAYMENT header, and the server proceeds. The math is simple: every paid call is its own proof that someone had economic skin in the game.

Once the request is paid and validated, the server does the following, and the order matters:

1. Compute digest = keccak256(prompt || response || model || timestamp).
2. Sign digest with the EVIDIQ operator key using personal_sign — that's EIP-191, recoverable by anyone with the signed bytes.
3. Upload the canonical receipt bundle (prompt, response, model, timestamp, digest, signature) to 0G Storage on mainnet.
4. Receive back storageRoot (the Merkle root containing the receipt) and storageTx (the on-chain transaction hash anchoring the upload).
5. Return a receipt object to the caller containing digest, signature, signer, timestamp, storageRoot, and storageTx.

A concrete example. An agent calls:

{
  "prompt": "Classify transaction tx0xabc... as fraud / not fraud",
  "response": "fraud",
  "model": "glm-5.2"
}

The returned receipt might look like:

{
  "digest": "0x9f3c…",
  "signature": "0x12ab…",
  "signer": "0xEv1d1Q…",
  "timestamp": "2026-03-14T18:22:07Z",
  "storageRoot": "0xa1b2…",
  "storageTx": "0x6f7e…"
}

That's it. The caller stores those six fields anywhere — a database, an IPFS pin, a hard drive. They never need to call EVIDIQ Notary again to prove that inference happened. The receipt is self-contained. For full schema details, the EVIDIQ Notary docs cover field-level semantics, including how the timestamp is bound into the digest so it cannot be silently rewritten post-signature.

Verifying a Receipt Offline

The interesting part is what happens six months later, in a courtroom, in a smart-contract dispute, or on an auditor's laptop. The verifier doesn't call EVIDIQ Notary. They don't need an API key. They don't even need to trust that the service still exists. The verification is pure math:

1. Concatenate prompt || response || model || timestamp in the documented order.
2. Compute keccak256 over those bytes. Compare against digest. If it matches, the content has not been altered.
3. Take signature and run ecrecover — EIP-191 recovery — to recover the signing address. Compare against signer. If it matches, EVIDIQ actually signed this exact digest.
4. Fetch the receipt bundle from 0G Storage using storageRoot. Confirm the bundle's hash sits inside the Merkle tree referenced by storageTx. If it does, the receipt was anchored on-chain at some point after storageTx was mined.

Every step is deterministic. Same inputs, same outputs, forever. You don't need to ask us, ask the chain, or ask anyone. Anyone can re-fetch the evidence from 0G Storage, re-hash it, and recover the signer — that's the property that makes a receipt worth more than a screenshot.

We deliberately route EVIDIQ Notary through EVIDIQ docs and the EVIDIQ Sentinel docs trust-score layer — receipt verification and trust scoring are decoupled by design. The score is computed from identity, capability, reputation, and risk. The receipt is computed from raw inference bytes. Neither depends on the other's server staying online.