I pay for these APIs with my own wallet and publish what happened. The volume this market gets quoted by is mostly wallets paying themselves, so I read the payments off the chain myself. I check whether the answer that comes back is actually right, against a source that cannot be the seller. And the verdict an agent gates on is backed by money that moved. Every weight and threshold behind that is published at how we grade. The sweep covers every USDC payment agents make on Base and Solana, every day. Free MCP server for your agent →
Why this differs from the x402 dashboard total
This headline counts USDC received at the seller wallets we track, on Base and Solana, over the last complete UTC day. Of it, $34,633 settled on Base and $72,814 on Solana (Solana is mostly Bitrefill and Laso). The /x402 dashboard sweeps Base only, so it shows roughly the Base portion; a rolling-24h window there also differs from a calendar day by a few percent. Every figure on this site carries its scope for exactly this reason.
26 ways paying an API as software goes wrong, each one learned by getting it wrong first. Most of these cost me a retraction rather than money.
api.surplusintelligence.ai publishes two payment options: exact via EIP-3009, which any x402 wallet can pay, and upto via Permit2, which needs a one-time on-chain approval. The standard one is listed first and its own instructions name it as the fallback. Our client chose Permit2 on all three attempts, including when forced to x402 on Base, and failed each time because an agent wallet holds no gas and has never sent a transaction. Read through that one client the seller looks broken. It is not. It is the fifth time a harsh finding here has turned out to be our own tooling.
What to do: Before grading a seller on a payment failure, read the whole accepts array and confirm your client tried an option it could actually use. Distinguish three cases that look identical from the outside: the seller published nothing payable, the seller published something payable that your client will not select, and your client selected correctly and the settlement failed. Only the first and third are the seller's. Grade completed purchases; when nothing settles, publish it as an observation and name the client.
2026-08-12. Three attempts against api.surplusintelligence.ai through agentcash, each choosing the upto scheme and returning permit2_allowance_required, while accepts[0] was exact on Base USDC at $0.0033. Nothing was charged: the Base wallet still held $1.9092 at nonce 0 afterwards. The same session found the probe misreading three other sellers by taking accepts[0] blindly when they listed Solana first.
The Bazaar ranks listings partly on calls and unique payers over 30 days. A service now sells that number directly: $99 to get listed, where they fire the indexing settlement from their own wallet if your price is a dollar or under, and $190 a year to keep sending your endpoint a small payment twice a month. The money lands in the seller's own payTo, so the heartbeat costs the seller nothing and the counter goes up. Nothing on chain distinguishes that from a customer.
What to do: Never read a registry's call or payer counter as demand. Count distinct paying wallets yourself from settlement logs, look at how evenly the dollars fall across them and how many buyers return, and check whether the money leaves again. Payments cost fractions of a cent, so any metric built from raw activity is priced in reach of anyone who wants to move it.
Product text quoted from the Bazaar registry on 2026-08-12. Of 14,668 endpoints listed 2026-08-04, 2,796 were gone seven days later and 111 hosts vanished entirely, but delisting did not track with non-payment: 10.8% of zero-call endpoints went against 20.6% of those with 1 to 9 calls.
89 addresses were generated to impersonate blockrun.ai's payment address, each matching it on at least the first four and last four hex characters. Truncated the way every wallet and explorer truncates, all 89 read 0xe9030…1abf, and so does the real address. Each sent a single USDC transfer worth a millionth of a dollar, whose only purpose is to sit in the buyer's history next to a real payment and get copied by mistake. The buyer, an agent, made 732,761 payments over the same period and sent every one to the correct address, because it reads the payTo out of the 402 challenge on each call instead of remembering it.
What to do: Read payTo from the live 402 challenge on every call and sign against that value. Never cache a seller's address between calls, never copy one out of a block explorer, and never reconcile by eye against a truncated address. If you must compare two addresses, compare all 42 characters or compare the checksummed form, never the middle-elided display.
Measured 2026-08-11 from Base USDC Transfer logs, roughly six days of blocks, zero failed ranges. 89 distinct senders, 89 transfers of 1 raw unit each, first 2026-08-09 07:51 UTC and last 2026-08-11 18:29 UTC. Real payTo 0xe9030014f5dae217d0a152f02a043567b16c1abf. Over the same window the targeted wallet paid it 732,761 times for $35,589.34 and paid a counterfeit zero times.
Six trust services were asked about a counterparty proven to charge twice and return nothing. An OFAC screen said PASS 100. A domain scorer said 50 of 100. A reliability check measured 100% reachable and 100% valid 402s, all true. A trust index called it live and operating. Only the one that compared the delivered response against the advertised schema and the settlement receipt answered inconsistent. A broken payout path scores well on every proxy, because the website works.
What to do: Use reputation for what it measures: sanctions, domain age, uptime, whether an address is KYC-linked. For whether you got what you paid for, check the goods against the promise. Keep the response, the settlement receipt and the advertised schema together, and compare them, either yourself or with a delivery attester.
Measured 2026-08-11 across lionx402, api.trustsource.cc, orcpin.dev, aeml-x402, 402.com.tr and groundcheck.seiche.info against api.jarvisclaw.ai. $0.054 spent; the only service that caught it charged nothing.
Some sellers run the paywall in front of the router, so payment settles before anything checks whether the route exists or the method is right. keyronne.com declares POST; a GET to the same path settled $0.003 and returned the site's own homepage as text/html. Called correctly it returns a clean 422 that states charged: false, so the service is fine and the ordering is not.
What to do: Read the declared method and body from the bazaar schema before the first call, and treat a text/html content-type on a paid JSON endpoint as a failed purchase worth reporting. Good sellers reject a malformed request with a 400 and no charge: quartermaster did exactly that on the same class of mistake in the same session.
Observed 2026-08-11. Charged tx 0x5432aeb5d6a2988cf3530380488bf95c76e21350d90f031afc37de44e294d8d5 for a GET that returned HTML.
Two sellers answered the same balance query fourteen seconds apart and returned different numbers. Both were right; the difference was a fee paid in between. Only one stamped a block number. A wall-clock timestamp tells you when their server replied, which you cannot verify and cannot reproduce. A block height pins the answer to a state anyone can re-read forever.
What to do: Prefer sellers that return the block, slot or height their answer was read at, and store it with the answer. When a chain read is not stamped with a block, treat it as an assertion rather than a citation, and re-read it yourself before acting on anything expensive.
Measured 2026-08-11 across anywaypossible.com, which returned blockNumber 49817928 with the reading, and signals.edge.report, which returned only generatedAt. Both matched the chain at the moment asked.
A seller can return an error that says settlement failed while the transfer has already settled. On 2026-08-09 api.jarvisclaw.ai answered 'user settlement failed' twice and our payment client reported payment: null both times. The chain shows two transfers of $0.001656 left the wallet, one per attempt, to the exact payTo the endpoint advertises. Nothing was ever delivered.
What to do: Reconcile against the chain, not against your client. After any session, read USDC Transfer logs out of your own address and match every debit to a response you actually received. Treat a reported failure as a reason to check before retrying, because a retry can be billed again. Nothing but the chain is a receipt.
Found two days late, and only because a balance series showed a daily drop of $0.034312 against $0.031 of known spending. The missing $0.003312 was exactly two undisclosed charges. The entry for that endpoint originally said no money was charged; it was corrected from D to F.
Measured across 220 origins on 2026-08-08: all 211 that answered with a parseable challenge put it in the payment-required header, and only 74 also put it in the response body. That means 63% of sellers return a 402 whose body contains no accepts[] at all. A client that parses only the body concludes most of the market is broken.
What to do: Read all three locations and stop at the first hit: accepts[] in the body, the payment-required header as base64 JSON, and WWW-Authenticate in both the X402 requirements="..." and MPP request="..." forms. Lowercase the header map first, because casing varies by server.
Body-less sellers include x402.tavily.com, stableenrich.dev, stableupload.dev, x402.twit.sh and api.loyalspark.online. This is the bug behind this site's own false '56% unpayable' headline, and behind a rival scanner grading BlockRun an F.
Sellers advertise a three cent action while every cheap action presupposes state you can only buy with an expensive one. FortClaw quotes $0.03 to heal a unit, but units only come from /start at $9.00. x402.boats quotes $0.10 to upgrade a ship you can only get by spending $2.00 first.
What to do: Before budgeting from the cheapest quote, check whether the endpoint takes an id or a slot that implies prior state. Read the bazaar schema's required fields: a required unit_id or slot means there is an entry fee upstream that nothing in the price advertises.
Observed 2026-08-07 across both mcp.fortclaw.com and mcp.x402.boats. In both cases a request without that state returns the same generic 402 as an unpaid request, so the real reason is invisible.
Sellers increasingly run a free tier that answers the same question as the paid call. TrustLayer's paid /agent/{id} and its free /demo/trust/{id} returned identical found:false for the same address, and the free one carried more fields. x402lint's full scan report is free at /v1/report while the paid call only buys freshness.
What to do: Read the OpenAPI or llms.txt and list which operations carry a 402 before spending. Where a free and a paid path cover the same resource, call the free one first and pay only if it is stale or thinner.
Measured 2026-08-08 and 2026-08-09 on api.thetrustlayer.xyz and api.x402lint.dev. The TrustLayer miss cost $0.001 for information that was free one path over.
A router's catalogue name and the weights that actually run can differ, and nothing in the request will tell you. On BlockRun, two separately listed free models, deepseek-v4-flash and step-3.7-flash, both return responses reporting nvidia/gpt-oss-120b. Neither advertised model is reachable under its own name.
What to do: Read the model field in the response, not just the one you sent, and compare them. Where a response does not echo a model id, treat the choice as advisory. If which weights ran actually matters to you, ask the model a question whose answer differs between candidates rather than trusting the label.
Observed 2026-08-07 across 36 free calls to blockrun.ai/api/v1/chat/completions. To BlockRun's credit the response discloses the substitution; the mismatch is in the catalogue, not the answer.
A service can publish a valid x402 quote and still refuse a standards-compliant payment, because it expects the signed payment in a header of its own choosing rather than the standard one.
What to do: Treat a second 402 after paying as a dialect problem, not a failure of your wallet. Read the error text: it usually names the header it wants. Check your funds did not move before retrying.
x402.boats, the top service by money received, answers a paid request with 402 and 'send the signed payment in the PAYMENT-SIGNATURE header'. Nothing settles and the balance is untouched.
Rank sellers by USDC landing at their payment address and some of the top entries are not selling anything. A game that returns stakes recycles the same pot; the inflow looks like revenue and is not.
What to do: Check what leaves the same wallet over the same window. Treat a high send-back rate as a flag to investigate, not a number to subtract: it can equally be cost of goods or a treasury sweep, and deducting it would punish any business with real suppliers.
x402.boats, a naval trading game for agents, took $6,897 and paid out $6,948 in the same six hours. Bitrefill sends back about 90% too, but there it is buying the gift cards it sells.
Coinbase and Circle both publish open registries of x402 services, and they overlap by ten hosts. Build discovery on one and your agent cannot see most of the market.
What to do: Read both. Coinbase indexes broadly and permissionlessly; Circle curates to named providers. Treat either alone as a sample, not a census.
Coinbase: 14,668 endpoints across 1,533 hosts. Circle: 943 across 22. Just 44 identical resource URLs in common, measured 2026-08-06.
USDC uses 6 decimals. Most BNB Chain tokens use 18. Divide every quote by a million and an 18-decimal one-cent charge reads as ten billion dollars.
What to do: Read the asset address, look up its decimals, then convert. Never assume six.
Cost me a nearly-published accusation against CoinMarketCap. 38% of the 27,099 priced payment options in the public registry use an asset that isn't six-decimal USDC.
A single 402 can offer many payment options across different chains and tokens. Take the first one and you may sign for the wrong asset on the wrong chain.
What to do: Decode every entry in accepts[] and pick the one matching what your wallet actually holds. 39% of listed resources offer more than one.
CoinMarketCap offers seven options across three chains, all worth the same cent.
It can be in the response body as accepts[], in a payment-required header as base64 JSON, or in WWW-Authenticate, which itself has two formats. Parse only the body and a large share of the market looks broken.
What to do: Check all three, and lowercase your header keys because casing varies by server.
Body-only parsing produced a false headline that 56% of endpoints were unpayable. The real figure was near zero.
Ask a market data API for BTC and you get 13 assets claiming that ticker. PEPE returns 32. Ask for SOL, take the first result, and you get Solcoin instead of Solana.
What to do: Query by the provider's numeric id, or filter on rank and drop anything unranked and priceless.
20 tickers returned 115 assets, 56 of them unranked. MORPHO returns 2, and the impostor has squatted the ticker since 2022, two years before the real one existed.
Some services mint a fresh receiving address per request. Compared against a registry entry it looks like a hijacked endpoint.
What to do: Probe the same endpoint twice. If the address changes between calls it is routing, not drift. Only a stable address that differs from the registry is worth flagging.
Nearly published a false payment-address warning about Tavily, which issues a new address every call.
Listings that share a payment wallet are the same business. Count them separately and you multiply both the size of the market and any revenue you attribute.
What to do: Group services by payment address before counting anything.
One wallet sits behind 148 listings, 77 of them subdomains of a single company. Another holds 88, a third holds 55.
Some endpoints charge a flat fee regardless of payload, which cuts both ways: generous on bulk requests, terrible on small ones.
What to do: Quote the smallest and largest request you would realistically make and compare before committing.
One market data endpoint charges the same cent for one coin or twenty. A gift card endpoint quotes a flat $25.00 whether you want a $5 card or a $1 top-up, and $500.00 for a malformed body.
A service can return a payment demand for a URL that does not exist, because the paywall fires before anything checks whether there is a product behind it.
What to do: Before trusting a seller, request a random path that cannot exist. If it asks for money, be careful.