How to check an x402 counterparty before paying

Your agent reads a 402 Payment Required, signs, and pays. The whole thing takes less time than a blink, and it happens thousands of times a day to endpoints the agent discovered minutes ago. The payment is an EIP-3009 USDC transfer on Base: no chargeback, no escrow, no dispute button. Once the money has moved, the only thing you can do about a bad counterparty is not pay it again.

So the check has to happen before, and it has to be cheap enough to run every time. Here are the five checks we would run, in order of how much each one tells you. Everything below comes from operating an index of every x402 / EIP-3009 USDC transfer on Base, 1.4 million addresses and counting.

Getting one payment wrong costs nothing, which is the whole problem

In a recent week (August 2026) the median transfer we observed was about $0.006. A single bad payment costs less than a rounding error, so nobody disputes one and nobody notices one. That is exactly the trap. Agents don't make one payment; they make thousands, unattended. A counterparty that quietly takes the money and returns junk, or nothing, never shows up in an error log. It shows up in your books, weeks later, as a line you can't explain.

The checklist

1. The address is older than a few days

The cheapest signal there is. Look the address up on any Base block explorer and find its first transaction. Payment addresses of real services live for months and accumulate history. Scam addresses are created in batches, used briefly and abandoned, because burning an address costs nothing. Across our whole index, three out of four addresses are gone within a day of their first transfer; we wrote up what that population looks like.

Age alone proves nothing. Every honest service was new once. But an address that appeared days ago and is asking for money has earned the rest of this list.

2. Somebody has paid it twice

This is the single most telling behavioral question, and an explorer will not answer it for you: you need the address's full payment history grouped by counterparty. Real services have returning customers; an agent that bought a useful API call buys it again. A take-the-money-and-disappear operation has almost none: every payer pays exactly once, finds nothing there, and leaves.

For scale: among established recipients active in one recent week, the median share of one-off counterparties was about 45%. Plenty of honest services have plenty of one-time buyers. The pattern that should stop your agent is an address where nearly everyone paid once and never came back.

3. Its first money did not arrive with a thousand siblings

Fresh scam addresses are rarely funded one at a time. They are seeded in batches from a single source; that is what address-farm tooling produces. In one week of August 2026 we watched 6,708 newly funded addresses arrive in 119 groups, each group sharing a single first funding source. The largest group held 1,375 addresses. We have yet to meet an honest business model that needs a thousand sibling payment addresses created in a week.

You can check one address's funding source by hand on an explorer. You cannot see, by hand, that the same source funded a thousand siblings.

That takes the graph.

4. It does not sit next to a known incident

Money moves between related addresses. An address one hop away from a wallet already identified in a scam incident is not automatically guilty, but it is worth a pause, the way a phone number one digit off from a known fraud line is. This check is genuinely hard to do yourself: it needs a maintained list of flagged addresses and a transfer graph to walk. One caveat any serious implementation has to get right: a dust transfer sent to an address by a stranger must never count against it, or anyone could taint anyone for a cent.

5. Its activity grew like usage, not like a campaign

Real usage grows and breathes. Manufactured activity arrives in spikes, a burst of transfers far above anything in the address's own past, often right before the address starts advertising itself. One explorer screenshot won't show you this. A baseline over time will.

By hand, you get two checks out of five

Checks 1 and (partly) 3 are explorer work: a minute per address, fine for a one-off. Checks 2, 4 and 5 are graph work over the full transfer history. That is not realistic by hand, and it is not realistic at all for an agent that decides in milliseconds.

This is the gap WalletBureau exists to close. We run the checks above, plus a few more described in the methodology, against our index of the complete x402 / EIP-3009 history on Base, and compress the answer into a 0–100 score, a verdict (ok / caution / avoid), and the list of flags that fired, each with its reason in plain text:

curl https://walletbureau.com/v1/demo/score/0x8f3a…b1c2

The demo endpoint is free: a few checks per day, no signup. The paid endpoint returns the same JSON for $0.01 per call, paid over x402 itself, so your agent can vet an address in the same protocol it uses to buy everything else. If your agent speaks MCP, the same check ships as an MCP server and works with no configuration.

What a score will not tell you

A behavioral score reads payment history, so it cannot see what has no history. A brand-new address gets a neutral, low-confidence answer, not a verdict; we say so explicitly rather than guess. It cannot tell you whether the service behind an honest-looking address is any good. And it is a set of risk signals, not an accusation: a low score means the patterns above are present and worth your attention, not that the owner is a criminal. Every flag we return comes with its reason precisely so you, or your agent, can decide what to do with it.

The numbers above come from the WalletBureau index of x402 / EIP-3009 USDC transfers on Base; the queries were run on 2026-08-20. How we classify transfers and what each signal means is in the methodology.