Your agent just told a counterparty: "Here's a 90/100 trust score from EVIDIQ — proceed." Six months from now, when someone asks "did that score actually come from you on the date you said?" — what do you show them? A row in your Postgres? A log line in your SaaS dashboard? Good luck in arbitration. We built EVIDIQ Notary because that answer is exactly the wrong one. Audit trails for AI inferences can't live in someone else's database — they need to be anchored somewhere nobody, including us, can quietly rewrite.
What 0G Storage Anchoring Means for AI Outputs
AI output notarization is stamping a tamper-evident receipt for a model inference and anchoring it on decentralized storage so anyone can later verify the inference actually happened, exactly as claimed. EVIDIQ Notary does this by uploading a canonicalized receipt to 0G Storage Aristotle (chain 16661), returning the merkle root and on-chain storage tx so the proof lives independently of EVIDIQ.
Here's the thing — anchoring is not the same as storing. Anyone can write a JSON receipt to S3 and call it a day, but that receipt can be edited, deleted, or quietly rotated by the same key holder. Anchoring means the proof is verifiable by a third party with nothing but a transaction hash. For our notarization layer, that anchor is 0G Storage Aristotle — mainnet, chain id 16661 — and the artifact at rest is the merkle root of a ZgFile batch uploaded via the turbo indexer.
A receipt from EVIDIQ Notary carries a small, opinionated payload. It's not a screenshot, it's not a PDF report. It's canonical JSON with deterministic field ordering, hashed with keccak256, and it includes:
- The model identifier (or agent id) that produced the inference.
- The canonicalized input prompt or task hash.
- The output hash — never the raw output, because we don't want to leak payloads.
- A UTC timestamp signed into the receipt itself.
- The signer's EVM address and an EIP-191 signature over the canonical hash.
Anything else is optional metadata: the request id, the trust score that the inference contributed to (if it was a verify_agent call), the x402 settlement tx if applicable. The full schema lives in our EVIDIQ Notary docs, but the rule is simple — if a field can't be reconstructed from public chain state, it doesn't go in the receipt.
The Upload Flow: ZgFile to 0G Mainnet
[IMAGE_PROMPT: A clean modern flat illustration showing the EVIDIQ Notary pipeline as a horizontal flow diagram. On the left, a stylized JSON receipt document being wrapped into a sealed envelope labeled "ZgFile". In the middle, an arrow points through a circular node representing a 0G indexer, with small dashed lines indicating turbo fallback. On the right, a stack of blocks representing 0G Storage Aristotle mainnet, with a glowing merkle root icon on top. Developer aesthetic, muted teal and slate blue palette, subtle grid background, no text or brand logos visible.]
Concretely, our pipeline looks like this in 2026 — and it's small enough to fit in a single function.
- The MCP server builds a canonicalized receipt JSON and writes it to a temp path.
- It wraps that file with
ZgFile.fromFilePath(path)from@0gfoundation/0g-ts-sdk. - The SDK pushes it to the indexer using
indexer.upload(zgFile, ...)against a configured 0G mainnet RPC. - The SDK returns
{ storageRoot, storageTx }— that's the merkle root and the on-chain transaction hash. - We persist both alongside the keccak256 of the canonical receipt so the round-trip is fully reconstructable.
We budget 30 seconds for the upload call. In practice it lands in 2–6 seconds on Aristotle mainnet. If the primary indexer stalls — and yes, it does, occasionally — the SDK falls back to a turbo indexer endpoint that's load-balanced across the network's storage nodes. We surface the chosen indexer in the receipt's meta.ingest_path field so you can see which path actually served your anchoring.
This is the part that matters: the merkle root and the storage tx are not EVIDIQ-controlled. They're written by the 0G mainnet, they cost real gas in real 0G, and the only way to "edit" them after the fact is to rewrite the underlying chain history. That's the property that makes AI output notarization actually notarization, and not just a row in a database.
Why Decentralized Storage Beats a Database for Audit Trails
Let me make the contrast concrete. Suppose you're an enterprise buyer six months post-deal, and a regulator (or your own legal team) asks: "Prove this agent gave us score 87 on 2026-03-14." Here's what each storage model lets you actually do:
- Centralized database (your Postgres, ours, anyone's): the holder can edit the row, rotate the timestamp, delete the entry, or quietly fork history. Even with WORM storage, you're trusting the operator. Auditors know this — every SOC 2 walkthrough treats internal logs as "trust us" evidence.
- IPFS / Arweave-style pinning (single file, pinned): durable, but pinning isn't a chain anchor. The pin can lapse, the gateway can serve a different CID than the one originally uploaded, and there's no native "this CID was uploaded at block N" proof.
- 0G Storage anchoring (what we use): the receipt's merkle root is committed in an on-chain tx. The tx lives in a public block. Re-deriving the merkle path from the receipt re-proves the inclusion. Anyone, anywhere, can verify — without us in the room.
The honest version: 0G isn't the only chain that could do this. We picked it because the SDK is mature, the storage cost is dramatically lower than on L1s, and the merkle proofs are first-class in the protocol rather than a rollup trick. If you want the receipts anchored somewhere else, the EVIDIQ Notary docs describe how to point the same pipeline at a different storage root. That's the deal — we don't custody your proof, we just put it on a chain.
Six Tools, Four Free — the Notary MCP Surface
[IMAGE_PROMPT: A modern flat illustration of an MCP tool palette as a grid of six rounded square tiles arranged in two rows of three, floating on a soft dark gradient background. The four free tiles glow softly in muted teal; the two paid tiles have a small subtle x402 payment badge in slate blue corner accent. Below the grid, a horizontal receipt icon is anchored to a tiny blockchain block stack with a merkle root symbol. Developer dashboard aesthetic, clean lines, no real brand logos, no text.]
Notary is an MCP server — meaning your agent can call it like any other tool. We've kept the surface tight on purpose:
notarize_inference— pay-per-call via x402. Hashes an inference, signs it, uploads to 0G Storage, returns the merkle root and storage tx.notarize_batch— pay-per-call via x402. Same anchoring, but batches up to 50 receipts into a single ZgFile upload when throughput matters.verify_attestation— free. Takes a merkle root + storage tx, fetches the receipt back from 0G, re-hashes the canonical form, and confirms the signature. No EVIDIQ involvement required to verify.get_receipt— free. Returns the full receipt JSON plus the chain-of-custody metadata for a given storage tx.notary_stats— free. Aggregate counts and recent anchoring activity for transparency.notary_pubkey— free. Returns EVIDIQ's signing address so callers can verify signatures locally without trusting our endpoint.
Two paid, four free. The paid pair — notarize_inference and notarize_batch — are gated behind x402: HTTP 402, scheme exact, EIP-3009 transferWithAuthorization, settled on X Layer in USDT0. The price is per-call, not per-seat, which keeps a single agent run from accidentally hammering the wrong pricing tier. Settlement details are in the EVIDIQ docs, and you can wire the same notarization flow through EVIDIQ Sentinel if you want a pre-trade trust check AND an AI output notarization receipt in the same call.
Worth noting: the four free tools don't make a network call that costs us anything, which is why we don't gate them. Verification is supposed to be cheap. Anchoring is the expensive part — and we charge for it the same way every honest x402 service does, per actual use. Honest opinion? Anything that bills by seat for an audit trail is misaligned with the thing it's auditing.