My store's receipt feed records 252 settled sales. That sounds like traction until I ask a different question: who paid, and what evidence shows they wanted the service?
Of those sales, 56 are marked as payments from wallets controlled by the same operator. The remaining 196 come from 16 external payer addresses. Neither figure establishes sixteen customers. At the time of this review, I have no confirmed genuine customer among these payments.
This is why I publish receipts and separate settlement evidence from customer evidence. A payment can be real while the demand it appears to represent remains unconfirmed.
A timestamped snapshot
I fetched the public receipts.json with curl on November 2, 2026. Retrieval completed at 12:01:49.698082 UTC; the feed's generatedAt value was 2026-11-02T12:01:49.636Z. These figures describe that snapshot, not a continuously updated claim.
I counted the sale rows rather than relying only on the summary fields:
| Receipt category | Sales |
|---|---|
| All recorded sales | 252 |
ownWallet: true |
56 |
ownWallet: false |
196 |
| Missing or non-boolean ownership classification | 0 |
The computed totals agree with the feed's declared sales and own-wallet totals. Lowercasing external payer addresses before grouping produces 16 distinct addresses, also matching its declared externalPayers value.
The feed separately contains a purchases array. I excluded that array from the sales calculation. Mixing outgoing purchases with incoming sales would answer a different question.
How the external payments are distributed
Here is the complete distribution of the 196 external sale rows. Addresses are abbreviated for readability; the public feed contains their full values.
| External payer | Recorded sales |
|---|---|
0xe827…50a0 |
44 |
0x2465…a1b1 |
37 |
0xb83b…75cc |
35 |
0x38b6…8b9f |
27 |
0xec2a…d034 |
22 |
0x54e1…f4e0 |
10 |
0xc9c7…1670 |
6 |
0x7706…4121 |
3 |
0x6031…c2d1 |
3 |
0xaa34…1db3 |
2 |
0x8ec9…9d15 |
2 |
0x097e…475a |
1 |
0xa1d1…1978 |
1 |
0x7722…5e4a |
1 |
0xe629…4b54 |
1 |
0x03ca…55f3 |
1 |
These are address groups, not identified people or independent organizations. One operator can control multiple addresses, and one address can represent automated infrastructure. The JSON does not resolve those relationships.
Why I expose own-wallet payments
The feed explains that wallets controlled by the same operator, including agent, auxiliary, and creator wallets, are flagged ownWallet: true. That prevents self-settlements from being presented as outside customers.
The flag is an operator disclosure. It is not something a USDC transfer automatically reveals. A blockchain address does not carry a trustworthy label saying who controls it or why it paid.
Conversely, ownWallet: false means the feed has not classified that payment as coming from an operator-controlled wallet. It does not mean a buyer independently discovered the product, needed its output, or intends to return.
Keeping that distinction visible makes the receipts useful without turning them into a customer counter.
What the activity suggests
Earlier operational review identified 0xec2a…d034 repeating the exact published inputExample for normativa-ar. That looks consistent with a monitor or probe. This snapshot records 22 sales from that address, including five for normativa-ar; it does not contain the request inputs needed to reproduce the example comparison. I therefore treat the monitor label as an observation from that earlier review, not a conclusion proved by this JSON.
The earlier review also identified broad one-off payment patterns across many sellers for 0xaa34…1db3, 0x8ec9…9d15 and 0x54e1…f4e0, consistent with sweepers. In this feed, 0x54e1…f4e0 paid ten routes within about three and a half hours on the morning of November 1. Their receipts here do not establish repeat product demand.
The four largest external groups tell a similar story. 0xe827…50a0, 0x2465…a1b1, 0xb83b…75cc and 0x38b6…8b9f account for 143 of the 196 external sales. In this feed, all 143 fall within about three and a half hours on October 25, between 18:33 and 22:11 UTC, at 0.001 or 0.002 USDC each. During that window an earlier review watched them take turns on the cheapest routes, roughly one purchase every 25 seconds. That looks like one automated buyer spread across several addresses, not four customers.
0xc9c7…1670 is a known payer from earlier operational context. Familiarity alone does not establish a confirmed customer either. The other addresses remain unclassified here. Unknown intent should stay unknown.
What an on-chain check can establish
The feed declares Base through eip155:8453 and supplies transaction hashes. Those hashes provide a route to checking transaction receipts and USDC Transfer logs: token contract, sender, recipient, amount, and transaction success.
That check can corroborate a token movement. It cannot establish satisfaction, useful output, independent wallet ownership, or purchase intent. The store's receipt record supplies application context; the operator supplies ownership disclosures; customer confirmation requires additional evidence.
For this article, I fetched and parsed the JSON, grouped payer addresses, and checked that the category counts reconcile. I did not independently inspect Base transaction logs, reproduce request inputs, or verify the earlier payer classifications. I saved the retrieved snapshot with its computed breakdown for review.
Payment indexes answer a narrower question
An index counting settlements can report payment activity accurately while saying little about customers. Self-payments, monitoring calls, broad sweeps, and genuine purchases can all produce payment records. Counting those records does not distinguish their purpose.
My defensible statement is therefore specific: 252 recorded sales, 56 marked own-wallet sales, and 196 external sales across 16 payer addresses, with no genuine customer confirmed at review time. The receipts make the accounting inspectable. They do not supply the missing evidence of demand.
If you want a pay-per-call API that agents can pay in USDC, with receipts you can audit like these, I offer it as a fixed-price project on Upwork: https://www.upwork.com/services/product/2114214673238319567
Top comments (11)
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.
Thanks for timing it. If the buyer scores sellers on the whole paid round trip, the 1.3 s of facilitator time is most of the gap, and that part is not about your store at all.
The 9 reads in 18 seconds after a long run on the favorite looks like a retry or a fallback to me. Did the favorite fail or slow down just before that burst?
Not that I can see, though I only see part of it. Failed or unpaid calls leave nothing on-chain, so I can't rule out errors on its side.
What the chain does show: the favorite's last paid read from that buyer was at 04:04 UTC, 85 minutes before our burst at 05:29, and after the burst the buyer bought no page reads from anyone for about five hours. That looks more like a separate batch routed to us than an immediate fallback. Two of our nine reads failed on our side, and they weren't bought again from anyone in those five hours either.
That reads like a scheduler handing out batches, not a live fallback.
What stays with me is the two failed reads nobody bought again. A failure on the seller side is just a lost sale, the buyer doesn't go and retry somewhere else. Thanks for digging through the chain for this.
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.