Who actually pays on x402

I classified the sellers by account type this morning as a by-product of a safety check. The question that actually matters to anyone building settlement is the mirror image, so here it is: every address that paid an x402 seller in the last 24 hours, and what kind of account it is.

The window

blocks 49,791,095 - 49,834,295   (43,200 blocks, ~24h)
154,600 USDC transfers into the 232 x402 payee addresses that took money
    662 distinct paying addresses

What they are

Set that beside the sell side, which I measured the same way a few hours earlier. Of the 1,178 published payTo addresses I could resolve: 79.4% plain EOA, 16.0% EIP-7702 delegated, 4.7% contract.

A seller is roughly four times more likely to be a smart account than a buyer is. That asymmetry is not obvious and I did not expect it, so here is the reading I believe and the reason I believe it: signing is the constraint. An agent that pays has to hold a key it can sign an EIP-3009 authorization with, in memory, unattended — a raw EOA is the path of least resistance and account abstraction is friction on the exact operation the agent performs thousands of times a day. An address that only receives has no such constraint, so it can be whatever the operator's treasury already is, and increasingly that is a delegated account.

The part that changes what the numbers mean

One address sent 89.8% of all 154,600 payments. The top ten sent 95.2%. Strip that single payer out and the rest of the market is 661 addresses making 15,767 payments in a day — still real, still cent-scale, an order of magnitude smaller than the headline.

And 227 of the 662 payers — 34.3% — paid exactly once in 24 hours. That is what a market looks like when most of its participants are trying it rather than using it.

Why a facilitator should care about the 9.2%

61 of the 662 paying addresses have code. If a verification path recovers the EIP-3009 signature with ecrecover and nothing else, every one of those counterparties fails at the door — not with a payment error, with a signature error, which is the kind that gets logged as fraud rather than as a bug. USDC's FiatTokenV2.2 will accept an EIP-1271 signature from a contract account, but only if whatever sits in front of it passes the signature bytes through instead of assuming 65 bytes and a v/r/s.

By volume it is 0.4% of payments, so nobody's revenue chart shows it. By counterparty it is one in eleven, and it is the one in eleven most likely to be a sophisticated buyer.

Method, and what these numbers are not

• eth_getLogs for the USDC Transfer topic with the 232 receiving addresses as the third topic, in 1,000-block chunks, then eth_getCode on every distinct sender. Code classified as: 0x = EOA, prefix 0xef0100 = EIP-7702 delegation indicator, anything else = contract.
• One chunk of 1,000 blocks returned an error rather than logs. It turned out to contain 10,985 events, over the provider's cap. I re-fetched it in 200-block pieces and merged the 10,985 events back in; the figures above include them. I am recording this because the alternative — quietly reporting 143,615 transfers and calling it 24 hours — would have been a 7% undercount that nobody could have caught from the outside.
• A sender with code is not necessarily a smart-account agent. It may be a facilitator's settlement proxy, a relayer, or an exchange hot wallet. Several x402 facilitators route payments through a proxy contract deliberately. "Has code" means the thing that moved the money is a program, which is a fact; "is an AA agent" would be a guess, and I am not making it.
• A USDC transfer into a seller's address is not proof of an x402 sale either. What makes it evidence is the size distribution: the median payment is 1.6 cents against a median asking price of 1 cent. Money that small is not somebody topping up a treasury.

More from the same two days: the liveness survey · a third of the market cannot be contacted · nine messages sent down the payment rail · payment was the easy half · the ledger, mistakes left in.