What 'Verifiable' Has to Mean for a Machine
0G TEE verifiable AI attestation is the practice of producing a trust verdict whose every step — the input data, the model inference, and the final signature — can be independently re-checked by anyone holding a few public tools. EVIDIQ uses it so that a machine receiving a trust score for another agent can prove, with hashes and signed evidence, exactly how that score was reached.
That single sentence is the difference between an audit trail and a billboard. A trust score sitting in a JSON blob with a stamp on it is not verifiable — it's decorative. If a receiving agent can't fetch the inputs, recompute the hash, recover the signer, and confirm the AI analysis ran inside an attested environment, then "verifiable" is marketing copy with better typography.
We built EVIDIQ for the moment a machine has to decide whether to hand another machine money, custody, or API access. At that moment, a score without a chain of evidence is just an opinion with a confidence number. Our job is to make the chain short, public, and reproducible. Here's the thing — if a system can't be checked by a script, it can't be trusted by a script. And scripts, not humans, are the ones doing the transacting in 2026.
The stakes aren't hypothetical. An agent that pays for inference, storage, or data routing on behalf of a user is one spoofed identity away from leaking funds. A trust verdict that another agent can't independently verify isn't a verdict at all — it's a request to take the verifier's word for it. That model collapses the moment a counterparty has an incentive to lie.
Four Links in the Chain
Every EVIDIQ trust report moves through four steps in order. Skip one, and you no longer have attestation — you have a vibe.
- Canonicalize the report. The trust verdict, the inputs we probed, the timestamps, the evidence URLs — all of it gets serialized into a single deterministic byte sequence. Canonicalization matters because two semantically identical reports must hash to the same value. If you change a single field order, a space, or a timestamp format, you've broken the audit before it started. Most "JSON signed" systems quietly fail this test.
- Hash it with keccak256. That canonical bytes object gets hashed using the same primitive Ethereum uses for transaction and storage hashes, which is intentional — anyone holding a wallet already has the tooling to verify it. Skip the hash and you've replaced math with "trust me, it didn't change."
- Anchor the hash on 0G Storage mainnet, which returns an on-chain transaction reference. This is the public commitment: "this exact report existed at this exact moment." Skip this step and your hash lives in a database a single party controls — which means it can be edited, quietly, by that party. With 0G, the anchor is the anchor. The hash is bound to a block height that nobody can rewrite without rewriting the chain.
- Sign the verdict with EIP-191. EVIDIQ signs using its own key. Anyone with the signature can recover the signer's address from the message bytes alone. That signature is the cryptographic tie between "we said this" and "you can prove we said this." Skip it and you have an assertion without an author.
The whole chain takes a few seconds. None of the steps are negotiable. Each one defends against a specific attack: canonicalization defends against tampering by re-formatting, hashing defends against bit-level edits, anchoring defends against revisionist history, and the signature defends against impersonation. Remove any one of them and you've reopened the door that the other three were guarding.
What the TEE Actually Buys You
The first three links — canonicalize, hash, anchor — are about the report. The TEE is about the AI analysis inside the report, and it's the part that most "verifiable AI" competitors skip.
When EVIDIQ runs a risk analysis on an agent, the inference happens inside a Trusted Execution Environment running on 0G Compute, using the GLM-5.2 model. The TEE produces an attestation that records the model provider's address and the request id of the inference. Anyone can fetch that attestation and confirm the verdict was produced by a specific model, at a specific time, on a specific machine, against a specific request.
That's a wildly different claim than "we ran some AI on it."
A plain API call to a model you don't control is a black box with a JSON response. You don't know if the system prompt was tampered with. You don't know if the model was swapped for a weaker one mid-flight. You don't know if the output was rewritten by an intermediary. Even worse, you can't prove any of that to the next agent in the chain. "Trust us, we ran GPT-class" isn't an attestation — it's a slogan.
A TEE changes the answer to "I don't know" from "nobody can know" to "the hardware itself produced an attestation saying this exact request, by this exact provider, produced this exact output." That's not perfect — TEEs have a trust assumption in the manufacturer — but it's the strongest provable claim available in 2026 outside of running the model yourself. We weighed that trade-off and decided that "the chip said so" beats "the vendor said so" by a wide margin.
What a plain API call gives you versus what the TEE attestation gives you:
- Plain API call — a JSON response, no proof the prompt wasn't tampered with, no proof the model wasn't swapped, nothing to show the next agent in the chain.
- TEE attestation — the provider address, the request id, and a hardware-backed claim that this exact input produced this exact output, unmodified.
We chose 0G specifically because the TEE attestation, the storage root, and the on-chain anchor live in the same verifiable neighborhood. A trust verdict shouldn't have to chase evidence across five different trust domains. Ours sits in one — and that's what makes 0G TEE verifiable AI attestation a coherent system instead of a marketing phrase.
How to Re-Verify a Report Yourself, Right Now
Most "verifiable AI" products make verification a six-month integration project. EVIDIQ doesn't. Here's the literal workflow — you can do this with curl and cast, in a few minutes, without writing us an email.
Step 1 — Fetch the evidence. Every EVIDIQ report ships with an evidence_root pointing at 0G Storage. Hit that endpoint and you get back the exact canonical bytes we hashed. No transformation, no middleware, no API key.
curl https://evidiq.dev/reports/<report_id>/evidence -o evidence.bin
Step 2 — Recompute the keccak256 hash. Take the raw bytes you just downloaded and hash them locally. If your hash matches the one in the report header, the evidence hasn't been tampered with between the anchor and now.
cast keccak evidence.bin
Step 3 — Confirm the anchor on 0G. Take the hash and the on-chain tx reference from the report, and read the 0G Storage contract on mainnet. If the hash is committed there, the report existed at that block height. The evidence is now timestamp-anchored, not just claimed.
Step 4 — Recover the signer. EIP-191 signatures are recoverable. Feed the canonical message and the signature into cast and you'll get back the EVIDIQ address. If it matches the published EVIDIQ signing key — and you can pin that key once and reuse it forever — the verdict is cryptographically from us.
cast wallet verify --message evidence.bin --signature sig.txt
That's it. No proprietary SDK, no gated dashboard, no "contact sales." You can wire this into another agent's intake flow and have it run before any money moves. Which is exactly what EVIDIQ was designed to enable.
If you want the quickstart version of the same flow, the EVIDIQ skill walks through it in a single install. The full architecture, including the scoring formula and the x402 payment path, lives in EVIDIQ docs. This is what 0G TEE verifiable AI attestation looks like in production: not a claim, a procedure.