How EVIDIQ Builds 0G TEE Verifiable AI Attestation for Every Trust Verdict

What 'Verifiable' Has to Mean for a Machine

0G TEE verifiable AI attestation is the EVIDIQ pipeline that turns a trust-score verdict into independent, machine-checkable proof. We canonicalize the report, hash it with keccak256, anchor it on 0G Storage mainnet, run the risk analysis inside a Trusted Execution Environment, and sign it with EIP-191 — so anyone can re-fetch, re-hash, and recover the signer without trusting us.

Picture the moment: your agent just received a 0-to-100 trust score on another agent. It needs to decide whether to hand over a payment, a key, or a task. A JSON blob with a score: 87 field is not evidence. It's an assertion. If your agent cannot independently check that the score wasn't tampered with, that the risk analysis actually ran, and that the signer is who it claims to be — your agent is taking the verifier's word for it.

That's a problem we kept running into while designing the EVIDIQ stack in 2026. The whole point of an EVIDIQ verdict is that it should be consumable by other agents, not just human reviewers reading a dashboard. And a machine has one unforgiving requirement: it needs cryptographic proof it can re-run on its own. Marketing-grade "verifiability" — where a vendor publishes a report and asks you to believe it — fails that test.

Here's the thing: a report that can't be independently re-derived from public primitives is just an opinion with better formatting. So 0G TEE verifiable AI attestation had to mean something stricter. Four things, specifically:

• Canonical inputs that produce identical bytes across machines.
• A one-way hash function that anyone can recompute.
• A public anchor on a network nobody has to permission us to write to.
• A signature whose public key is recoverable from the message bytes alone.

If any one of those is missing, "verifiable" is decorative. We treat the chain as load-bearing.

For the deeper product story behind the score itself — the identity, capability, reputation, and risk inputs that feed into our formula — the EVIDIQ docs cover that. What we want to dig into here is the part most teams skip: how a verdict becomes something your agent can prove to itself.

Four Links in the Chain

The chain is short and the order matters. Reverse any step and the whole thing collapses.

1. Canonicalize the report. We serialize the trust report using a deterministic JSON shape — sorted keys, fixed whitespace, no timestamps that drift between calls. Two agents that fetch the same report at different times must get byte-identical content, or the hash below becomes a per-request snowflake.
2. Hash with keccak256. We run the canonical bytes through keccak256. This is the fingerprint. If a single character of the report changes, the fingerprint changes — and there is no known preimage attack.
3. Anchor on 0G Storage mainnet. The fingerprint is written to 0G Storage, returning an on-chain transaction receipt. This is the step that turns a private assertion into a public commitment. Skip it and you've got a hash that only lives inside our database.
4. Sign with EIP-191. We wrap the canonical payload in the Ethereum personal-sign prefix and sign with our published EVIDIQ key. Anyone with the message bytes and the signature can recover the signer address locally.

What breaks if you skip step 1? Non-determinism. Different parsers, different Unicode normalizations, different float encodings — and your re-hash will silently disagree with ours. Every verifier downstream is now debugging whitespace.

What breaks if you skip step 2? You have no integrity check. The anchor in step 3 becomes a commitment to "whatever was in our database at write time," and a future rewrite of that row leaves no trace.

What breaks if you skip step 3? You have a hash and a signature but no independent record. Anyone who can rewrite the report can rewrite the hash. The signature still says "EVIDIQ signed something," but you can no longer prove what.

What breaks if you skip step 4? You have a hash on a public chain, but the message attached to that hash is unsigned. A court, an auditor, or another agent can't prove which key endorsed the verdict.

Our EVIDIQ Sentinel docs walk through the exact bytes that flow across this boundary. The point worth restating: every link is replaceable in isolation. Together they form one cryptographic statement: "EVIDIQ, on 0G, at this request, attested to this exact report." Tamper with any byte of the report and the chain disagrees. Tamper with any link of the chain and the math no longer closes.

What the TEE Actually Buys You

Up to this point, the chain is mostly bookkeeping. Determinism, a hash, a public anchor, a signature — all necessary, none of them unique to AI. The part that actually needs AI-grade hardening is the inference step: the moment we ask a language model "given this agent's evidence, what is the residual risk?"

Plain API call problem: when you POST a prompt to a hosted model, you receive an answer. You do not receive proof that:

• The model that ran was the model the provider claims.
• The system prompt wasn't altered mid-flight.
• The model wasn't swapped out for a cheaper, weaker one after a pricing change.
• The output wasn't rewritten by a post-processing filter before it returned to you.

For a normal chatbot this is fine. For a trust verdict that downstream agents will rely on — that they will hand money over based on — it's not fine.

The Trusted Execution Environment is what closes that gap. Concretely, here's what the EVIDIQ risk analysis run looks like in 2026:

• GLM-5.2 is invoked through 0G Compute inside an attested enclave.
• The enclave produces a TEE attestation quote binding the provider's address and the request id to the exact model binary and prompt that ran.
• That quote is recorded alongside the risk output, so the inference is reproducible to "this address ran this model on this request."
• If a single byte of the system prompt, the model weights reference, or the output post-processing changes, the attestation no longer matches the recorded request id, and any verifier can spot the mismatch.

What this buys you is not "the model is correct." Models can be wrong. What it buys you is a much narrower, much more useful claim: "the verdict your agent is reading was produced by the inference stack EVIDIQ says it uses, on the request it claims, with the inputs it claims." That is the difference between trusting a vendor and trusting a cryptographic trace.

If you want the operational view — quotas, retries, the exact attestation quote format — the EVIDIQ Operator docs have the implementation details. The philosophical point is shorter: a TEE doesn't make the model truthful, it makes the claim about the model checkable.

In practice, this is what lets us put do_not_proceed and proceed verdicts on the same footing. Either verdict is the same artifact: hashed, anchored, signed, run in an enclave. Downstream agents don't have to treat risk-blocked outputs as a special, more-suspicious class. They're just outputs.

How to Re-Verify a Report Yourself, Right Now

You don't need our permission, our UI, or our word. You need a report, the 0G root hash, the signature, and a couple of standard crypto primitives. Here's the path.

1. Pull the canonical report bytes from the EVIDIQ Notary docs reference schema. Make sure your serializer matches ours byte-for-byte — keys sorted, no trailing whitespace, numbers unquoted.
2. Compute keccak256 of those bytes. The output should match the fingerprint embedded in the report header.
3. Fetch the evidence blob from 0G Storage using the recorded root hash. Verify that the blob's hash equals the fingerprint from step 2. If it doesn't, the report and the anchor disagree — stop and flag.
4. Take the EIP-191 signed message — the canonical report prefixed with \x19Ethereum Signed Message:\n<len> — and recover the signer address from the signature using ecrecover.
5. Compare the recovered address to the EVIDIQ publisher key listed in the EVIDIQ docs. Match means the signature is genuine. Mismatch means somebody else's key signed this — also stop and flag.
6. Cross-check the TEE attestation: the provider address and request id in the quote must correspond to a real 0G Compute invocation on 0G mainnet. If you can't find it, the risk step never happened.

Worth noting: step 6 is the one most teams underestimate. Anyone can mint a signature. Anyone can anchor a hash. The thing only EVIDIQ can produce — and only because the GLM-5.2 inference ran inside a TEE we can reference — is the risk output bound to a specific 0G Compute request. Reproducing that, end to end, is the actual 0G TEE verifiable AI attestation. Everything else is plumbing.

If you want to try this without writing code from scratch, the EVIDIQ playground wraps steps 1–5 for you and shows the recovered signer in the response panel. For production integrations, the same checks live in the open-source evidiq-skill repo under MIT.