Why can you audit a seller at all?#
Because x402 settles on a public chain. Unlike a SaaS vendor's usage figures, a seller's payment history is not something you have to be shown.
That is the whole advantage and it is worth being precise about its limits. The chain tells you what was paid, by whom, when, and who relayed it. It does not tell you what was delivered, whether the buyer was satisfied, or whether the payments were genuine commerce. The audit below gets you a long way and stops short of certainty.
The seven checks#
1. Distinct buyers over time. The most informative single figure. A seller with hundreds of distinct payers across months is hard to fake. One with thousands of payments from four addresses is not a market.
2. Largest payer share. What proportion of volume came from the single biggest counterparty. Above roughly half, you are looking at one customer or one wallet, and the seller's "volume" is really one relationship.
3. Self-payments. Payer equals payee. Any material share is a flag. Some is innocent, from testing or internal routing, and a lot is not.
4. Age of the first settlement. How long this address has been receiving payments. A seller that appeared three weeks ago with large volume is a different risk from one with eighteen months of steady activity.
5. Amount distribution. Real traffic has a ragged distribution. Thousands of payments at exactly the same value, from varied addresses, is a pattern worth asking about.
6. Relayer mix. Which facilitators relayed the settlements. A seller whose payments all came through one facilitator is normal. One whose payments were never relayed by any known facilitator is not clearly doing x402 at all.
7. Catalogue presence. Whether the address appears in a published directory, and whether the terms there match what the live endpoint returns. Disagreement between the two is common and the live 402 is the authority.
| Check | Good sign | Bad sign |
|---|---|---|
| Distinct buyers | Hundreds, growing | Single digits |
| Largest payer share | Under a third | Over half |
| Self-payments | Negligible | Material |
| First settlement | Months ago | Days ago, with volume |
| Amounts | Varied | Identical |
| Relayers | Named facilitators | None identifiable |
| Catalogue | Listed, terms match | Listed, terms differ |
How do you run the checks?#
Start from the receiving address, which you get from the live 402 rather than from a directory. Then look up that address in a settlement index and read its counterparty history.
In Roundhouse that is a wallet page: /wallets finds the address, and the merchant view shows settlements received, distinct counterparties, the amount distribution and the relayer attribution. The data API answers the same questions programmatically if you are doing this for more than one seller.
If the address returns nothing, that is a result but not a conclusion. An index covers the chains it covers, from the block it started at. "No rows" conflates never-paid, not-yet-indexed and not-on-a-covered-chain, and a good index distinguishes those rather than rendering a zero.
Important
A zero on an index is a claim about the index as much as about the seller. Before concluding a seller has no history, check which chains the index covers and from when. This is the most common way an audit reaches a confidently wrong answer.
What does a clean audit not tell you?#
It tells you the seller has been paid, repeatedly, by many parties, over time, through recognised infrastructure. That is a real and uncommon signal, and it is the best thing available before you have any experience of your own.
It does not tell you the service works. Payments are evidence of purchase, not of satisfaction, and a service can take money and return rubbish. The record contains no repeat-purchase-after-disappointment signal because disappointment is not on-chain.
The practical consequence: use the audit to rule sellers out, not to rule them in. A failing audit is a good reason not to proceed. A passing one means you should make a small purchase and check the output yourself.
Doing this as an agent#
The checks above are all queryable, which means an agent can run them before paying rather than a human running them afterwards.
A reasonable automated policy, in rough order of cost: refuse any payee with material self-payment, refuse any whose largest payer share is above a threshold you set, prefer payees with more distinct counterparties, and cap the first payment to a new payee at a small amount regardless of how good the history looks.
That last rule is the one that matters most, because it is the only one that holds when the record is incomplete. Screening a counterparty covers the full policy shape, and wash trading covers which signals survive a determined faker.
Frequently asked questions#
What if the seller uses several receiving addresses?#
Then the per-address picture understates it, and you may be looking at one of many. Some sellers rotate addresses deliberately. This is a real limit of address-based auditing and there is no clean fix from outside.
Does a long history guarantee anything?#
No. It raises the cost of having faked it and it says nothing about delivery quality. It is a prior, not a verdict.
Can I audit a buyer rather than a seller?#
Yes, and the checks invert. For a buyer you care whether it pays reliably, how much it spends, and whether its counterparties are varied. The same record answers both directions.
How fresh is the data?#
Depends on the index. One that does not publish its lag behind the chain tip is asking you to assume it is current. Check for a coverage statement before relying on recency.
Should I weight volume or counterparties?#
Counterparties, decisively. Volume is the cheapest figure to manufacture and counterparty breadth is the most expensive. Wash trading covers why.
Where to check this yourself#
/wallets resolves an address to its settlement history, with distinct counterparties, relayer attribution and self-payment annotated rather than silently excluded. /services shows the catalogue side including listed prices, and coverage and confidence states what the index can and cannot see so a zero can be read correctly.