Receipts count payments, not customers. Early x402 traffic is mostly builders' own test wallets plus scripts that hit every endpoint once. Keeping an explicit list of your own wallets and dropping them before counting anything removes most of the illusion.
Senior backend developer (.NET, C#, microservices) from Argentina. Running an autonomous agent that sells cheap x402 data and text services on Base at tienda.textokit.store.
Location
Buenos Aires, Argentina
Work
Senior Backend Developer (.NET) at ABS-TI, client Banco Galicia
Agreed, and that is the first filter the feed applies. Wallets the operator controls are flagged ownWallet: true (56 of the 252 in this snapshot) and set aside before anything else is counted. The harder part is what remains: most of the other 196 came from one bot spread across four addresses, plus probes and sweepers.
The check that has helped me most since then is repetition plus breadth on-chain. After this snapshot, one address (0x72c5…159b) paid twice, about 43 hours apart, on two different routes. Its USDC transfers on Base for the 24 hours up to Nov 4 16:30 UTC show 877 payments to 35 sellers, about 20.34 USDC, mostly to a few data and model APIs. That looks like a gateway buying routinely, which is closer to a customer than anything else in the list, even though it still says nothing about who sits behind it.
Paying again on a different route says more than anything inside a single receipt. 877 payments to 35 sellers in a day also makes me curious how it picks them.
Can you tell whether those 35 appear in a facilitator's discovery list, or does it look like it works from its own list? If it's the second, a discovery listing won't bring a seller to a buyer like that.
Senior backend developer (.NET, C#, microservices) from Argentina. Running an autonomous agent that sells cheap x402 data and text services on Base at tienda.textokit.store.
Location
Buenos Aires, Argentina
Work
Senior Backend Developer (.NET) at ABS-TI, client Banco Galicia
I checked that on-chain. In the 24 hours up to Nov 5 02:00 UTC the same address made 1,258 USDC payments to 51 pay-to addresses, and 50 of those 51 also appear as payTo in Coinbase's x402 discovery list (about 115k resources at the time). Those 50 received 1,240 of the 1,258 payments.
That fits a buyer that picks sellers from the discovery list, but it doesn't prove it, because most active x402 sellers are listed there anyway. One more data point: it isn't choosing on price either. For page reading it sent 113 payments to a seller charging $0.002 and 3 to us at $0.001.
Interesting that it paid the $0.002 seller 113 times and you only 3 times at half the price. If price is not the signal, my guess is position in the discovery list or how fast the first call answered.
Did you see whether the seller it prefers responds faster?
Senior backend developer (.NET, C#, microservices) from Argentina. Running an autonomous agent that sells cheap x402 data and text services on Base at tienda.textokit.store.
Location
Buenos Aires, Argentina
Work
Senior Backend Developer (.NET) at ABS-TI, client Banco Galicia
Partly. I can only time the free step, the first 402 reply. With five tries each from one host on Nov 5, the seller it prefers answered in 0.07 to 0.26 s, another page reader took 0.33 to 1.01 s, and we were in between at 0.10 to 0.96 s, mostly our tunnel, since the store itself answers in about 3 ms. So on what I can measure without paying, the favorite is the fastest.
I can't time its paid path without buying from it. Ours takes 1.6 to 4.5 s per paid read, and about 1.3 s of that is the facilitator's verify and settle calls.
It isn't a fixed winner either: right after a five-hour stretch where the favorite got 99% of the reads, it sent us 9 reads in 18 seconds. So speed looks like one input, but from the outside I can't tell what else goes into the choice.
Nice to see someone split settlement evidence from customer evidence. I can resolve three of your 16 external payers, because they pay our endpoints too and their user agents name them:
0xec2a…d034 (22 sales): lumiere-paycheck-prober, an x402 payment verifier
0x54e1…f4e0 (10): nohumans-scout, a directory that pays a cent to check that payments work
0xc9c7…1670 (6): vet402-observatory, another verifier
So 38 of your 196 external sales are verification probes, not demand, which leaves 13 addresses. In our on-chain counts on Base, about half the sellers that were paid at all were paid only by scanners like these, so your caution is well placed.
Senior backend developer (.NET, C#, microservices) from Argentina. Running an autonomous agent that sells cheap x402 data and text services on Base at tienda.textokit.store.
Location
Buenos Aires, Argentina
Work
Senior Backend Developer (.NET) at ABS-TI, client Banco Galicia
Thanks, Frits. I checked your three against our own data and they line up: /receipts.json shows exactly 22, 10 and 6 settled sales for 0xec2a…d034, 0x54e1…f4e0 and 0xc9c7…1670, and those three user agents (lumiere-paycheck-prober, nohumans-scout and vet402-observatory) appear in our access logs. We had them filed as a monitor, a sweeper and a known verifier, so it helps to have the names confirmed by someone who sees them from the other side.
One data point since the article: on November 2 the store got what looks like its first real buyer, a purchasing gateway that routes calls across many x402 sellers, which paid once for a page-to-text call. One purchase is not a customer yet, so it stays in the watch-if-it-repeats column until it comes back.
We're a place where coders share, stay up-to-date and grow their careers.
Receipts count payments, not customers. Early x402 traffic is mostly builders' own test wallets plus scripts that hit every endpoint once. Keeping an explicit list of your own wallets and dropping them before counting anything removes most of the illusion.
Agreed, and that is the first filter the feed applies. Wallets the operator controls are flagged
ownWallet: true(56 of the 252 in this snapshot) and set aside before anything else is counted. The harder part is what remains: most of the other 196 came from one bot spread across four addresses, plus probes and sweepers.The check that has helped me most since then is repetition plus breadth on-chain. After this snapshot, one address (
0x72c5…159b) paid twice, about 43 hours apart, on two different routes. Its USDC transfers on Base for the 24 hours up to Nov 4 16:30 UTC show 877 payments to 35 sellers, about 20.34 USDC, mostly to a few data and model APIs. That looks like a gateway buying routinely, which is closer to a customer than anything else in the list, even though it still says nothing about who sits behind it.Paying again on a different route says more than anything inside a single receipt. 877 payments to 35 sellers in a day also makes me curious how it picks them.
Can you tell whether those 35 appear in a facilitator's discovery list, or does it look like it works from its own list? If it's the second, a discovery listing won't bring a seller to a buyer like that.
I checked that on-chain. In the 24 hours up to Nov 5 02:00 UTC the same address made 1,258 USDC payments to 51 pay-to addresses, and 50 of those 51 also appear as payTo in Coinbase's x402 discovery list (about 115k resources at the time). Those 50 received 1,240 of the 1,258 payments.
That fits a buyer that picks sellers from the discovery list, but it doesn't prove it, because most active x402 sellers are listed there anyway. One more data point: it isn't choosing on price either. For page reading it sent 113 payments to a seller charging $0.002 and 3 to us at $0.001.
Interesting that it paid the $0.002 seller 113 times and you only 3 times at half the price. If price is not the signal, my guess is position in the discovery list or how fast the first call answered.
Did you see whether the seller it prefers responds faster?
Partly. I can only time the free step, the first 402 reply. With five tries each from one host on Nov 5, the seller it prefers answered in 0.07 to 0.26 s, another page reader took 0.33 to 1.01 s, and we were in between at 0.10 to 0.96 s, mostly our tunnel, since the store itself answers in about 3 ms. So on what I can measure without paying, the favorite is the fastest.
I can't time its paid path without buying from it. Ours takes 1.6 to 4.5 s per paid read, and about 1.3 s of that is the facilitator's verify and settle calls.
It isn't a fixed winner either: right after a five-hour stretch where the favorite got 99% of the reads, it sent us 9 reads in 18 seconds. So speed looks like one input, but from the outside I can't tell what else goes into the choice.
Nice to see someone split settlement evidence from customer evidence. I can resolve three of your 16 external payers, because they pay our endpoints too and their user agents name them:
So 38 of your 196 external sales are verification probes, not demand, which leaves 13 addresses. In our on-chain counts on Base, about half the sellers that were paid at all were paid only by scanners like these, so your caution is well placed.
How we tell them apart: fizzl.eu/research/x402-real-buyers...
(I make x402 Doctor / Fizzl)
Thanks, Frits. I checked your three against our own data and they line up: /receipts.json shows exactly 22, 10 and 6 settled sales for 0xec2a…d034, 0x54e1…f4e0 and 0xc9c7…1670, and those three user agents (lumiere-paycheck-prober, nohumans-scout and vet402-observatory) appear in our access logs. We had them filed as a monitor, a sweeper and a known verifier, so it helps to have the names confirmed by someone who sees them from the other side.
One data point since the article: on November 2 the store got what looks like its first real buyer, a purchasing gateway that routes calls across many x402 sellers, which paid once for a page-to-text call. One purchase is not a customer yet, so it stays in the watch-if-it-repeats column until it comes back.