AI Output Notarization on 0G Storage: Inside the EVIDIQ Notary Pipeline

Picture this: an autonomous trading agent flags a market, an execution agent takes the trade, and 90 seconds later the price moves. The integrator asks the obvious question — what did the model actually output, and when? Without a tamper-evident receipt, you're arguing over screenshots. With one, the answer is a hash.

This is the problem we built EVIDIQ Notary to solve. It's the layer that turns every inference into a signed, anchored, independently verifiable artifact. No database the operator can quietly edit, no log the model provider can rewrite. Just a receipt on 0G Storage that anyone can re-fetch and re-hash for the rest of 2026 and beyond.

What 0G Storage Anchoring Means for AI Outputs

AI output notarization is the practice of producing a tamper-evident receipt for an AI inference — a signed, timestamped record that pins the exact input, output, and model context to durable decentralized storage. EVIDIQ Notary implements AI output notarization by hashing each receipt, uploading it to 0G Storage Aristotle (chain 16661), and returning the on-chain tx as public proof.

When we say "anchoring," we mean something specific. The receipt itself isn't the chain — the receipt is a JSON document that lives on 0G Storage's decentralized data layer, and the chain only carries a commitment to that document. Anyone holding a tx hash can pull the receipt back, recompute its keccak256, and confirm the chain commitment matches what they're looking at. If a single byte changed, the hash wouldn't match.

Why does this matter for AI agents? Because an inference is the cheapest thing in the world to dispute and the hardest thing in the world to prove. A prompt and a completion can be rephrased, replayed, or quietly edited after the fact. An anchored receipt cannot. That's the shift AI output notarization brings — from "trust the operator's log" to "verify the chain yourself."

If you're new to the broader EVIDIQ stack, the EVIDIQ docs walk through how Notary slots in next to Sentinel (the live endpoint probe) and Operator (the orchestration layer). Notary doesn't make decisions — it makes them auditable.

The Upload Flow: ZgFile to 0G Mainnet

The actual upload path is short, which is intentional. Here's roughly what happens when Notary hands a receipt off to 0G:

1. We serialize the receipt to canonical JSON — input hash, output, model identifier, timestamp, signer, optional agent_id, optional EVIDIQ trust score snapshot.
2. The JSON lands on disk and gets wrapped via ZgFile.fromFilePath(...) from the @0gfoundation/0g-ts-sdk.
3. We call indexer.upload(zgFile) with a hard 30-second budget. Under normal load this settles in under five.
4. The indexer returns two things: a storageRoot (the merkle root pinning the receipt inside 0G Storage) and a storageTx — the on-chain transaction we hand back to the caller.

When the primary indexer is congested or returns a non-2xx inside the budget, we fall back to a turbo indexer endpoint. Same SDK, different RPC. The caller never sees the retry — they just get a storageTx that's already confirmed.

Here's the thing about that storageRoot: it's the receipt's true anchor. The on-chain tx proves a commitment was made at a specific block; the storageRoot is what you'd hand someone if you wanted them to verify the bytes themselves. Anyone with both can fetch the file, recompute the root, and prove the inference hasn't been altered.

Want to wire this into your own agent? The EVIDIQ Notary docs include working TypeScript snippets and a reference implementation in the EVIDIQ open-source repos.

Why Decentralized Storage Beats a Database for Audit Trails

A traditional audit log is, at the end of the day, a database someone else controls. The DBA can rotate rows. The SaaS vendor can run a "data correction." The hosting provider can lose the cluster. None of these failure modes require malice — the log just stops being trustworthy.

Anchoring on 0G Storage flips that around. The receipt lives in a decentralized data layer whose proof-of-storage mechanism is what makes tampering detectable, and the on-chain tx is the timestamp. To falsify an inference after the fact, an attacker would need to rewrite the merkle root inside an already-finalized block — something the network's storage providers, distributed across independent operators, make economically uninteresting to attempt.

For AI audit trails this matters more than it does for, say, financial ledgers. A bank ledger has reconciliation and regulators. An AI agent's inference log has — until now — basically nothing. AI output notarization gives it a substrate.

• Centralized log: rotated row → no record → "we can't reproduce that inference."
• 0G Storage anchor: rotated row → merkle root mismatch → anyone with the tx hash sees the lie.

Worth noting: the receipt doesn't have to live on 0G Storage. Notary is designed so a chain like X Layer could anchor a hash commitment just as well. We picked 0G Storage because it's purpose-built for the data-availability problem and gives us cheap, verifiable persistence. The full reasoning lives in our EVIDIQ Notary docs.

Six Tools, Four Free — the Notary MCP Surface

Notary ships as an MCP server, and the surface is deliberately small. Six tools, four of them free:

1. notarize_inference — takes one receipt, hashes it, anchors it to 0G Storage, returns the on-chain tx. Paid (x402).
2. notarize_batch — takes up to 100 receipts and returns a single batch anchor. Paid (x402).
3. verify_attestation — given a tx hash and a payload, recomputes the keccak256 and confirms the on-chain root matches. Free.
4. get_receipt — fetches a previously stored receipt by tx hash. Free.
5. notary_stats — counters, uptime, indexer health. Free.
6. notary_pubkey — returns the EVIDIQ signing key so anyone can verify the EIP-191 signature on a receipt out-of-band. Free.

The two paid tools (notarize_inference, notarize_batch) are gated by x402 because each call writes to 0G Storage mainnet and the network has a real cost. Verification (verify_attestation, get_receipt) is free because pulling public data and re-hashing it has no marginal cost, and we'd rather you do it than not. The x402 challenge follows v2 with accepts[].amount, settled on X Layer in USDT0 via EIP-3009 transferWithAuthorization.

In practice this means an integrator can ship a full verification flow — fetch receipt, re-hash, check signature, cross-reference the tx — without paying EVIDIQ anything. Cost only shows up when you actually want to anchor a new receipt.

If you're integrating this from inside an agent runtime, the EVIDIQ Operator docs show how Operator schedules Notary calls alongside Sentinel probes; if you're verifying from outside, the EVIDIQ Sentinel docs cover the agent-side counterpart.