0G TEE verifiable AI attestation: Why EVIDIQ Anchors Every Trust Verdict on 0G

Imagine two AI agents trying to settle a $4,200 invoice. One says "trust me, I scored this counterparty at 82." The other hands over a signed, on-chain-anchored, TEE-attested dossier with a 0G root hash you can re-fetch yourself. Which one would you pay? In 2026, when autonomous agents are moving real money on X Layer, "I checked it" stopped being a sufficient answer. We built EVIDIQ because the only attestation that scales between machines is one a machine can independently re-run.

What 'Verifiable' Has to Mean for a Machine

0G TEE verifiable AI attestation is the end-to-end pipeline EVIDIQ uses to make every trust report independently checkable: the canonical report is hashed with keccak256, anchored on 0G Storage mainnet, run through a GLM-5.2 inference inside a 0G Compute TEE, and signed with an EIP-191 key — so any third party can re-fetch, re-hash, and recover the signer.

A report a machine can't independently check is just an opinion with better formatting. That's the bar we set when we designed EVIDIQ's 0G TEE verifiable AI attestation chain — if your agent can't verify our verdict without phoning us, we haven't actually attested to anything. We've just shouted from a rooftop.

Concretely, "verifiable" here means four things, and skipping any one of them collapses the whole claim:

• The report has a canonical byte representation (no whitespace games, no field reordering).
• The canonical bytes have a deterministic keccak256 hash.
• That hash has been written to an immutable, third-party-owned ledger.
• The verdict was produced by code running in hardware the operator can't tamper with mid-flight.

If your trust pipeline only does the last two of those, you're publishing a screenshot. If it skips the first one, even the on-chain anchor is meaningless because nobody can reproduce the bytes that were anchored. EVIDIQ does all four, every time, for every verify_agent call.

Four Links in the Chain

Every EVIDIQ report passes through the same four operations, in order, and every operation produces evidence the next link can lean on. We chose these operations specifically because each one is the minimum thing that lets a stranger audit the result without trusting us.

The chain looks like this:

• Canonicalize. We serialize the report (agent identity, declared capabilities, probe result, score breakdown, recommendation, timestamp) using a deterministic JSON canonicalization scheme. Two different runs over the same logical report produce byte-identical output.
• Hash. We keccak256 the canonical bytes. The digest is the report's content-addressed identity.
• Anchor. We write that hash to 0G Storage on mainnet and wait for the on-chain transaction receipt. The receipt is the third-party-owned proof that these exact bytes existed at this exact time.
• Sign. We EIP-191 sign the canonical bytes with the EVIDIQ notary key. Anyone with the public key can recover the signer and confirm it matches the key published at our EVIDIQ Notary docs.

Now the obvious question: what breaks if you skip a link? Skip canonicalization and your anchor is pinned to a string that doesn't round-trip — anyone reading your report from 0G Storage produces a different hash, and the on-chain receipt becomes unfalsifiable but also unverifiable. Skip the keccak256 step and you lose content addressing entirely; you're back to "trust the URL." Skip the 0G anchor and the whole chain is self-asserted — we could re-publish a "corrected" version tomorrow and nobody outside our database would notice. Skip the signature and even the canonical bytes are just an unsigned note from a stranger. Each link is load-bearing. The chain is the product.

We publish the notary key, the canonicalization rules, and the hashing function in our EVIDIQ docs. That transparency is what turns the chain from a private promise into a public artifact.

What the TEE Actually Buys You

Anchoring a hash is necessary, but it isn't sufficient. We also need to attest to what the model said about the report. That's where the TEE comes in — and where most "AI verification" projects quietly wave their hands.

The risk analysis in every EVIDIQ report is generated by GLM-5.2 running inside a 0G Compute Trusted Execution Environment. A TEE is a hardware-isolated enclave: the operator of the host machine — including us, including 0G's own staff — cannot inspect, modify, or substitute the inference mid-flight. The enclave produces an attestation quote that binds three things together: the identity of the model binary, the input it processed, and the output it returned.

What you actually get back from that quote is a small, cryptographically-signed record containing:

• The TEE provider's address on 0G.
• The request id of your specific verify_agent call.
• A measurement hash of the model binary that ran your analysis.

Compare that to a plain API call to a hosted model. With a plain call, you have to trust the provider not to swap the model, not to substitute the prompt, and not to forge the response. The provider could literally edit the JSON before returning it. You'd never know. Worse, if your downstream system is automated — an escrow agent, a settlement bot — it can't tell the difference between a model that ran and a model that didn't. With a TEE quote, the model, the inputs, and the outputs are bound together by hardware. The provider address on the quote lets you look up the enclave's signing certificate; the request id lets you match the inference to your call; the binary measurement lets you confirm GLM-5.2 is what actually ran.

That's the difference between a vendor saying "our AI looked at it" and an artifact that proves the inference happened, on the claimed hardware, with the claimed inputs. The first is a promise. The second is a 0G TEE verifiable AI attestation. We lean on it because everything downstream — the score, the recommendation, the escrow decision — inherits its evidential weight from this quote.

If you're wiring EVIDIQ into your own pipeline, the operator side of this is documented in our EVIDIQ Operator docs. The sentinel side — how your agent calls verify_agent and reads back the verdict — is at EVIDIQ Sentinel docs.

How to Re-Verify a Report Yourself, Right Now

The whole point of the chain is that you don't have to take our word for it. Here's the literal sequence — five steps, no special tooling beyond a JSON parser and an Ethereum RPC. After you finish, you'll have independently executed a 0G TEE verifiable AI attestation check on the report in front of you.

1. Fetch the report. Every EVIDIQ report includes an evidence field with the 0G Storage root hash and a fetch URL. Pull the JSON document from that URL.
2. Canonicalize it locally. Apply the same canonicalization rules we publish (sorted keys, UTF-8, no insignificant whitespace). Two correct implementations produce identical bytes.
3. Hash the canonical bytes with keccak256. Any standard library will do — ethers.keccak256(toUtf8Bytes(canonical)) in JS, Web3.keccak(canonical) in Python, cast keccak in Foundry.
4. Compare the hash to the on-chain anchor. Look up the 0G Storage transaction by the hash stored in the report's anchor.txHash field. The bytes the chain stored must match what you hashed. If they don't, the report has been tampered with.
5. Recover the signer from the EIP-191 signature. Take the signature field, prepend \x19Ethereum Signed Message:\n plus the canonical-bytes length, hash, and run ecrecover against the public key we publish. The recovered address must equal the EVIDIQ notary address.

If all five steps line up, you've independently confirmed that the report was produced by the EVIDIQ notary, that the bytes were anchored on 0G Storage, and that nothing between us and you was edited in transit. If any step fails — wrong hash, wrong signer, missing anchor — the report is invalid and your agent should treat it as such. This is not theoretical; we want operators to actually run this.

The reason we keep this whole thing auditable is simple: in an autonomous economy, the cost of trusting a forged verdict is paid by someone who didn't even know a verification was happening. We don't want to be that bottleneck, and you shouldn't want us to be either.