AI Output Notarization, Anchored: How EVIDIQ Notary Writes Receipts to 0G Storage

Your agent just made a $50,000 decision. It used an LLM to score a counterparty, generated a recommendation, and committed to a transaction. Three months later a regulator asks: "Why did your system approve that loan?" If your only record is a log line in a Postgres table, you're in trouble — because you can't prove it wasn't edited. This is exactly the gap that AI output notarization closes at EVIDIQ.

We've shipped EVIDIQ Notary as the durable evidence layer for every inference we score. Here's how it works under the hood, why we picked 0G Storage over a centralized backend, and what you can do with it today.

What 0G Storage Anchoring Means for AI Outputs

AI output notarization is the practice of producing a tamper-evident receipt for an AI inference — capturing the model id, the input hash, the output hash, the trust score, and a timestamp — then anchoring that receipt on decentralized storage so it cannot be retroactively rewritten. EVIDIQ Notary anchors every inference receipt on 0G Storage Aristotle mainnet (chain id 16661), returning an on-chain transaction hash anyone can re-fetch and verify.

Most "audit logs" are not auditable. They're mutable rows in a database owned by the same entity that produced the inference. If that entity has an incentive to rewrite history — to hide a bad call, a hallucination, a bias incident — they can. A notarized receipt is different: it leaves the operator's trust boundary entirely and lands on a storage network whose root is committed on-chain.

Here's the thing: anchoring matters most when there's a dispute. Two agents disagree about what an LLM said last Tuesday. A user claims the model was poisoned. An insurer wants proof the inference used a specific model version. In every one of these cases, the only useful evidence is something the operator cannot edit. We designed Notary around that requirement.

The receipt itself is a small JSON object: a keccak256 hash of the canonical inference payload, the EVIDIQ verdict (proceed, proceed_with_escrow, caution, do_not_proceed), the trust score broken into its four components, and a signature under EVIDIQ's EIP-191 key. That JSON gets uploaded to 0G Storage and its merkle root lands in a transaction on Aristotle. The on-chain tx is the proof; the JSON on 0G is the evidence; the signature is the accountability layer.

The Upload Flow: ZgFile to 0G Mainnet

Let me walk you through what happens when you call notarize_inference.

We take the canonical inference payload — model id, prompt hash, output hash, score components, verdict — and serialize it deterministically. Same input bytes, same output bytes, every time. We keccak256-hash the canonical bytes to get the receipt's identity. Then we build a receipt object that bundles the payload, the hash, the timestamp, and the EVIDIQ signature.

The interesting part is the upload. We use @0gfoundation/0g-ts-sdk to wrap the receipt JSON in a ZgFile.fromFilePath call, which prepares it for the network's erasure-coded chunks. Then we call indexer.upload(zgFile) against the 0G Storage indexer endpoint. The SDK returns two values we surface to the caller: a storageRoot (the merkle root the indexer computed for the file) and a storageTx (the on-chain transaction hash anchoring that root on Aristotle mainnet).

A few operational details worth knowing:

1. We budget 30 seconds for the upload, then fall back to the turbo indexer. Turbo trades decentralization for latency and is useful when you're notarizing a hot path that can't wait.
2. The merkle root is what you'd compare against if you re-downloaded the receipt and re-hashed it locally. Mismatch means the evidence was tampered with.
3. The on-chain tx is independently verifiable on any Aristotle block explorer. No EVIDIQ permission needed.

This is why we picked 0G Storage specifically. It's not just "decentralized file storage" — it's a network where every uploaded file gets a deterministic merkle root published on-chain, and the same SDK handles both the upload and the verification path. The full pipeline is documented in our EVIDIQ Notary docs.

Why Decentralized Storage Beats a Database for Audit Trails

A traditional audit log lives in a database you control. That's fine for observability. It's catastrophic for accountability. The math is brutally simple:

• Centralized log: edit one row, change one inference's "recorded" outcome. No one outside your org can detect it.
• 0G-anchored receipt: edit the JSON on 0G, the merkle root changes, and the on-chain tx hash no longer matches the recomputed root. Anyone with 30 seconds and a CLI can prove tampering.

The asymmetry is the whole point. When a third party — a counterparty agent, a court, an auditor — needs to verify what your model said, they shouldn't have to trust your database. They should be able to fetch from a network they don't own, recompute the hash, and confirm the signature. That's the standard Notary meets.

We've also seen the operational case: agent-to-agent transactions where neither side trusts the other's logs. A receipt on 0G Storage is the neutral ground. Both parties can point to the same tx hash on Aristotle and agree on what happened. This matters even more as x402-based agent commerce scales — see the EVIDIQ homepage for how trust scores feed into payment decisions.

The other reason we went decentralized: durability. 0G Storage is designed for long-term persistence with replicated erasure coding across independent node operators. A receipt you notarize today should still be retrievable in 2030. Your Postgres backup from 2026 might not be.

Six Tools, Four Free — the Notary MCP Surface

Notary ships as an MCP server alongside our trust-score tools. There are six tools on the surface, split by access model:

• notarize_inference — paid (x402). Single inference receipt upload + anchor.
• notarize_batch — paid (x402). Up to 100 receipts in one call, cheaper per-inference.
• verify_attestation — free. Given a tx hash and a payload, recompute the merkle root and confirm the signature.
• get_receipt — free. Fetch the raw receipt JSON from 0G by storage root.
• notary_stats — free. Aggregate counters — total notarized, by chain, by verdict — for monitoring.
• notary_pubkey — free. The EVIDIQ signing pubkey, for anyone who wants to verify a signature locally.

The two paid tools (notarize_inference and notarize_batch) are gated by x402 — exact scheme, EIP-3009 transferWithAuthorization, settled on X Layer in USDT0. The 402 challenge follows x402 v2 with accepts[].amount. The free tools are open and rate-limited only by abuse prevention. Our EVIDIQ docs cover the exact price points and rate limits.

If you're already using the trust-score side of EVIDIQ, pair it with the verifier workflow from EVIDIQ Sentinel docs. Sentinel is the piece that calls Notary under the hood every time it produces a score; if you're building your own verifier, you can do the same.

For agent operators who want to understand how notarized receipts flow into authorization decisions, the EVIDIQ Operator docs walk through the full lifecycle — request, score, notarize, act.