When a Seller Funds Its Own Buyers, Its Buyer Count Stops Measuring Demand

An on-chain analysis published today traced where the buyers on Base's x402 rail got their USDC, and the finding is worth repeating exactly as stated: for one seller, it claims at least 675 of 715 buyers had been funded by wallets that seller itself funds, accounting for at least 97.0% of that seller's volume.

The published summary sentence is the whole post in one line: when a seller's revenue funds its buyers, its buyer count doesn't measure outside demand.

We are not the authors of that analysis and we are not naming the seller as anything more than the analysis names it. The caveat the authors attach is real and we will attach it too: a common funder can legitimately be a faucet, an exchange, or a custodial service, and addresses are not people. But the method is sound and the shape it finds is not exotic. It is the default failure mode of any success metric on an open payment rail, and we know because the same audit, run in the other direction, describes us.

The measurement, and where it comes from

Attribution first, because a number without a source and a window is decoration:

• Source: ChainWard, chainward.ai/decodes/x402-on-base (surfaced on Hacker News 2026-09-28).
• Scope: settlements on Base in which the transaction was submitted by an address on x402scan's facilitator list and consumes a USDC EIP-3009 authorization, directly or through a facilitator proxy. Seller names are x402scan origin labels.
• Window: blocks 51,320,527–51,622,926 — 2026-09-15 00:00 to 2026-09-21 23:59 UTC.
• Data: ChainWard's own Base node plus Blockscout for longer histories; the facilitator list pinned at x402scan commit f205fbe.

In that window the rail did 407,959 settlements and $128,977.37 of volume across 7,660 buyer addresses and 4,920 receiving addresses — a median settlement of $0.008. Of that volume the analysis attributes at least $56,268 (43.6%) to money that looped back rather than money that arrived.

Why the count cannot carry the claim

Every column a marketplace naturally reaches for is cheap for an interested party to mint:

The rail is open and permissionless by design — that is the point of it, and it is why the same property makes both honest and manufactured demand look identical from the outside. The settlement record proves a transfer happened. It does not, and cannot, prove the money came from outside the seller's own orbit. That information lives in the funding graph, one hop away from the ledger everyone is reading, which is exactly why a seller count survives scrutiny while being wrong.

This is not a fraud technique that someone had to invent. It is what an unguarded metric degrades into. Which brings us to our own ledger.

The mirror image: our own traffic, counted as strangers

We publish a first-party x402 marketplace — 1,702 listed endpoints, USDC on Base, five free trial calls per signed wallet. Our public stats endpoint reports a trial-wallet count for the trailing seven days, and for most of this project's life that number was the headline we watched.

Trial wallets, 7-day window, measured 2026-09-28:

agentTrialWallets7d      1360
  of which first-party    1359     (127.0.0.1, our own IPv6 /64)
  external                    1

We ran the provenance trace on ourselves after reading the ChainWard method, and 99.9% of our own trial-wallet metric is our own probes. Nobody attacked us. We did it to ourselves by writing a probe that mints a fresh wallet per call — which is precisely what a legitimate first-time agent also does. In the column we were counting, those two populations are the same shape, and no amount of staring at the number separates them.

Our own delivery-failure ledger tells the same story from a different angle. Of 264 recorded failed deliveries, 235 came from loopback and 13 from our own IPv6 range. Sixteen came from anywhere else.

What actually survives as evidence

The useful question is narrow: which column would it cost a stranger something to produce? A wallet is free. An IP is shared, mobile, or rented. What we ended up trusting instead was a value the client has to carry deliberately and cannot guess:

1. An identity the client supplies and signs. We accept an X-Agent-ID header and store only HMAC(X-Agent-ID). It is privacy-safe — we never keep the plaintext — and a caller has to choose to send it. A probe that mints a wallet but no identity lands in the same bucket as a stranger, which is exactly the honest treatment.
2. An explicit reserved-value exclusion. Our own instruments self-identify with a reserved identity, so they can be subtracted by name rather than inferred away. The subtraction is printed, not silently applied.
3. A published caveat on the column that cannot be made exact. The stats response itself says, in the response, that wallet counts "can carry a first-party share". A metric whose limitation is written down where the number is read is worth more than a cleaner-looking number whose limitation lives in someone's head.

And the numbers that survive that treatment are small and we publish them anyway:

paidCalls7d              2       real settled paid calls, 7d
realAdoptingAgents7d     3       distinct HMAC(X-Agent-ID), 7d
agentPayingWallets7d     2       distinct paying wallets, 7d
agentTrialWallets7d      1360    of which 1359 first-party

The top three are the honest size of our external demand this week. Publishing them next to the fourth is the point: a platform that only ever shows you the flattering column has not told you anything about whether its rail is a business or a metronome.

Three checks before you trust any seller count

1. Ask what the denominator is made of. "N buyers" means nothing until you know whether those are addresses, wallets, signed identities, or funded humans. The word "distinct" does a lot of unearned work in this space.
2. Ask who funded the buyers. Demand from outside arrives as money from outside. If the settlement volume traces back to the seller's own address within a few hops, the revenue is a round trip, and the buyer count is measuring the seller's own transfer volume.
3. Ask which failure modes the number can express. A metric with no way to say this is partly our own traffic will report the same figure whether or not it is. That is the same defect as a health check that cannot distinguish "verified" from "unable to verify" — and it fails in the same direction: all-clear.

None of this requires assuming bad faith. The strongest version of the ChainWard finding is not that someone cheated; it is that at least $56,268 of a week's volume was money moving in a loop, on a rail whose public numbers presented it as an economy. Ours is not that we inflated anything; it is that our instruments, which we trust, were 99.9% of the metric we were reading. Both were true at once, and nothing in either dashboard could have told you.

We run an x402 marketplace for agents and we publish provenance checks on these numbers as part of the daily job. If you publish an x402 seller count, the funding graph is one hop away and it is the only place the answer lives.