We tried to buy one call from 100 x402 sellers. Most delivered. Almost nobody is buying.
Coinbase's x402 Bazaar lists 34,768 paid endpoints today, and a small industry of trust scores has grown around them. Our own x402 routes are probed by more than twenty of those indexes: uptime monitors, censuses, "trust" scanners. Their user agents say it plainly: never pays, no payment attached, reachability only.
That tells you whether a seller answers with a price. It tells you nothing about what the money buys. So we paid.
How we picked and paid
- A random sample. 100 sellers, drawn from the 1,466 eligible hosts with a published seed. Eligible means x402 v2, HTTPS, a declared example request, and an
exactUSDC offer on Base of at most $0.01. Our own listings were excluded. - The seller's own example. Each seller got exactly the example request from its own listing. That is what an agent copying the documentation would send.
- A dry run first. One unpaid request to read the 402. Then the purchase, on exactly the terms the dry run saw.
- A narrow buyer. The reference x402 client, capped at $0.01 per call and allowed to sign only an EIP-3009
transferWithAuthorization. It never signs a permit and never an approval. - Charged or not. Read from USDC's
authorizationStateon Base, not from what the seller says. - Answer or not. Judged by a five-model jury, the same one that releases escrow in our Pay-on-Verified flow. Its question: is this a genuine, complete answer of the kind the listing promises, and not an error, an empty list, a placeholder or a demand for more money?
What came back
| Outcome | Sellers |
|---|---|
| Answer accepted by the jury | 74 |
| Answer rejected by the jury, buyer charged | 3 |
| Answer received, jury not confident either way | 8 |
| Error after payment, buyer not charged | 9 |
| Error after payment, buyer charged | 1 |
| Not bought | 5 |
Totals: - 95 payments signed, for $0.536. - 85 executed on chain, for $0.489. - 74 of the 85 paid calls (87%) returned a real answer. Among those we checked by hand: a 768-number embedding, a Wikipedia article, Product Hunt data, a correct inverse Web Mercator projection. - 4 of the 85 took the money for nothing useful.
Not fraud: broken examples
The commonest defect was not a scam. It was the listing. About one seller in ten advertises an example request that does not work: - the service rejects its own sample input; - a required field is missing from the example; - the call needs a header the listing never mentions; - the example URL points at a page that does not exist; - the "example" holds placeholders instead of values.
Most of these sellers did the right thing on failure and did not settle. Several even say so in the error body: you were not charged. That is good engineering.
But for an agent, the listing is the API contract. If the documented call fails, the agent stops there, and the seller never learns that it lost a customer.
Four times the money went for nothing
- An error returned after the charge: the reference in the seller's own example had expired.
- An empty list, for $0.01.
- A snapshot whose own status was "partial, indeterminate".
- An error report where the promised data should have been: the listing's example pointed at a placeholder host.
That is $0.022 out of $0.489. The sums are small because the prices are small. What matters is that a probe that never pays could not have seen any of it.
What a 402 probe cannot see
A few things surfaced only because money moved:
- A settlement that did not happen. One seller's settlement header said the payment succeeded, but the chain says the authorization was never used. We got the answer for free, and the seller's books are wrong.
- A 402 mixing protocol versions. One 402 combined x402 v1 and v2 fields, so the reference client refused to pay. No buyer using the standard SDK can pay that seller.
- A changed payee. One listing named a different payee from the one in its live 402. We did not pay it.
- A changed price. One price had doubled since the listing was published.
The real finding: almost nobody is buying
The Bazaar publishes its own 30-day counters: - 65% of all listings had exactly one paying wallet. The Bazaar lists a route after its first payment, so that one payer is most likely the seller itself. - Only 1.1% had ten payers or more. - In our sample, 23 of the 74 sellers that delivered a genuine answer had exactly one payer.
The services mostly work. The buyers are not there yet. Our own paid routes tell the same story: during the test, they were visited by more index bots than customers.
If you sell on x402
- Run your own listed example with a real payment after every deploy. Run the documented call itself, not a health check.
- Settle only after you have produced the answer. Most of you already do.
- Never report a settlement you did not make.
- Keep the listing and the live 402 in step: the same payee, the same price, and v2 fields only.
You can check yourself with the same tool; the unpaid step is free:
cd scripts/delivery-survey && npm ci
node survey.mjs catalog --out bazaar.json
node survey.mjs sample --catalog bazaar.json --host your.host --cap 0.01 --seed self --out plan.json
node survey.mjs probe --plan plan.json --out probe.jsonl # unpaid: your own example and your 402
node survey.mjs buy --plan plan.json --probe probe.jsonl --out buy.jsonl --budget 0.05 \
--payer 0xYourBuyer --key-file wallet.json # one paid call per listing
node survey.mjs chain --buy buy.jsonl --out chain.json # charged or not, by the chain
Why we don't name anyone
One paid call on one day is thin evidence about a business, and our request may not be the use a seller had in mind.
- The public data is anonymized. It has price bands instead of prices, no hosts and no transactions, and rows are shuffled.
- The private evidence is pinned. The full file (host, request, answer, transaction, verdict) is fixed by its sha256 in the report.
- We are contacting the sellers whose listings had a problem, each with its own evidence.
Our interest, and the limits
- Our interest. We run AIMarket, a market where agents pay agents, and we sell verification, so we have an interest in this question. That is why the seed, the tool and the data are public. It is also why we are reporting the result that does not flatter a verification seller: most sellers deliver.
- The limits.
- One call per seller, on one day.
- The seller's own example only, so a trivial example passes with a trivial answer.
- The jury checks for a genuine answer of the promised kind; it does not fact-check every value.
- It covers only sellers at $0.01 or less on Base with a declared example.
Links:
- Full report, in English, Русский, Español, Français and 中文.
- Tool, open source, 22 tests: scripts/delivery-survey.
- Anonymized data: results/2026-10-05.json.
If a payment of your own fails, modelmarket.dev/tools/x402-check rebuilds the EIP-712 digest, recovers the signer and names the domain a failing signature was really made for. Free, no account.
If you build one of those trust indexes and want paid-and-judged data next to your uptime numbers, open an issue on alexar76/aicom. We would rather add to your scores than build another one.