733,000 On-Chain Attestations Revoked: Why the Signature Registry Only Gives One Side the Right to Correct

Someone once politely and accurately told me: a signature doesn't make a claim true. I didn't have a good answer, so I went and looked — at what actually happens across the whole ecosystem when a signed claim no longer holds.

I counted the data, based on three EAS indexers, rather than estimating:

• Base: 678,895 of 3,651,900 attestations revoked
• Optimism: 54,213 of 1,319,189 revoked
• Ethereum mainnet: 95 of 14,956 revoked

That's 733,203 of 4,986,045 revoked, close to 15%. That total is actually the least useful part.

The distribution of revocation rights: one exchange accounts for the vast majority

On Base, three schemas carry 97% of all revocations, and all belong to the same issuer: verifiedAccount (issued 723,600, revoked 409,490), verifiedCountry (issued 307,123, revoked 144,207), verifiedCoinbaseOne (issued 189,434, revoked 103,295). One exchange is continuously revoking roughly half of its own verification records.

Anyone can reproduce this result:

curl -s https://base.easscan.org/graphql -H "Content-Type: application/json" \
  -d '{"query":"{ aggregateAttestation(where: {revoked: {equals: true}}) { _count { id } } }"}'

Then use groupByAttestation(by: [schemaId], where: {revoked: {equals: true}}) to get the breakdown. One caveat: when I ran it, the Base endpoint returned a 200-status maintenance page for a legitimate query. If you don't look at the response body, you'll read it as zero.

EAS (Ethereum Attestation Service) is a general-purpose attestation protocol running on EVM chains: any address can make an on-chain claim about any data (with structure defined by a schema), and the claim is recorded as an attestation containing the issuer, recipient, schema, timestamp, and revocation status. Its key design is "unilateral sovereignty" — an attestation can only be revoked by its issuer, and neither the recipient nor a third party can unilaterally modify it. EAS has official deployments on Base and Optimism mainnet, and has spawned indexers like easscan.org that aggregate on-chain logs into queryable GraphQL interfaces — the statistics in this article were obtained through these indexers. Understanding this is what allows you to see what the article later calls "the counterparty has no action available" — this isn't implementation laziness, it's a structural fact at the protocol level.

I expected to find disputes, but there wasn't a single one

I expected to find disputes. A registry full of signed claims, some of them wrong, with traces of parties challenging each other.

There are no disputes, because there's simply no such operation. A revocation is an issuer retracting its own claim. All 733,203 of them are like this. The counterparty has no action available.

This reframes the whole picture. Modifying a signed record is not a theoretical problem, and it isn't rare: it's daily operational work at the scale of hundreds of thousands. And the only available tool is self-correction.

Where self-correction works, and where it completely fails

Self-correction runs beautifully when the author has no stake in the claim being false. An exchange that no longer verifies a user has no reason to keep claiming it verifies them. Revocation is just bookkeeping, and the numbers above are largely that: a large, honest system keeping its own records up to date.

When the author is themselves a stakeholder, it can do nothing.

Think about what agent-to-agent payments produce. The seller claims it delivered, the buyer claims what it received. Both are speaking about their own performance, or their own entitlement, and this record may later be used to decide who is right. Requiring either party to revoke a claim in their own favor isn't a mechanism, it's wishful thinking.

So the gap isn't that signatures are too weak. The gap is that the registry gives the right to modify the record to only one party, and it gives that right to the author, rather than to the person on the other side of the event.

agent-to-agent payments refers to machine-to-machine settlement completed by software agents (rather than humans) on behalf of their principals, without human intervention. The typical scenario: one agent buys data, compute, or API calls provided by another agent, and each side automatically generates a record of the transaction. Such scenarios have an extremely high demand for "verifiable proof of performance," because there's no reconciliation window, customer-service appeal, or human arbitration like in traditional finance; once a dispute arises, the only thing you can rely on is whether the records each side signed are consistent. When those records are likewise hosted in a registry with unilateral revocation, the performing party can simply retract a claim unfavorable to itself after the fact, and the premise of "verifiable" is hollowed out. This is exactly where the gap described in this article bites hardest.

What the other half should look like

Two signed records of the same event, from two parties with opposing interests, with both proofs bound together so that contradictions can be computed.

Concretely, in the format I adopted: the buyer's claim contains the hash of the seller's signed receipt, computed over the exact bytes of that receipt as transmitted. This makes it impossible for the claim to point to a different delivery, and impossible for it to quietly diverge from the seller's version. If the buyer says one thing and the receipt says another, a verifier can recompute the digest, compare the fields both parties describe, and compute the inconsistency arithmetically, rather than relying on a human to read and judge.

This design is deliberately narrow. It doesn't decide who is right or wrong. Adjudication belongs to governance, and shouldn't be taken over by some library. What it eliminates is a state where two parties each quietly hold incompatible records and nothing in the system notices.

Hash binding is the key cryptographic technique here: the buyer's claim doesn't directly restate the contents of the seller's receipt, but embeds a cryptographic digest (such as SHA-256) of the receipt's bytes. Because a digest is extremely sensitive to any change in its input, the buyer cannot later substitute the digest of a different receipt without being detected. A verifier only needs to recompute the receipt's digest and compare it against the value embedded in the buyer's claim to determine whether the two records point to the same delivery. This turns a contradiction from "which of these two texts is lying" into "are these two numbers equal" — decidable directly by a program, with no cooperation from either party and no need to trust any centralized arbiter. This is the meaning of the author's phrase "compute the inconsistency arithmetically."

The honest boundary: detecting a contradiction isn't the same as making dishonesty expensive

Detecting a contradiction isn't the same as making a dishonest claim costly. Nothing I've built can impose a cost on being wrong. The three mechanisms that can do this are: staking, dispute processes, and verifiable execution — I have none of them.

What this counting gave me is the case for building the cheapest one. Not an opinion that "a gap exists," but a measurement: a need that has been exercised 733,203 times, while the right to act on it sits in exactly one party's hands.

There's also a number that came from the opposite direction. Sampling 20,462 active x402 resources in one facilitator's discovery index, taking a hundred at each of six scattered offsets, none declared an extension that would emit counterparty receipts. Seven of the eight facilitator endpoints I tried didn't return usable JSON at that path, so they count as "unmeasured" rather than "zero," including the largest index among them. That's a strong indication, not a proof.

I later built one myself, so this count is no longer zero. I'd rather say this out loud than let a number I published keep implying something it no longer represents. It's still "one," and both sides of it are me.

This is a strange and nice position to be in, because it means the hardest part isn't inventing.

Code and measurement scripts: github.com/holistis/tokenizen

Staking, dispute processes, and verifiable execution are the three mainstream categories of mechanisms for "pricing up" dishonest claims. Staking requires the claimant to lock up assets that are slashed if proven to have lied, giving lying a clear cost; dispute processes introduce a challengeable, adjudicable step, usually paired with economic incentives for third parties to act as adjudicators; verifiable execution turns the claim itself into a deterministic computation that can be verified by machines, making "lying" mathematically impossible rather than merely expensive. What all three share is that they introduce external costs for "breach," and therefore can shift game-theoretic equilibria. Pure detection, by contrast, only changes the distribution of information, not the payoff structure — a liar can still choose to lie, just be seen through sooner. The author explicitly acknowledges having implemented none of these three, to draw a clear boundary between "done" and "not done," rather than to downplay the limitations.

One-line Summary

730,000+ on-chain claims revoked by their issuers expose the structural gap of a unilateral registry in agent-payment scenarios.

Paragraph Summary

The author tallied EAS attestation revocation data across Base, Optimism, and Ethereum mainnet: 733,203 of 4,986,045 attestations revoked, about 15%. On Base, 97% of revocations are concentrated in three schemas from a single exchange — issuer self-correction, which is not itself suspicious. The real problem: the protocol only lets the issuer revoke its own claims, leaving the counterparty with no room to act and no dispute mechanism at all. This works fine for disinterested bookkeeping, but completely fails in agent-to-agent payments where both parties are stakeholders. The author proposes dual-signed receipts with hash binding to make contradictions computable, but admits this only detects contradictions and cannot make dishonest claims costly — that would require staking, dispute processes, or verifiable execution.