AI Output Notarization: How EVIDIQ Notary Anchors Inferences on 0G Storage

Your agent just spent $4.20 on an inference, made a decision that routed $18,000 through an escrow, and logged a one-line JSON receipt to disk. Six weeks later, the counterparty denies the decision was ever made. The receipt file is right there on your laptop — but so what? You're holding a string in a database you control. That is the entire audit-trail problem in one sentence, and it's exactly why we built AI output notarization as a first-class primitive inside EVIDIQ.

Most teams treat inference logs as an internal observability concern. We disagree. Once an autonomous agent is moving money, signing attestations, or rejecting counterparties, the receipt is the product. It has to outlive the process that produced it and resist silent editing by anyone — including the team that wrote the agent. That's what the EVIDIQ Notary docs deliver: a tamper-evident seal on every inference, anchored on decentralized storage.

What 0G Storage Anchoring Means for AI Outputs

AI output notarization is the act of sealing an AI inference receipt on decentralized storage so it cannot be silently edited. EVIDIQ Notary anchors every receipt to 0G Storage Aristotle (chain 16661), returning a merkle root and a mainnet transaction hash that anyone can re-fetch and re-hash to confirm integrity.

So what is "anchoring" actually doing? Three concrete things at once. First, it pins the canonical bytes of your receipt — the exact JSON, not a paraphrase — to a content-addressed store. Second, it returns a merkle root that summarizes the chunk. Third, it writes that root on a real chain, so the proof isn't just "we stored it" but "this transaction on 0G mainnet committed to this root, and here's the tx hash anyone can paste into a block explorer." That's the difference between a database row and a notarized record.

Here's the thing most people miss: a wallet balance alone tells you nothing about whether the AI that produced a decision was the AI you think it was. We built EVIDIQ's scoring formula to weigh identity, capability, reputation, and risk — but none of that matters if the underlying receipts can be quietly rewritten. Decentralized anchoring closes that gap.

The choice of 0G Storage Aristotle as the substrate wasn't accidental. It offers data-availability guarantees that a Postgres table fundamentally cannot, settlement on a real L1, and an SDK that lets us script the entire upload in a single TypeScript call. For an audit trail that has to survive lawsuits, custody transfers, and the death of the company that produced it, that combination is hard to beat. Tamper-evident is not a marketing word here — it's the literal failure mode we're designing against.

The Upload Flow: ZgFile to 0G Mainnet

The mechanics are simpler than the cryptography implies. When our Notary MCP server receives a notarize_inference call, here's exactly what happens — the AI output notarization pipeline, end to end:

1. We serialize the receipt — inputs, output, model id, prompt hash, trust score, timestamp, signing key — into canonical JSON. No floats, no extra whitespace, no undefined keys.
2. The JSON is written to a temp file and wrapped via ZgFile.fromFilePath from @0gfoundation/0g-ts-sdk. This handles chunking and merkle tree construction.
3. indexer.upload(zgFile) streams the file to the 0G Storage node. We hold a 30-second timeout budget for the whole operation — anything slower than that and we fall back to the turbo indexer endpoint.
4. The SDK returns a tuple: storageRoot (the merkle root committed in the chunk) and storageTx (the on-chain mainnet transaction hash).
5. Both values are folded back into the receipt metadata and returned to the caller, ready to be persisted wherever they like.

The turbo indexer fallback isn't decorative. In our internal testing during early 2026, roughly 1 in 40 uploads hits a slow path on the standard indexer, and a 30-second wall-clock budget without a fallback means notarization becomes the bottleneck of an agent's hot loop. Two indexer endpoints, same SDK, identical receipt — the caller never knows which one served them.

One subtlety worth naming: the merkle root is what makes this useful. If someone later claims the receipt was tampered with, you don't have to trust our server. You re-fetch the file by tx hash, recompute the merkle root, and compare. Mismatch means the bytes changed. Match means the bytes are exactly what we sealed. That's the entire audit story in one comparison.

Why Decentralized Storage Beats a Database for Audit Trails

A central database audit log has a fundamental problem: it's controlled by whoever owns the database. They can edit a row, delete a row, or quietly migrate the schema. Even with cryptographic chaining inside the database, you're trusting the operator — and the operator is often a counterparty to the dispute.

Here is where 0G Storage flips that. The transaction hash is public. The data is replicated across the network's storage nodes. Once the merkle root is committed on mainnet, no one — not us, not 0G, not a subpoena-holding party — can rewrite it without that change being obvious. Anyone with the tx hash can re-pull the file and re-hash it. If the bytes don't match what was originally committed, the receipt is dead.

The practical implication: when a dispute lands six months later and someone says "the agent never said that," you don't argue semantics. You pull the tx hash out of your local log, hit a public 0G endpoint, and the JSON speaks for itself. We've watched this pattern turn a 6-week legal back-and-forth into a 20-minute Slack thread in pilot integrations.

For agents operating under the EVIDIQ Sentinel docs framework, this is even more load-bearing. Sentinel routes an agent's actions through risk-tiered recommendations — proceed, proceed_with_escrow, caution, do_not_proceed. Each tier is a decision someone might later contest. Anchoring the inference receipt that produced the tier means the recommendation is reproducible and falsifiable, not a vibe.

We deliberately did not build our own storage network. Reinventing data availability is a fool's errand in 2026. The point of AI output notarization is the anchoring primitive, not the bytes-on-disk primitive.

Six Tools, Four Free — the Notary MCP Surface

The Notary MCP server exposes six tools to any agent or operator that connects to it. Four are free, two are paid per-call via x402 — and the boundary is drawn where the operation starts costing us real money on 0G mainnet. Paying for storage on a real L1 isn't free, so we mark the calls that actually hit 0G bandwidth as paid and keep the verification primitives open.

Free tools:

• notarize_inference — seals a single inference receipt on 0G Storage and returns the storageRoot + storageTx.
• notarize_batch — bundles up to 50 receipts into one anchored submission for cost amortization.
• verify_attestation — re-fetches a receipt by tx hash, recomputes the merkle root, and confirms the EVIDIQ signature on the report.
• notary_pubkey — returns the active EVIDIQ signing key so verifiers can independently recover the signer.

Paid tools (x402, priced per call):

• get_receipt — full canonical receipt including AI risk analysis, model metadata, and any operator-added fields. Bigger payload, more 0G bandwidth.
• notary_stats — aggregated counters across a time window; requires extra indexer queries that we don't subsidize.

The split is intentional. Anyone — including a competitor — can verify a notarized receipt for free, forever. That's the point. EVIDIQ is the trust layer, not the toll booth. The two paid calls are the ones where we're doing more than a single merkle check, and the x402 challenge lets the caller settle in USDT0 on X Layer without an account on our side.

If you're wiring this into an agent runtime, the EVIDIQ Operator docs walk through the MCP handshake and the x402 payment flow end-to-end. You can also browse the open-source surface in our EVIDIQ docs.