Will a standard x402 buyer be able to pay you tomorrow?

Why

x402 lets a program pay for one API request, usually in USDC, with no account: your server answers 402 Payment Required with its price, and the buyer signs a payment and sends the request again. If one field in that 402 is wrong, the buyer gives up, and you never get paid for the call.

On Oct 21, 2026 we pointed a standard buyer (@x402/fetch and @x402/evm 2.27.0, default settings) at 1,500 paid endpoints from public x402 catalogs, picked from the 50,102 they list. It never paid: we kept each 402 and replayed the payment offline with a throwaway key. 1,391 endpoints answered with a live 402.

• 39 of them would make the buyer's payment fail (33) or have it sign a payment that stays open for more than a day (6). Every one of the 39 sat on a host that a catalog had already flagged, and it was still broken on Oct 21.
• On hosts no catalog had flagged, the buyer tried to pay 1,267 endpoints, and none failed on an x402 mistake. The only 2 failures there were paused deployments that answered 402 with no x402 offer at all.

The sample leaned on purpose toward hosts whose listings showed a problem, so these counts are not a rate for x402 as a whole. What they do show: most sellers are fine, and the broken ones were flagged in a listing and stayed broken. A catalog listing doesn't reach your inbox. This does.

What it checks

Each day the buyer requests each of your endpoints once, without paying, reads the 402 the way @x402/fetch does and signs the payment it would send, offline. Then we check that payment against the token's contract on its chain. These six things stopped it on Oct 21:

• Your 402 names its network the old way, like 'base', while it says it is x402 version 2, so the buyer finds no network it can pay on (v1 network names in a v2 challenge). Oct 21: 16 endpoints.
• The token name or version in your signing details doesn't match the token's contract, so the buyer signs a payment the token will reject (wrong EIP-712 domain in extra.name or extra.version). Oct 21: 12 endpoints.
• The payment you ask for stays valid for more than a day, so the buyer signs something that could still be collected long after the request (maxTimeoutSeconds over 86,400, or a Unix time in its place). Oct 21: 6 endpoints.
• The token address has no contract behind it, so there is nothing to pay with (asset is not a contract). Oct 21: 3 endpoints.
• The offer is only in the response body, without the header an x402 version 2 buyer reads (v2 challenge without the PAYMENT-REQUIRED header). Oct 21: 2 endpoints.
• The 402 carries no x402 offer at all, as when a host pauses a deployment (no x402 challenge). Oct 21: 2 endpoints.

We also try each of your offers on its own, as a buyer who pays only on that network, or only in that token, would. So a broken offer next to a working one still shows up: a second chain whose token name is off, say.

What you get

• The first check, free, within a day of your email: each paid endpoint we can find on your host, what the buyer did with it, and the field to fix where it failed.
• Then one run a day.
• An email only when something changes: an endpoint breaks, or starts working again. It shows the request we sent, what came back and the fix. A quiet day sends nothing.

A sample alert

What one looks like, for a made-up host:

Price

$10 a month in USDC on Base, paid after the free first check, and only if you keep the watch. No account. To stop, reply to any of our emails.

How to start

Email [email protected] with your host, or your /.well-known/x402 or openapi.json URL. Already have a fix note from us? Reply 'start' to it. Your first check comes back within a day.

Paying us

Send USDC on Base (the token at 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913) to the ChainWard treasury:

0xf7Ee65130Fb2B3bb42Cc5cbFED085d7D482667cD

The only address we use; copy it from this page, never from a transaction history. Look-alike addresses that share its first and last characters get planted in payment histories, so check every character. Then reply with the transaction hash, so we can match the payment to your host.

Limits

• We replay each payment offline with a throwaway key, so we see what the buyer would sign and whether the token would accept it. We can't see what happens after a payment: your handler, or the uptime of your facilitator (the service that settles the payment on-chain).
• Offers on non-EVM chains like Solana, and prices above the stock client's $1 cap, are reported, not judged.
• One unpaid request per endpoint a day, at least 1.2 seconds apart, with the user agent chainward-x402-lint/1.0 (+https://chainward.ai). No payment headers, and no redirects followed.
• POST endpoints get an empty JSON body. If yours needs a sample request before it answers 402, send us one.

Who runs it

ChainWard reads x402 payments on-chain and publishes what it finds: the weekly x402 seller board, which traces where the buyers of Base's top x402 sellers get their USDC, and our x402 decodes: one week of x402 on Base, two weeks later, six wallets paid only by each other and three top-ten sellers that pay their own buyers. Questions: [email protected].