How EVIDIQ Builds a 0G TEE Verifiable AI Attestation You Can Re-Check

Last month an agent paid another agent $4,200 USDT0 for a market analysis. Both wallets looked legitimate on-chain. The "reputation" backing the seller turned out to be a screenshot from a Discord. Three days later the buyer realized the report had been hallucinated end to end, and there was no way to prove which model had run, which inputs it had seen, or who had actually signed off on the verdict. That is the world we built EVIDIQ against — not the world of well-lit demos, but the one where a counterparty has motive to lie and time to do it well.

What "Verifiable" Has to Mean for a Machine

A 0G TEE verifiable AI attestation is EVIDIQ's signed, end-to-end evidence package proving that a specific trust verdict came from a specific AI inference running inside a Trusted Execution Environment, with the underlying evidence anchored on 0G Storage. For a machine, verifiable means independently re-derivable.

Here's the thing: a report a machine cannot independently check is just an opinion with better formatting. We mean it literally. If your audit trail lives in a vendor's Postgres database and the only way to confirm it is to ask the vendor nicely, you do not have an audit trail — you have a promise with a logo. Our entire architecture is the opposite of that. Every claim we produce is rebuilt from public primitives before it is trusted. That is not a slogan; it is a checklist our engineers run on every release.

The chain we assemble for each verdict is four steps long and skipping any of them leaves a hole a sufficiently motivated counterparty will eventually find. We do not ship "best-effort provenance." We ship the kind of evidence that survives being screenshotted, leaked, and argued about six months later in a Discord you no longer moderate. The goal is not to make EVIDIQ impossible to compromise. The goal is to make every compromise independently provable — and that is exactly what a working 0G TEE verifiable AI attestation is for in 2026.

Four Links in the Chain

Walk the chain in order, because the order is the point. Each link is what makes the previous one non-repudiable.

1. Canonicalize the report. We serialize the trust verdict JSON with sorted keys, no trailing whitespace, and a pinned schema version. Same input, same bytes, every time. Skip this and a counterparty can argue that your "hash" was of a different document than theirs.
2. keccak256 hash. The canonical bytes go through keccak256. This is the fingerprint the rest of the chain hangs off. Skip hashing and "anchoring" is anchoring to nothing specific.
3. 0G Storage anchor. The hash is submitted to 0G Storage on mainnet, which returns an on-chain transaction hash. Anyone holding that tx can pull the payload back and confirm the bytes match. Skip this and you have anchored to a database row, which is a soft anchor at best.
4. EIP-191 signature. The verdict is signed by the EVIDIQ key using EIP-191 personal_sign. Anyone can run ecrecover to recover the signer. Skip the signature and "EVIDIQ said so" becomes unfalsifiable folklore.

What breaks if you skip a link is worth saying out loud. No canonicalization means the hash is unstable across implementations. No hash means the 0G anchor points at ambiguous bytes. No 0G anchor means the signature is over a blob only EVIDIQ can reproduce. No signature means the whole thing is hearsay with good branding. Every link exists because the previous one had a documented failure mode, and a complete 0G TEE verifiable AI attestation is only as strong as the one before it.

What the TEE Actually Buys You

This is where most readers lose the thread, so let us slow down. The risk analysis you read inside an EVIDIQ verdict was generated by GLM-5.2 running on 0G Compute inside a Trusted Execution Environment. That single sentence has three independent claims — verifiable model identity, verifiable inputs, verifiable outputs — and the TEE attestation is the only thing that lets you prove any of them.

A plain API call to a model provider tells you exactly one thing: "trust us, the model ran." You do not know which weights were loaded. You do not know whether the prompt was logged or modified upstream. You do not know whether a wrapper injected extra instructions before the response came back. You do not even know whether the answer was hand-typed by an intern named Dave on a slow Tuesday afternoon.

By contrast, a TEE attestation is a cryptographic receipt from the hardware itself. It proves that:

• A specific inference container was loaded into a specific enclave on a specific provider.
• The model file referenced inside that enclave matched a known hash before any tokens were generated.
• The output bytes were produced by that exact binary against those exact inputs.
• The provider address and request id were recorded in the report so the job can be looked up later.

What you still cannot prove is intent. Dave might still have written a bad prompt. What you can prove is that the inference you got back was the inference the enclave ran, unmodified, end to end. If someone disputes the verdict six weeks later, we do not have to argue about whether the model "really" ran — we hand over the receipt and the on-chain trust verdict together. Pair that with the recorded provider address on chain and the 0G anchor, and you have three independent layers that would all have to be compromised simultaneously. That is what a working 0G TEE verifiable AI attestation chain actually looks like in 2026.

For agents that need to enforce these guarantees automatically at request time, our EVIDIQ Sentinel docs walk through the runtime hooks. For teams that want to audit a history of past verdicts in bulk, the EVIDIQ Operator docs describe the batch re-verification pipeline that rebuilds the chain from raw 0G data without going through our API at all. Both tools rely on the same re-verifiable chain, so a verdict held in Sentinel's in-memory cache can be re-derived from scratch by Operator at any later moment.

How to Re-Verify a Report Yourself, Right Now

This is the part our competitors do not write down. You do not need our permission, our SDK, or our login. Here is the entire procedure, end to end:

1. Grab the verdict JSON from the response, the dashboard, or the canonicalized report pointer. It includes the report hash, the 0G Storage root hash, the TEE provider address, and the EIP-191 signature.
2. Pull the evidence blob from 0G Storage using the returned root hash. The 0G client returns the raw bytes over standard HTTP.
3. Canonicalize the report locally with the same sorted-key rules and schema version. Recompute keccak256 over the canonical bytes. Compare against the hash in the verdict — they must match byte for byte.
4. Take the signature bytes, the report hash, and the EIP-191 prefix (\x19Ethereum Signed Message:\n32). Run ecrecover against it. You should get back the EVIDIQ signer address published in our public registry at EVIDIQ docs.
5. Optionally, cross-check the TEE receipt by reading the recorded provider address and request id from the report, then querying 0G Compute directly for that exact job and confirming the enclave quote matches what is in the verdict.

If any of those steps fail, the verdict is wrong. Period. We deliberately do not ship a "trust the dashboard" fallback, and we will not ship one in 2026 or any year after. The whole point of the 0G TEE verifiable AI attestation chain is that the dashboard is a viewer, not a source of truth. The on-chain anchor is the source of truth.