0G TEE Verifiable AI Attestation: Why EVIDIQ Anchors Every Trust Verdict

Picture this: your AI agent is about to wire 5,000 USDT0 to another agent it met ten minutes ago. The counterparty's wallet looks clean. Its ENS resolves. It even paid for a service once, on-chain. So your agent forwards the payment authorization, the funds move, and the work never arrives. Three hours later the merchant agent has rotated its address and gone silent.

This is the failure mode we built EVIDIQ to prevent. Not by policing agents — that's impossible at scale — but by producing evidence a third party can re-check without trusting us. The whole point of our stack is that a recommendation has to outlive the conversation that produced it. And that only works if every link in the verification chain is genuinely verifiable. That's what we mean by 0G TEE verifiable AI attestation: not a buzzword, but a specific, end-to-end proof chain from a deterministic score to a tamper-evident signature.

What 'Verifiable' Has to Mean for a Machine

0G TEE verifiable AI attestation is the practice of producing a deterministic AI-agent trust verdict, hashing its canonical evidence, anchoring that hash on 0G Storage, optionally running risk analysis inside a 0G Compute TEE, and signing the report with an EIP-191 key. EVIDIQ publishes each link so any party can re-verify the verdict independently.

Here's the thing. "Verifiable" gets thrown around a lot. A dashboard that shows you a score is not verification — it's a UI. A JSON blob signed by some SaaS is not verification either, unless anyone with the blob can independently prove it hasn't been tampered with and that it came from the key it claims to have come from. For a machine, "verifiable" means something very specific: given the evidence and the rules, a third party can recompute the verdict and get the same answer. No oracle. No "trust me, bro." No appeal to authority.

We took that constraint seriously. The trust score EVIDIQ returns — that 0–100 number with a proceed, proceed_with_escrow, caution, or do_not_proceed label — is deterministic and explainable: identity × 0.3 + capability × 0.3 + reputation × 0.2 + (100 − risk) × 0.2. Same inputs, same score, every time, on every machine. The score, the recommendation, the inputs — all of it is auditable, not a black box. But a deterministic score alone still relies on you trusting that we actually ran the inputs we say we ran. So we wrapped it in a chain that doesn't ask you to.

Four Links in the Chain

Every report EVIDIQ emits goes through the same four steps — the operational backbone of 0G TEE verifiable AI attestation. Skip one and the chain is decorative. Keep all four and the report is independently checkable by anyone holding the bytes.

The four links, in the order they execute:

• Canonicalize the evidence. We take the score, the input fields, the recommendation, the timestamp, the version of the scoring spec, and the probe results, and serialize them with a strict, sorted-key JSON encoder. Two evaluators running the same input produce the byte-identical payload. Without canonicalization, hashing is meaningless — you'd just be hashing your representation, not the verdict.
• Keccak256 the payload. The canonical bytes get hashed with keccak256, the same primitive Ethereum uses. The output is a 32-byte digest that uniquely identifies the report. Change a single character in the JSON, the digest changes.
• Anchor on 0G Storage (mainnet). That digest is submitted to 0G Storage, which returns an on-chain transaction hash. Now the report has a timestamped, decentralized existence proof. Anyone with the original evidence can recompute the digest and check it against the on-chain root. This is the difference between "we say we ran this" and "the network says this report existed at this point in time."
• Sign with EIP-191 using the EVIDIQ key. Finally, the canonical payload is signed off-chain with our published EVM key, producing an EIP-191 personal_sign signature. The signer address is recoverable from the signature itself, so no certificate authority is in the loop.

What breaks if you skip a step? Skip canonicalization and two honest verifiers can disagree on the digest. Skip hashing and there's nothing to anchor. Skip 0G Storage and the report can be silently backdated. Skip the signature and there's no provenance — anyone could publish a report claiming to be from EVIDIQ. Every link has to be load-bearing, or none of them are.

Our EVIDIQ Notary docs walk through the exact wire format and the test vectors we ship with the SDK. If you're integrating this, start there.

What the TEE Actually Buys You

Half of the chain is about the verdict itself. The other half is about the risk analysis that runs before EVIDIQ signs.

When we generate a risk assessment for an agent, we don't just ask a remote model "what do you think?" A plain API call to a model you can't verify ran unmodified isn't attestation — it's a guess with better formatting. So we route the risk analysis through 0G Compute running GLM-5.2 inside a Trusted Execution Environment. This is what elevates the pipeline from "signed score" to genuine 0G TEE verifiable AI attestation.

A TEE is a hardware-isolated execution region. Code running inside it can prove to a remote verifier that (a) a specific binary was loaded, (b) no one — not even the operator of the host machine — tampered with the inputs, and (c) the output came from that binary. Concretely, our TEE execution emits an attestation receipt containing the provider address (the 0G Compute node that ran the inference) and the request id (the unique identifier for this specific run). Both of those land inside the canonical report before hashing.

Why does this matter? Two reasons.

First, you can prove which model weights produced the risk text. A vendor that silently swaps a smaller, cheaper model in the middle of the night gets caught immediately — the attested binary changes. Second, you can prove that this exact request was processed by this exact node at this exact time. Without that, an attacker who controls the inference path can replay, substitute, or fabricate outputs.

In practice, this is the difference between "the AI said it was risky" and "this specific AI, on this specific node, processed this specific request, and the network can prove it." When stakes are non-trivial — and in an autonomous agent economy in 2026, they always are — that's the only version of "the AI said" that's worth anything.

Honest opinion: most "AI risk scores" in the wild skip the TEE entirely. They call a model over HTTPS, paste the output into a JSON, and ship it. That's not a trust system. It's a reformatting service. Our implementation details, including the GLM-5.2 reference and the TEE receipt format, are documented in the EVIDIQ Sentinel docs.

How to Re-Verify a Report Yourself, Right Now

This section is intentionally a how-to, not marketing. If you have a report from EVIDIQ in hand, here is exactly how a skeptical third party — say, you, six months from now — checks it without ever contacting our servers.

1. Pull the evidence by its 0G Storage root hash. Take the on-chain tx hash from the report, query 0G Storage for the original payload. If the network still has it, you get back the exact bytes we hashed.
2. Recompute the keccak256 digest locally. Run keccak256(bytes) on the returned payload. Compare byte-for-byte against the digest embedded in the report. Mismatch? The evidence was tampered with or substituted. You're done.
3. Recover the signer from the EIP-191 signature. Take the canonical payload, append the EIP-191 prefix (\x19Ethereum Signed Message:\n<len><payload>), hash it, and run ecrecover against the signature. The recovered address must equal the EVIDIQ publisher key listed in our public registry on EVIDIQ docs.
4. Recompute the score. Apply the published formula to the reported identity, capability, reputation, and risk sub-scores. If your number matches, the verdict is honest. If it doesn't, the inputs were lied about — and you now have cryptographic proof of that lie.

The whole verification loop runs in under a second and uses zero EVIDIQ infrastructure. That's the test. A trust system where you have to phone the vendor to ask "is this real?" is not a trust system. It's a help desk.

If you're building the verifier into your own agent, the EVIDIQ Operator docs have ready-made SDK calls for each step, plus a CLI that does the full chain in one shot.