Most writing about agent payments cites the headline number, which is in the hundreds of millions of dollars. Someone finally went and counted the other one — the money that actually changed hands between independent sellers and the agents buying from them — and it is $11,748 for a month. We think that number is the most useful thing published about this market so far, so we ran the same shape of measurement on our own catalog and are publishing the result here, including the parts that are not flattering to us.
The measurement is a research post by driftwatch, published late August 2026 from a full pull of the Coinbase CDP x402 Bazaar discovery catalog on 7 August 2026. The Bazaar publishes a 30-day call count and unique-payer count per registered service, which makes the whole thing countable:
Registered discoverable services 14,128
with >=100 paid calls in 30 days 287 (2.0%)
with >=1,000 paid calls in 30 days 26 (0.18%)
Total 30-day GMV, every seller combined $11,748Their other findings, in brief, are worth reading in full at the link: the best-performing independent operator grosses about $872/month; roughly half of all x402 transactions are self-dealing or wash trading; and the 2025 transaction spike was substantially one meme coin's pay-to-mint mechanic, after which wallet retention fell from about 87% to 5%.
None of that means the protocol is fake. It means the protocol's transaction count and the market's revenue are two different quantities, and only one of them was ever being quoted.
One service in their pull — 25 clean Ethereum RPC endpoints — was found by 641 distinct agents, who between them made 1,018 calls. That is 1.6 calls per payer. Six hundred and forty-one agents found the door, paid once, and did not come back.
Set that against the two services in their dataset with real demand:
x402.tavily.com 422 payers -> 55,372 calls (131 per payer)
stableenrich / exa 277 payers -> 12,085 calls (44 per payer)Only 32 services out of 14,128 — 0.23% — clear the bar of 20+ unique payers and 10+ calls per payer. Twenty-two services have 300+ payers and fewer than two calls each. That distribution, not the GMV, is the finding. A catalog can look populated and be a tasting menu.
We publish a set of usage figures at /api/stats that are deliberately defined to exclude bot polling, our own probes and team wallets, because an adoption number that counts your own traffic is not an adoption number. Pulled on 2026-09-19:
catalog services published 1,696
settled on-chain payments, lifetime 393 payments / 43.512 USDC
last 7 days:
paid calls 6
distinct paying wallets 5
active agents (distinct IPs, no bots) 7Two published figures, same 7-day window, divide to 1.2 calls per paying wallet. Their best-built service measured 1.6. We are not going to spin that: at n=5 and n=6 in the window, any ratio is noise, and the honest reading is only the shape. The shape is the same one they found in the well-built service — a small number of wallets, most of them paying once.
The lifetime figure is the other honest one. 393 settled payments and 43.512 USDC is what our entire on-chain history adds up to. Anyone reading a marketplace's endpoint count as a proxy for its business should hold both numbers at once.
It is tempting to put their endpoint-health probe next to our own catalog scan and declare a winner. That comparison would be wrong, and the reason is worth stating because the same mistake is easy to make in the other direction:
Different populations, different denominators, different probing rules. Ours says something about whether the links we publish are alive; theirs says something about whether a random sample of the open catalog is. Collapsing those into "we are healthier than the Bazaar" would be a category error, and the fact that the number favors us is exactly why we are not doing it.
The claim that half of x402 transactions are self-dealing is the kind of claim that should make any marketplace operator look at their own ledger, so we did — specifically at the wallets behind our published paying-wallet count.
One of the wallets paying us in the window sources from the same address space as our own infrastructure. It is not a customer. It is a sibling agent paying for calls as an integration test, and it is the kind of traffic that, counted as adoption, would make our funnel look wider than it is.
We then checked the published figure arithmetically against the definition that produces it rather than against the note's prose: the metric's own query over the ledger returns 6 distinct paying wallets for the window, the team-wallet filter drops 1, and the published number is 5. The figure provably does not count us — the exclusion is real and the number on /api/stats is what it claims to be.
What we changed is the guard that watches for this. It now reads the metric's own definition out of the deployed source at run time and does the subtraction, instead of reading a receipt table and asserting from provenance alone. A wallet paying from our address space that isn't matched by the team filter now fails the check by name, which is the case that would actually be a defect.
Their conclusion about what works is one we recognise from our own trial data: the services that survive resell access that an autonomous agent otherwise cannot buy, because an agent has a wallet and no credit card, no legal entity, and no way to sign a SaaS contract. They also note, correctly, that much of that arbitrage sits downstream of upstream terms of service that were not written with per-call agents in mind. That tension is unresolved in this market, and no amount of protocol design resolves it.
If you are building here, the number to instrument is calls per payer. It is the only figure in this post that revenue cannot inflate, and it is the one that told us something we did not want to know.