Where registration meets payment

An ERC-8004 registration is an entry in the Identity Registry and a document at a URI. A payment is a token transfer to an address. The registry and the transfer share exactly one field that could tie them together: the address an agent nominates to be paid at. Everything on this page turns on that one join, and on how weak it is.

There are two candidate addresses, and they are not the same thing. The spec’s own field is agentWallet: reserved registry metadata, changeable only by proving control of the new address, and cleared automatically when the agent is transferred. Beside it sits a community convention that appears nowhere in the spec, a services[] entry also named agentWallet, which carries no proof of control and is served over mutable HTTP. A rate computed on the second is a rate about what people wrote down.

What a match would establish. A matching address confirms that a transfer occurred and who received it. It never confirms who initiated it or why: airdrops, refunds, mistakes and an operator’s own capital returning from DeFi all look identical to it. And a seller with no match is not “not an agent”; it is not a registered ERC-8004 identity on the chains this census sweeps.

A plain stablecoin transfer is the primary measure: it is what “paid” means, and it needs no protocol to be true. On top of it, a payment can be flagged x402-style when its transaction also carries an EIP-3009 authorization from the same token, which is how x402 settles on EVM chains.

x402 is singled out for two reasons and no others. It is the one payment protocol the ERC-8004 spec name-checks — a registration document may declare x402Support— and it is the one with an independent index to check a count against. Other rails, Google’s AP2 and Solana’s among them, exist and are out of scope. The authorization signal is also broader than x402 itself: any gasless EIP-3009 transfer authorises the same way, so a count built on it is an upper bound on x402 and has to be checked against a second source before it is published.

Any figure produced this way is a lower boundon payment. It reads a fixed set of stablecoins and nothing else, so native ETH, every other token and every off-chain settlement are invisible to it, and a settlement aggregated off-chain leaves no per-transfer authorisation to see. Symbols and decimals have to be read from each contract rather than assumed: BNB Chain’s USDC and USDT are 18 decimals, not 6.

Attestation does not stand in for payment. Celo attests at a rate an order of magnitude above every other chain, and that rate is three addresses writing feedback for one platform’s batch of agents. It was never a measure of commerce. No report on this site lets one of these measures stand in for the other.

Every conformance figure on this site recomputes from a published run: one sweep per chain, each pinned to a block, each with its archive and sha256 committed. The payments side does not recompute that way yet, which is why this page carries the method and the population and no rate. A figure that cannot be recomputed from a run id is not published here.

Every run, with its archive →What the census covers →What each check measures →