How EVIDIQ Notary Anchors AI Output Notarization on 0G Storage

You shipped an agent. It's signing real transactions on mainnet, calling paid APIs, and returning inferences to users. Now your compliance lead asks you to prove a specific output came from your model, unchanged, on March 14 at 14:02 UTC. You stare at your logs. They're text files on a VPS that your intern has sudo on.

That's the problem EVIDIQ Notary was built to solve. Our solution is AI output notarization anchored to 0G Storage — not a database, not an S3 bucket, a real decentralized storage layer where every receipt is verifiable by anyone holding a tx hash.

What 0G Storage Anchoring Means for AI Outputs

AI output notarization is the practice of producing a tamper-evident receipt for an inference or agent action, then anchoring that receipt on decentralized storage so the receipt itself is durable and independently verifiable. EVIDIQ Notary does this by uploading a canonical JSON receipt to 0G Storage Aristotle (chain id 16661), where the upload produces a merkle root and an on-chain transaction that anyone can re-fetch and re-hash.

The result is an audit trail that doesn't depend on the operator staying honest, the database staying online, or the company staying in business.

The Upload Flow: ZgFile to 0G Mainnet

The boring truth is that anchoring looks like a four-step pipe. We've kept it short on purpose — every extra hop is another thing that can break in production.

Here's the actual flow inside the notary:

1. The caller hands us a payload (model id, prompt hash, output, timestamp, optional metadata). We canonicalize it: stable key ordering, no whitespace games, deterministic JSON.
2. We keccak256 the canonical bytes. That hash becomes the receipt id.
3. We wrap the canonical JSON into a ZgFile via ZgFile.fromFilePath, then call indexer.upload from the @0gfoundation/0g-ts-sdk. The SDK returns storageRoot and storageTx.
4. We persist those two fields alongside the receipt so a later verifier only needs the receipt id to recover everything.

Three details that matter in practice. First, we size every upload under the 30-second timeout budget we set for the notarize path — a stuck upload is worse than a failed one, because the caller is waiting on a synchronous trust decision. Second, the SDK points at the standard 0G indexer by default, but we keep a turbo indexer endpoint configured as a fallback for traffic spikes; if the primary misses a heartbeat, we flip automatically and continue. Third, the storageTx we return is a real on-chain transaction on 0G mainnet — paste it into the explorer and you'll see the merkle root committed.

The receipt itself looks roughly like this:

• receiptId: keccak256 of canonical payload
• payload: the original fields, frozen
• canonicalHash: redundant with the receipt id but useful for cross-checking
• storageRoot: returned by the 0G indexer
• storageTx: the on-chain tx hash anchoring the root
• signedAt: unix seconds
• signature: EIP-191 over the rest

Worth noting: we never store the full prompt or output in the receipt. We hash them. The receipt is evidence about evidence — it tells you what was produced and that the hash matches what was anchored, without forcing the storage layer to hold potentially sensitive inference text.

Full field-by-field coverage lives in the EVIDIQ Notary docs. Nothing in the production code path is fancier than this — that's the point.

Why Decentralized Storage Beats a Database for Audit Trails

Let's talk about the alternative, because most teams start with a database. A traditional audit log lives in Postgres, gets replicated to a read replica, and is backed up nightly to object storage. That setup is fine for debugging. It is not fine for the question your compliance lead actually asked.

Here's the thing: a centralized log can be edited. It can be deleted. It can be quietly rolled back by an operator with shell access, or by a future CTO who has different incentives than you do. Even if the team is honest, a single point of failure is a single point of failure. A row in your database is a promise. A row anchored on 0G Storage is a fact. AI output notarization flips that equation: the receipt lives on chain state, not in our database, so the audit trail survives us.

The math is simple. Once the indexer returns a storageRoot and the chain confirms storageTx, that receipt is permanent:

• Anyone with the storageTx can ask the 0G explorer to confirm the merkle root was committed at block N.
• Anyone with the merkle root can re-fetch the underlying data from 0G Storage and re-hash it.
• Anyone who re-hashes and gets the same canonicalHash knows the receipt hasn't been mutated since anchoring.

That last step is the one a database cannot give you. A database log tells you here's what we recorded. An anchored receipt tells you here's what the network agrees was recorded, and here's the cryptographic proof. When a regulator, a counterparty, or a user wants to check a specific inference from six months ago, they shouldn't have to ask you nicely. They should be able to verify it themselves with nothing but a tx hash.

We deliberately pick the EVIDIQ Notary flow over an in-house Postgres table for exactly this reason — central storage is the easiest thing in the world to compromise and the hardest thing in the world to prove you didn't.

Six Tools, Four Free — the Notary MCP Surface

If you're integrating from an agent or a build script, you'll hit the notary through its MCP surface. There are six tools today. We expose four of them without payment, and gate two behind x402 — same scheme as the rest of EVIDIQ: HTTP 402, exact, EIP-3009 transferWithAuthorization, settled on X Layer in USDT0.

The six notary tools:

• notarize_inference — paid (x402) — anchor a single inference receipt. Returns the full receipt including storageRoot and storageTx.
• notarize_batch — paid (x402) — anchor up to 50 inferences in one call, sharing the upload overhead.
• verify_attestation — free — given a receipt id, re-fetch the data from 0G Storage, re-hash it, and confirm the signature. This is the one a third party runs.
• get_receipt — free — fetch the stored receipt by id without verifying. Useful for inspection.
• notary_stats — free — aggregate counts, uptime, and recent anchoring volume. Good for dashboards.
• notary_pubkey — free — return the EVIDIQ signer public key so clients can pre-validate signatures.

The split is intentional. Anything that produces new evidence costs money, because each notarization is a real on-chain storage anchor. Anything that reads or verifies existing evidence is free, because verification should never be paywalled — that's the entire point of a public audit trail. A user who wants to double-check a receipt should not need a wallet.

The paid tools return a 402 challenge first. A client that knows how to speak x402 signs a transferWithAuthorization for the quoted USDT0 amount, retries with the X-PAYMENT header, and gets the receipt back. The same flow works from any language — the SDK ships TypeScript and Python bindings — and the EVIDIQ Notary docs walk through a working example.

Honestly? The MCP surface is the part we're proudest of. We could have shipped a REST API and called it done. Putting notarization behind MCP means an agent can call it directly from its own tool loop, no glue code required. That's what makes AI output notarization practical for autonomous workflows in 2026 — the receipt lands in the agent's tool response, not in a separate dashboard nobody checks.