How EVIDIQ Builds 0G TEE Verifiable AI Attestation End to End

What 'Verifiable' Has to Mean for a Machine

EVIDIQ's 0G TEE verifiable AI attestation is the practice of canonicalizing a trust report, hashing it with keccak256, anchoring the digest on 0G Storage mainnet, optionally analyzing with GLM-5.2 inside a TEE, and signing the verdict with an EIP-191 key — so anyone can re-fetch the evidence, re-hash it, and recover the signer without trusting the issuer.

Every phrase in that definition does work. Drop "canonicalize" and verifiers stop agreeing on what they signed. Drop the hash and the storage anchor is unfalsifiable. Drop the anchor and signatures float free of public commitments. Drop the signature and the report is, legally, somebody's blog post.

The Stakes in 2026

Agents are transacting on x402 rails, calling paid endpoints, holding USDC authorizations, and asking other agents to hand over tokens for tasks. Each handshake is a tiny trust decision: do I send funds to this counterparty, or hold?

"Verifiable" can't mean "we logged in and looked at it." The verdict has to survive being replayed from raw bytes, by anyone, in any jurisdiction, with no callback to us. Three things follow:

• The evidence has to live on storage that isn't us. 0G Storage mainnet qualifies.
• The cryptographic hash of the evidence has to be anchorable. keccak256 is the cheapest credible option on the EVM side.
• A signature has to be tied to a key the world knows. EIP-191 signatures recover cleanly over the same curve.

Skip any one of those and you've built a pretty dashboard. Pretty isn't the same as defensible.

Four Links in the Chain

We chain four operations in a fixed order. Each one is cheap; each one is removable in principle; removing any of them leaves the report downgradeable in a way that matters.

The chain:

1. Canonicalize the report. Strip non-deterministic fields, sort keys, pin a JSON spec (RFC 8785-style). The same input must produce the same bytes.
2. keccak256 the canonical bytes. A 32-byte digest stable across every implementation.
3. Anchor the digest on 0G Storage mainnet. We get back an on-chain tx that names the root hash.
4. EIP-191 sign the digest with our publisher key. Anyone can recover the signer.

[IMAGE_PROMPT: Modern flat illustration in developer aesthetic, muted teal and orange palette, isometric chain of four interlocking cryptographic blocks connected end-to-end with data bytes flowing through pipes between them, each block showing a different abstract icon (sorted grid for canonicalize, hex pattern for hash, on-chain tile for storage anchor, signature ribbon for sign), subtle dotted grid background, no text, no real logos]

That's what makes our pipeline an end-to-end 0G TEE verifiable AI attestation rather than a fancy JSON export.

What Breaks if You Skip a Link

Canonicalize, or don't — your downstream verifiers stop agreeing on what they signed. The same report rerendered by a different library yields a different hash, and your "re-verification" produces a mismatch nobody can debug. Field ordering, Unicode normalization, and float precision are the usual suspects.

Drop the hash and you've got a blob on storage nobody can prove belongs to this report. Sure, the URL fetches it — until the storage provider reshuffles or a malicious proxy swaps the bytes.

Skip the anchor and you've stored evidence nobody can verify wasn't planted retroactively. 0G Storage gives you a public, replayable commit on a ledger. Lose it, lose the audit trail.

Without a signature, the report is unsigned hearsay. Anyone could publish "EVIDIQ said agent X is trustworthy." Without a recoverable signer it's just text.

Each link is necessary. None of them, individually, is sufficient.

What the TEE Actually Buys You

Plain LLM API calls have a standing problem: you sent a prompt to a URL, got text back, and have no cryptographic proof that the inference ran unmodified — same weights, same system prompt, same provider — between your request and your evidence. A vendor could swap to a cheaper model mid-month, or a compromised endpoint could be running somebody else's policy. Output looks identical from the outside.

What turns a signed log into 0G TEE verifiable AI attestation is the TEE step. In our 0G Compute pipeline, GLM-5.2 runs inside a TEE that emits two pieces of evidence:

• The provider address — the on-chain identity of the compute provider that executed your inference.
• The request id — the unique identifier EVIDIQ assigned to your scoring job.

Together, those two values let any re-verifier check that the response they're holding came from the same TEE session EVIDIQ dispatched. The cryptographic attestation report from the TEE (a signed quote, not a database row) is published alongside the report so the chain extends: 0G Storage anchor → TEE quote → AI inference output → EVIDIQ signature.

A concrete example makes this less abstract. An agent endpoint claims to expose a payment surface over x402 with a stated capability of "refundable ticket booking." We task GLM-5.2 inside the TEE to read the agent's skill manifest, cross-reference the declared capability against the tooling actually exposed via the served MCP surface, and flag mismatches — "declares refund ability but exposes no dispute endpoint," say. That analysis lives inside the TEE, signed by the TEE, and stitched into the risk component of the report.

A plain API call gives you logs you have to trust. A TEE gives you a signed quote you can re-check against the hardware vendor's root certificate. The math is simple: if the quote verifies and the request id matches, you know what ran.

Worth noting: we treat the TEE as evidence for AI risk analysis, not as the source of truth for the deterministic trust score. The score (identity0.3 + capability0.3 + reputation*0.2 + (100-risk)*0.2) is recomputable from raw inputs — that's a bigger guarantee, since the score itself can be replayed without trusting us at all. The TEE layer adds what the formula doesn't: a record of what generated the risk narrative, when, and in which environment.

If you're running this verification work yourself, the EVIDIQ Sentinel docs walk through the TEE quote verification flow, and the EVIDIQ Operator docs cover the operator side — spinning up the agent endpoints that get probed in the first place.

How to Re-Verify a Report Yourself, Right Now

Concretely, here's how the re-verify half of 0G TEE verifiable AI attestation works in your terminal. Take any report an EVIDIQ endpoint returns — say, the JSON body from verify_agent over x402 — and run four checks.

1. Pull the canonical form of the report. EVIDIQ embeds both the canonical JSON and the original under evidence_canonical and evidence_raw so you don't need to re-implement normalization to start.
2. Re-hash the canonical bytes with keccak256. cast keccak <report.json> from Foundry, or any equivalent.
3. Take the resulting 32-byte digest and look up the corresponding on-chain transaction on 0G Storage mainnet. The tx body contains the root hash; compare against your locally computed digest. Mismatch means tampering, full stop.
4. Recover the EIP-191 signer from the signature over the digest. ecrecover on EVM, or any secp256k1 recovery library. Compare against the EVIDIQ publisher key listed in our docs.

[IMAGE_PROMPT: Modern flat illustration in developer aesthetic, slate teal and amber palette, minimal terminal window panel showing abstract code-like commands and checkmarks next to a stack of three layers (storage block, digest block, signature block) with a verified-checkmark glow at the end, dotted background, no text, no real logos]

If all four checks pass, you've proven three independent things: the report hasn't been edited since it was anchored, it was anchored by an EVIDIQ-controlled key, and the key recovered is the one we publish. None of those require us to be online, to grant permission, or to log you in. Most complaints we hear about "verifiable" systems turn out to be scope confusion — verification means somebody else's bytes, somebody else's key, somebody else's ledger. If the only person who can check is the publisher, you don't have a verification system, you have an SLA.

Developers ask us: "What if your publisher key gets rotated?" Fair question. Each report embeds the key version it was signed under, and the rotation policy is documented in the EVIDIQ docs — old keys stay verifiable indefinitely, new keys have a grace window. The chain doesn't depend on a single live key.

If you want structured disputes or third-party countersignatures on top, the EVIDIQ Notary docs describe the optional notary layer that lets independent parties co-sign the same digest.