How 0G TEE Verifiable AI Attestation Backs Every EVIDIQ Verdict

What 'Verifiable' Has to Mean for a Machine

0G TEE verifiable AI attestation is the process EVIDIQ uses to make every trust report independently checkable by a machine. The report is canonicalized, keccak256-hashed, anchored on 0G Storage, analyzed inside a TEE, and signed with EIP-191 — so any third party can re-fetch the evidence, re-run the hash, and recover the signer.

A score that no one can re-derive from public evidence isn't a verdict — it's a vibe. We learned this the hard way: an early EVIDIQ prototype returned a 0-100 number with no attached evidence, and we watched counterparties shrug. "Why should I trust seventy-three?" was the actual quote from a builder we'd never hear from again.

So when we say EVIDIQ produces 0G TEE verifiable AI attestation, we mean something sharper than "it's signed" or "it's on a blockchain." A machine — not a human reading a blog post — must be able to pull the report, re-run the math, and reach the same number. Anything less is just an opinion with better formatting.

The point of a trust score isn't the score. It's the receipts. Every digit EVIDIQ returns is backed by an evidence bundle, a canonical hash, a storage root anyone can read, a TEE trace that proves the inference ran unmodified, and an EIP-191 signature that ties the whole thing back to a known key. If a counterparty can dispute the verdict by pointing at a real hash mismatch, the verdict was always going to be wrong anyway. 0G TEE verifiable AI attestation exists so the dispute happens with logs, not feelings.

We've found builders tend to underestimate this. They read "verifiable" as "it has a signature somewhere" and move on. The reality is a chain of independent claims — and a chain is only as strong as its weakest link. Let's walk it.

Four Links in the Chain

0G TEE verifiable AI attestation is the name we give this whole pipeline — and like every pipeline, it can leak at any joint. The chain we ship has four ordered steps. Skip any one of them and "verifiable" becomes wishful thinking.

1. Canonicalize. Before hashing, the report — identity anchors, capability declarations, reputation signals, risk dimensions, final score, recommendation — is serialized with a single deterministic JSON encoding. No whitespace drift, no key reordering, no floating timestamp randomness. Same inputs, same bytes, every time. Skip this and two clients computing "the same" hash will get different answers, and the whole attestation is dead on arrival.

2. keccak256 hash. That canonical bytes blob is run through keccak256. The output is a 32-byte fingerprint that's effectively unique to that exact report. We use keccak256 deliberately: it's the same primitive Ethereum uses, so wallets, explorers, and on-chain verifiers can all speak the same language. Drop the hash step and you're back to "trust me, this is the report."

3. 0G Storage anchor. Once the hash is computed, the full evidence bundle — the canonical report plus all the raw inputs that produced it — is uploaded to 0G Storage on mainnet, and the root hash is recorded as an on-chain transaction. This is what makes the evidence retrievable forever, not just signed. Anyone can pull the bundle by root and re-hash it themselves. Skip the anchor and the signature protects a document nobody else can read.

4. EIP-191 signature. Finally, the keccak256 digest — together with a domain separator that prevents cross-protocol replay — is signed by EVIDIQ's known key. The signature is appended to the report alongside the storage root and the TEE trace. ecrecover returns the signer address. Skip this step and the anchor is just... data. No party claims responsibility.

Each link exists because the next one down is insufficient on its own. The signature without an anchor proves only that someone signed a hash. The anchor without canonicalization proves only that some bytes were stored. Canonicalization without a hash proves only that some structure existed. The chain is the product.

If you've configured an EVIDIQ Operator integration, the receipt your client stores already contains all four artifacts in a single object — see the EVIDIQ Operator docs for the exact field shape.

What the TEE Actually Buys You

Here's where most teams quietly cut corners and hope you don't notice.

EVIDIQ's AI risk analysis — the step that interprets the evidence bundle and produces the natural-language summary you read in a verdict — runs GLM-5.2 inside a Trusted Execution Environment on 0G Compute. Not as a marketing claim. As an on-chain, cryptographically attested trace.

Concretely, when a TEE-attested inference runs, 0G Compute records four things into a public attestation log:

• Provider address of the inference endpoint
• Request id that ties this specific job to the inputs we sent
• TEE attestation that the model code ran unmodified on the claimed hardware
• Public log entry anyone can fetch later to confirm the inference happened

Why bother? Because a plain API call to a model you can't verify is just... a string someone else wrote. A counterparty asks the obvious question: "Did the model actually see what you say it saw? Could someone have slipped a different prompt in front of it? Could the output have been edited before you read it?" Without a TEE trace, your answer is a shrug.

With 0G TEE verifiable AI attestation, the answer is a row in a public ledger. The provider address and request id pin the inference to a moment in time. The TEE guarantees the model code ran unmodified on the claimed hardware. The hash chain we walked above guarantees the inputs that went in were the same ones we hashed, signed, and anchored. The pieces compose.

This is also why we keep the LLM step narrow on purpose. GLM-5.2 produces a risk narrative — it does not produce the score. The score is deterministic math over identity, capability, reputation, and risk, and the math doesn't care what an LLM thinks. So even on a worst-case day where someone finds a way to mislead the model, the on-chain evidence, the TEE trace, and the signed score all still agree. We designed for that.

If you're wiring an agent that needs to consume the AI risk summary alongside the signed score, the EVIDIQ Sentinel docs cover how to surface both to your downstream policy.

How to Re-Verify a Report Yourself, Right Now

Enough theory. Let's actually do it. Below is a literal workflow for taking a trust report EVIDIQ gave you and re-verifying it from scratch using only public infrastructure. No special access, no EVIDIQ SDK, no permission.

1. Pull the receipt. Every EVIDIQ response contains a receipt object with: canonical_report, keccak256_digest, storage_root (0G Storage), tee_trace (provider address + request id), and signature (EIP-191 over the digest). Grab it.

2. Fetch the evidence bundle from 0G Storage. Hit the 0G Storage mainnet gateway with storage_root. You'll get back the exact canonical bytes that were uploaded. Don't trust the canonical_report field in the receipt — fetch the bytes directly.

3. Re-hash those bytes. Run keccak256 on the raw bytes you just pulled. The output must equal keccak256_digest in the receipt, byte for byte. If it doesn't, the report was tampered with after anchoring. Stop.

4. Recover the signer. Take the keccak256_digest, prepend the EIP-191 prefix (\x19Ethereum Signed Message:\n32), run ecrecover, and you should land on EVIDIQ's published public key. Cross-check the address against the one documented at EVIDIQ docs. Mismatch means a forgery, not a glitch.

5. Validate the TEE trace. Look up the request_id in 0G Compute's public attestation log. Confirm the provider_address matches the model endpoint EVIDIQ claims to have used. This is what closes the loop on the AI risk narrative.

That's the whole flow. No trust in EVIDIQ's servers, no trust in EVIDIQ's API status, no trust in a dashboard screenshot. Just bytes on disk, hashes on chain, and a recoverable signature. The full reference implementation lives in the EVIDIQ Notary docs — copy-paste runnable, with sample receipts.

We deliberately ship the verifier separately from the producer. A report you can't check is a report you have to take on faith, and faith doesn't scale across agents.