What can you know before paying?#
More than in most markets, because x402 settles on a public chain. A payee's payment history is not something you have to be shown by the payee.
What you can establish, in one lookup:
| Check | Signal |
|---|---|
| Distinct counterparties | Breadth of real demand. Hardest figure to fake |
| Largest payer share | Whether "volume" is one relationship |
| Self-payment rate | Whether the payee pays itself |
| First settlement date | How long this has been operating |
| Amount distribution | Whether traffic looks organic |
| Relayer attribution | Whether these were x402 payments at all |
What you cannot establish: whether the service works. The record proves purchase, not satisfaction. Nobody records disappointment on-chain, so a seller can have an excellent history and return rubbish.
That limit is the whole reason the first-payment rule below exists.
A policy an agent can actually run#
Ordered so the cheap checks come first and the expensive ones only run on candidates that pass.
- Refuse any payee with material self-payment. Payer equals payee at any meaningful rate is a flag, and it is a single-field check.
- Refuse any payee whose largest payer share is above a threshold you set. Above roughly half, you are looking at one customer rather than a market.
- Prefer payees with more distinct counterparties over more volume. Volume is cheap to manufacture; breadth is not. Wash trading covers why this specific ordering matters.
- Treat a short history as a short history, not as a problem. New sellers are new, not bad. It changes the cap, not the decision.
- Cap the first payment to any new payee, hard, regardless of the record.
Rule 5 is the one that holds when the others return nothing, and it is the one to implement first if you only implement one.
Important
An empty record is not a clean record. An index sees the chains it covers from the block it started at, so "no rows" conflates never-paid, not-yet-indexed and not-on-a-covered-chain. Treating absence as a pass is the most common way this screening reaches a confidently wrong answer.
Where does the data come from?#
Start from the payee address in the live 402 response, not from a catalogue. Catalogue entries and live terms drift, and the live response is what you will actually pay.
Then look that address up in a settlement index. /wallets resolves an address to its counterparty history, and the data API answers the same questions programmatically, which is what you want if an agent is doing this per payment rather than a human doing it once.
Check the index's own coverage before trusting a negative. An index that does not publish how far behind the chain tip it is, and which chains it covers, is asking you to assume it is complete.
What a seller should take from this#
That your public record is read by buyers deciding whether to try you, and that the figures they weight are not the ones you would put in a press release.
Breadth of counterparties beats volume. Longevity beats a spike. Self-payment, including innocent self-payment from testing and internal routing, counts against you in any automated screen that is not sophisticated enough to tell the difference, and most are not.
The practical advice: route internal and test traffic through addresses separate from your production receiving address, and pick a chain with good indexer coverage so the history you are accumulating is visible to the buyers doing the screening. Making your API discoverable covers the rest.
What about identity rather than history?#
Registry identity exists and is weaker evidence than it looks.
ERC-8004 gives agents an on-chain registry identity, and adoption figures through 2026 were large. Empirical work on the same registries found most registrations were placeholders, with only a small fraction exposing a live service endpoint, and concluded that the reputation layer as deployed could not function as a trust signal.
So treat a registry entry as a weak positive. A payment history is evidence of behaviour; a registration is evidence of having registered.
Frequently asked questions#
How long does this take?#
One lookup, which an agent can do in well under a second against an API. It is cheap enough to run before every payment to an unfamiliar address rather than only on large ones.
What if the payee uses several addresses?#
Then your view is partial and you are screening one of several. Some sellers rotate deliberately. There is no clean fix from outside, which is another argument for the first-payment cap.
Does a good history justify a large payment?#
It justifies a larger one, not a large one. The record shows the seller has been paid; it does not show the seller delivers. Escalate the amount with your own successful experience, not with someone else's.
Can I screen the buyer instead?#
Yes, and the checks invert: does this address pay reliably, how much does it spend, are its counterparties varied. The same record answers both directions.
Is any of this required?#
No. It is a risk control you choose. For sub-cent payments the screening may cost more than the exposure, which is a perfectly good reason to skip it below a threshold and run it above one.
Where to check this yourself#
/wallets is the lookup, with distinct counterparties, relayer attribution and self-payment annotated rather than silently excluded. Vetting a counterparty is the step-by-step version, and coverage and confidence states what the index can and cannot see so an empty result can be read correctly.