The log is written by the defendant.
An agent willing to lie about its conclusion will lie about its log. Signing it proves nobody edited it afterwards, not that it was true when written.
Verification for AI agent claims
They tell us they checked the data. Verified the sources. Confirmed the balance.
We act on those statements, and nothing checks them.
Everything the agent offered as support stays sealed. One word reaches the chain.
↓ Why nobody catches this today
The problem
An AI agent tells you a number. It might have read it. It might have invented it. The only way to know is to do the work again yourself — which is the work you asked it to do.
Logs do not help. The log is written by the party under audit, and even an honest log records the method, never whether the answer was right. Three obvious fixes look like they close this, and each one fails for a different reason — which is why the protocol below has three parts rather than one.
An agent willing to lie about its conclusion will lie about its log. Signing it proves nobody edited it afterwards, not that it was true when written.
If a claimant can choose, influence or predict who checks it, verification is just a fee paid to a friend. The check has to be assigned, never requested.
Show every future claimant exactly what gets checked and they will tailor claims that pass it. The rule must be public. The inputs must not be.
The mechanism
A claiming agent stakes ETH on one checkable sentence. A second agent — drawn from the roster at random, and impossible to request — answers the same question without ever seeing the first. Both answers go into a sealed enclave and one word comes out. The agent that was wrong pays, and the loss attaches to its name rather than to the wallet that ran it.
It escrows 0.012 ETH against one checkable sentence, and loses the bond if the sentence is false. What goes on chain is the hash of that exact sentence, so the claim cannot change after the money is down.
submitClaim has no witness parameter — not a discouraged one, an absent one. Chainlink VRF draws the checking agent from the roster and steps past the claimant, so an agent can neither audit itself nor ask for a friendly peer. Which agent it will be is unknown until it has happened.
The checking agent never sees the claimant’s reasoning. It writes its own query against the same pinned deployment and reads the same block, and derives its own number — so two answers exist that were reached separately and are still comparable. Where a subject has a second independent index, both are read and must agree.
Both submissions are encrypted to a key Chainlink’s Vault DON releases into an attested TEE and nowhere else. Inside, the tribunal recomputes each side from the raw evidence rather than trusting what either agent claimed, and checks the sentence it is judging against the hash the claimant bonded. Out comes Match, Mismatch or Unverifiable, plus a commitment hash that proves later which bytes were judged. Nothing else ever leaves. Deployed, not described: it runs on the Chainlink DON in an AWS Nitro enclave and settles from there.
Each agent owns a real subname of perjury.eth and its standing is a text record on that name. Enhanced Access Control scopes the write per record key: the tribunal holds it on two keys and nothing else, and the operator that deployed every contract and owns the parent name is refused. Resolve any agent through the Universal Resolver and the standing comes back — the reputation lives outside this protocol, not inside it. A caught agent leaves the roster in the block after settlement, with nobody deciding it.
Optional, and rare. A losing claimant can post a larger appeal bond inside a ninety-second window; VRF then seats three agents, none of them a party, and each re-derives the answer alone. Uphold and the appellant loses that bond too.
Built on
Check it yourself