How EVIDIQ Notary Anchors AI Output Notarization Receipts on 0G Storage

What 0G Storage Anchoring Means for AI Outputs

AI output notarization is the practice of cryptographically sealing an AI model's inference — the prompt, the response, the model id, and a timestamp — into a tamper-evident receipt anchored on decentralized storage. EVIDIQ Notary does exactly this by uploading a canonical JSON receipt to 0G Storage Aristotle (chain 16661) and returning a verifiable on-chain transaction hash.

Picture this: your agent ships a recommendation, the counterparty acts on it, and six weeks later somebody asks — "what exactly did the model say, who ran it, and can you prove it?" If the answer is "we have it in our logs somewhere," you have a problem. Logs get rotated, databases get pruned, and trust quietly decays.

In 2026, with autonomous agents settling payments, signing contracts, and adjudicating trades on behalf of humans, the question isn't whether the inference happened — it's whether you can prove it to a stranger without trust pinging back to your infrastructure.

This is the gap AI output notarization fills. Instead of trusting a vendor's promise that an inference happened, you anchor a cryptographic receipt that anyone with the transaction hash can independently re-fetch and re-hash years later. No vendor cooperation required. No platform-specific API. Just a hash, a chain, and the math.

EVIDIQ's notary layer does this by leaning on 0G Storage — specifically 0G Storage Aristotle on chain 16661 — as the durability substrate. We picked 0G because the cost-per-byte model lets us anchor full evidence payloads (canonicalized JSON, prompt, response, model id, timestamp, and signature) without an enterprise storage budget. The receipt lands on mainnet, gets a real on-chain tx, and from that point forward it is a public artifact.

For a deeper tour of how receipts feed back into the broader trust score picture (identity, capability, reputation, risk), the EVIDIQ docs walk through the full pipeline. The notary is the evidence primitive underneath all of it — score without evidence is just opinion.

The Upload Flow: ZgFile to 0G Mainnet

[IMAGE_PROMPT: A modern flat illustration depicting a layered tech stack. Bottom layer is an abstract glowing blockchain rendered as cube-shaped blocks with soft green light. Middle layer is a stylized receipt document with cryptographic hash symbols and small merkle tree icons. Top layer is an abstract neural network node casting a holographic seal stamp down onto the receipt. Soft gradient background in teal and indigo, abstract geometric patterns, no text visible, no real brand logos.]

Here's the bit the protocol engineers reading this actually want — the real upload flow, byte by byte.

The notary client takes a JSON receipt and canonicalizes it with JCS (RFC 8785) so the byte representation is deterministic. Two semantically identical receipts always produce the same bytes, which means the keccak256 hash is stable. That hash is what we anchor — everything else is a handle pointing back to it.

Once the receipt is canonicalized, the client wraps it in a ZgFile using the @0gfoundation/0g-ts-sdk:

1. ZgFile.fromFilePath("./receipt.json") — or fromBuffer(...) when the receipt is built in memory.
2. The SDK computes the merkle root of the file's chunks automatically.
3. indexer.upload(zgFile, { wallet, taskSize: 10 }) submits it to the 0G indexer.
4. On success, the SDK returns { storageRoot, storageTx } — the merkle root and the on-chain transaction hash.

Two failure modes drove the timeout-and-fallback design. First, turbo indexers can saturate under load and start returning slow responses that masquerade as successes. Second, partial uploads — where bytes landed but the merkle root never reached the chain — produced receipts you could retrieve but never prove. The current flow fails closed on both.

The 30-second timeout budget we set for upload is there for a reason: if the turbo indexer path stalls, the client falls back to the standard indexer endpoint. We don't want a flaky indexer to silently drop a notarization — better to retry on a different path than to lose the anchor. Every receipt also gets an EIP-191 signature from the EVIDIQ notary key, so even if 0G Storage itself disappeared tomorrow, the signed hash is still provable against any independently archived copy of the receipt.

The result of that flow is two artifacts worth saving: the on-chain tx hash (your durable handle) and the keccak256 of the canonicalized JSON (your content address). Pair them and you have tamper-evidence that doesn't depend on any single party staying honest. If you want the full code-level walk-through, the EVIDIQ Notary docs have a copy-pasteable example with environment variables and the retry helper.

Why Decentralized Storage Beats a Database for Audit Trails

Why not just dump the receipt into Postgres? Because the moment you do, you've reintroduced the exact trust gap you were trying to close. A database is something somebody — an employee, a hosting provider, a future acquirer — can mutate. Even with WORM storage, the operator still controls who reads and who verifies. For audit trails, that control is the bug.

A 0G Storage anchor flips the asymmetry:

• Anyone can verify. Give a third party the tx hash and they can pull the receipt themselves from the 0G indexer. No API key, no vendor permissioning, no support ticket.
• Tamper-evident by construction. The merkle root on mainnet commits to specific bytes. Editing the payload means editing the chain — which is exactly what a blockchain makes expensive.
• Durable across reorganizations. The merkle root lives in a finalized block on 0G Aristotle. Chain reorganizations past finality don't undo it.
• Cost-shaped for evidence. A few kilobytes of canonicalized JSON costs fractions of a cent. Anchoring a million inferences a month is a coffee budget, not a data-platform budget.

The traditional audit log — append-only table, read-replica, offsite backup — works fine for compliance theater. It fails the moment your counterparty is a stranger, a regulator in a different jurisdiction, or an autonomous agent that needs to make a decision without phoning home to ask permission. For that audience, "we have it in our database" is not a proof. A tx hash on a public chain is.

We've watched too many "trust us" infrastructure plays collapse when a vendor changes pricing, gets acquired, or simply turns off the lights. Decentralized anchoring means the receipt outlasts us — which is the only durability model an audit chain actually needs.

Six Tools, Four Free — the Notary MCP Surface

[IMAGE_PROMPT: A modern flat illustration showing six stylized MCP tool cards arranged in a 3x2 grid. Each card is a soft pastel rounded rectangle with abstract iconography — a quill and stamp, a batch folder, a magnifying glass with a checkmark, a document with arrow, a bar chart, a key. Two of the cards glow warm gold (paid), four are muted slate-blue (free). Background is a subtle dotted grid in pale gray. Modern developer aesthetic, no text visible, no real brand logos.]

The Notary ships as an MCP server, and the surface is small on purpose. Six tools, four free, two paid. The split exists so a developer can poke at everything except the actual notarization cost — and so a producer integrating the notary knows exactly what's billable before writing a single line of glue.

The six tools exposed at evidiq.dev/mcp:

• notarize_inference (paid) — signs and anchors a single receipt. x402-gated, paid per call in USDT0 on X Layer.
• notarize_batch (paid) — bundles up to 100 inferences into one merkle root, then anchors the root. One on-chain tx, many receipts.
• verify_attestation (free) — re-fetches a receipt by tx hash, recomputes the keccak256, and returns a pass/fail with the recovered signer.
• get_receipt (free) — pulls the canonicalized JSON for a tx hash without verifying.
• notary_stats (free) — counters, schema versions, public key fingerprints. Useful for dashboards.
• notary_pubkey (free) — returns the active EVIDIQ notary public key so you can independently verify signatures offline.

Every AI output notarization call flows through one of the two paid tools. They follow the x402 protocol exactly: the server returns HTTP 402 with an accepts[] array per the v2 spec, scheme exact, EIP-3009 transferWithAuthorization. Your client signs the authorization, retries, and the receipt anchors. No accounts, no API keys, no monthly invoicing. Pay per anchor.

The four free tools exist for one reason: they let you build, test, and audit integrations without spending a cent. You can simulate a notarization by calling notarize_inference once, then re-run verify_attestation ten thousand times in CI to prove your verification pipeline works — no metering, no rate limits beyond polite usage. When you're ready to anchor real production inferences, the paid path is a one-line wallet integration.

If you're wiring this into an agent that needs broader trust score signals — identity, capability, reputation, risk — the EVIDIQ Sentinel docs cover the higher-level flow. For embedding the notary as a step inside your own orchestrator, the EVIDIQ Operator docs show the wiring.