Why would anyone manufacture payment volume?#
Understanding the incentive makes the detection obvious.
A seller wants to appear in a ranking, qualify for an incentive programme, support a fundraise, or simply look busier than it is. Volume and transaction count are the metrics everyone quotes. Both can be manufactured by paying yourself.
The cost is one transaction fee per fake payment. On the chains x402 settles on, that is a fraction of a cent. For a few dollars a seller can manufacture tens of thousands of payments, and the resulting rows are, on their face, identical to real ones: real addresses, real transfers, real settlements.
Note
This is not a crypto-specific failing. App stores had install farms, ad networks had click fraud, and NFT marketplaces had wash trading for exactly the same reason. Any public metric that is cheap to manufacture and valuable to show will be manufactured. The interesting question is which signals survive.
The five patterns#
1. Self-payment. Payer and payee are the same address. The crudest form and trivially detectable, which is why it mostly appears where nobody is looking. It is also sometimes innocent, since testing and internal routing produce it, which is why annotating it is better than deleting it.
2. Buyer concentration. A seller's volume comes from one or two addresses. A real market has a distribution; a manufactured one has a source. TRM's published filters remove flows concentrated in one or two payers and sellers with fewer than ten distinct buyers for exactly this reason.
3. Circular flow. Money moves A to B to C and back to A. Each hop is a genuine transfer and the net position is unchanged. This is the version that survives a self-payment filter, and catching it needs graph analysis rather than a per-row check.
4. Uniform timing. Payments arriving at a fixed interval, or in bursts of identical size. Human-triggered and agent-triggered traffic both have ragged distributions; cron jobs do not.
5. Uniform amounts. Every payment the same value to the cent. Real usage varies, even for a fixed-price endpoint, because the mix of callers varies.
| Pattern | Detectable from | Can be innocent? |
|---|---|---|
| Self-payment | One row | Yes, testing and routing |
| Buyer concentration | A seller's history | Yes, one large customer |
| Circular flow | The payment graph | Rarely |
| Uniform timing | A time series | Yes, scheduled jobs |
| Uniform amounts | A value distribution | Yes, fixed-price endpoints |
Every one of these has an innocent explanation in isolation. That is why no single check is a verdict, and why a tool reporting one of them as fraud is overclaiming. Several together, on a seller with a short history, is a different matter.
What can detection not do?#
Separate a careful faker from a real business, and this limit should be stated plainly rather than buried.
Two wallets controlled by one party, funded separately, transacting at irregular intervals in varying amounts, are not distinguishable from two unrelated parties by any on-chain method. The only thing that would separate them is information that is not on the chain.
The honest framing is that detection raises the cost of faking rather than eliminating it. Manufacturing volume that survives all five checks takes real effort, and a faker willing to put in that effort at scale is rare. That is a worthwhile outcome and it is not the same as a guarantee.
The error in the other direction#
The filters that catch wash trading also catch real activity, and TRM said so about its own method.
A single-purpose agent that buys one service repeatedly, on a schedule, in identical amounts, trips uniform timing, uniform amounts and often buyer concentration at the seller's end. It is exactly the automation the protocol exists for, and every heuristic flags it.
So a filtered figure is a lower bound on authenticity, not a measurement of it. Anyone presenting a cleaned number as the true one is making a claim their method does not support. How much x402 volume is real goes through the published estimates and how far apart they are.
What should you publish instead of a single number?#
Publish the signals, not a verdict.
For a seller you are evaluating, the useful figures are distinct counterparties over time, the share of volume from the largest payer, the proportion of self-payments, and how long the seller has been receiving payments at all. Those four tell you more than any composite score, and they cannot be collapsed into one without losing the thing you needed.
For an ecosystem figure, publish the evidence grade alongside the count, with the exclusions named. A reader can then apply their own standard, which is the only way a figure survives disagreement about method.
Frequently asked questions#
Is wash trading illegal here?#
It depends on jurisdiction and on what the volume was used to obtain. Manufacturing metrics to win an incentive payment or to mislead an investor has obvious legal exposure; inflating a leaderboard position may have none. This is not legal advice.
Can I tell if a specific seller is doing it?#
You can check the five patterns against the public record and form a view. You cannot prove it, and a seller with a clean distribution and a long history of distinct buyers is a much safer counterparty regardless of what it might be doing.
Does excluding self-payments fix the numbers?#
It is the cheapest improvement and nowhere near sufficient. Self-payment is the form a faker stops using the moment anyone filters for it.
Why not just require identity?#
Because the absence of identity is the feature that makes the protocol work for agents. Adding mandatory identity would solve the measurement problem by removing the thing being measured.
How does this affect a buyer rather than a seller?#
A buyer screening a seller is the main use. A seller with manufactured volume may still deliver, but its popularity is not evidence that it does, and popularity is usually what the buyer was relying on. Screening a counterparty covers the checks, and auditing a service's traffic is the longer version.
Where to check this yourself#
Roundhouse annotates self-payment on every settlement rather than silently excluding it, and publishes per-entity counterparty counts rather than volume alone. /transactions exposes the raw record with those annotations, and a wallet's own page shows its distinct counterparties over time, which is the single hardest figure to manufacture.