How 0G TEE Verifiable AI Attestation Actually Works in EVIDIQ

What 'Verifiable' Has to Mean for a Machine

0G TEE verifiable AI attestation in EVIDIQ is the end-to-end process of canonicalizing a trust report, hashing it with keccak256, anchoring that hash on 0G Storage, running GLM-5.2 risk inference inside a Trusted Execution Environment, and signing the verdict with an EIP-191 signature — so any party can re-fetch the evidence, re-hash it, and recover the signer independently.

For an agent handling value, 0G TEE verifiable AI attestation turns a reported score into evidence another party can inspect without relying on EVIDIQ's word.

Picture this: your AI agent calls another agent, gets back a "trust report" full of green checks and a friendly score, then sends 200 USDT0 to a wallet it has never verified. The report looked authoritative. It was, in fact, just a JSON object that someone on the internet wrote. There was no proof that the score was derived from the inputs claimed, no proof the inputs were real, and no proof the signer was who they said they were. That whole experience is what we built EVIDIQ to delete.

Here's the thing: a machine can't read tone. It can't tell sincerity from fraud. The only thing it can do is independently re-run the math and check a signature. If the report can't survive that, it isn't evidence — it's marketing.

So when we say "verifiable," we mean something specific. Not "trust us." Not "we ran checks." We mean: the report has a canonical form, a cryptographic hash, an on-chain anchor, a TEE-attested inference, and a recoverable signature. Every link is checkable by anyone with curl and a hex decoder. Anything less than that and the term "verifiable" is doing PR work, not engineering work.

Four Links in the Chain

The attestation chain inside EVIDIQ is short on purpose. Four steps, no detours. Each one answers a different "but how do you know?"

1. Canonicalize the report. EVIDIQ serializes the verdict into a single deterministic JSON form — same fields, same ordering, no whitespace games. If we skipped this, two honest clients could hash different byte strings and both think they were right. Canonicalization is what makes "the same report" mean the same thing.

2. keccak256 the canonical bytes. This produces a 32-byte hash. Two reports with one byte of difference hash to wildly different values; the same report always hashes to the same value. Without the hash, there is nothing to anchor. The hash is the report's fingerprint, full stop.

3. Anchor the hash on 0G Storage (mainnet). EVIDIQ submits the hash and returns the resulting on-chain transaction. Now the fingerprint has a public, timestamped existence. Anyone can re-fetch the evidence from the storage root and confirm it matches. Skip the anchor and you've got a hash floating in a PDF, which proves nothing.

4. Sign the verdict with EIP-191. Finally, the EVIDIQ key signs a digest that ties everything together. Recovering the signer from the signature takes three lines of ethers. Without the signature, the anchor could be a copy; with it, the chain is closed.

Honest question — what breaks if you drop step 4 and only publish the anchor? Plenty of people could publish the same hash. The signature is what turns "EVIDIQ said this" from a claim into a verifiable fact. The chain only works because every link does work the others don't.

What the TEE Actually Buys You

The risk analysis is the part of an EVIDIQ verdict most likely to be challenged. A score is a number; an LLM summary is prose. Anyone can write either. The question is: did the model you claim actually run, on the inputs you claim, producing the output you signed?

That's where the Trusted Execution Environment comes in. When EVIDIQ sends the risk inference to 0G Compute, GLM-5.2 runs inside a TEE, and the TEE emits a quote that records two things: the provider address that executed the model and the request id of the inference call. That quote is what the EVIDIQ signer ties the risk score to.

Concretely, what does the TEE buy you that a plain API call to a model you can't verify doesn't?

• Proof the model was unmodified. The TEE attestation binds the inference to a known code image. If someone swapped GLM-5.2 for a friendlier model at runtime, the quote wouldn't verify.
• Proof of the operator. Provider address is recorded. You know who was on the other end, not just "some inference endpoint."
• Proof of which request produced which output. Request id ties the inference to your specific call, so a cached or replayed answer can't be substituted.
• Replay resistance for the verdict. Because the signature covers the TEE quote and the request id, an attacker can't re-use an old attestation on a new report.

A plain "we called an LLM" gives you none of that. The model could be anything, the operator could be anyone, and the answer could have been generated last week for a totally different question. The TEE doesn't make the model truthful — it makes the pipeline tamper-evident. That's the line we hold, and it's the difference between a reputation system and a recommendation engine with a logo.

How to Re-Verify a Report Yourself, Right Now

You don't have to trust us. Here is the literal workflow to re-verify any EVIDIQ report from scratch, no UI required.

1. Pull the report JSON from the response payload EVIDIQ returned to your agent. Note the evidence_root, tx_hash, tee_quote, and signature fields.
2. Run the same canonicalization our EVIDIQ docs describe (sorted keys, no whitespace) over the verdict object — excluding the signature itself.
3. Compute keccak256(canonical_bytes) locally. Compare it to the evidence_root in the report. If they differ, the report was tampered with after signing.
4. Fetch the evidence blob from 0G Storage using the root. Re-hash it. Confirm the bytes match what was anchored in the on-chain tx_hash.
5. Recover the signer from the EIP-191 signature using ethers.SignatureUtils.recover or ecrecover. Confirm the recovered address equals the EVIDIQ public verifier key listed in EVIDIQ Notary docs.
6. Verify the TEE quote against the 0G Compute attestation contract. Confirm the provider address and request id are consistent with the report's report_id and timestamp window.

If all six checks pass, you have mathematically reproduced the 0G TEE verifiable AI attestation yourself. No login. No API call. No EVIDIQ server trust required. If any one fails, the report is invalid, full stop — no need to argue about it.

We've kept this process deliberately boring. Boring is what you want when money moves.