The 400 you didn't pay for

2026-08-28. In wave 5 of our paid census, 99 endpoints answered a real, authorized USDC payment with HTTP 400. We first reported that as “sellers settle the payment and reject the request — money gone, no recourse.” Then we audited our own claim, twice, and both halves fell. This page is the corrected anatomy of the most common paid-call failure class on the network — and it is much better news than what we first published.

First finding: the contract was published all along

We made one unpaid request to every active listing and kept the entire 402 challenge instead of extracting a price from it. 97 of the 99 rejected purchases had declared their required parameters, machine-readably, inside the very challenge we paid against — 87 with fields marked required, 10 in a declared shape without the marker. Only 2 declared nothing. Our buyer read the price out of the challenge and nothing else, then paid against a contract it never looked at.

This is not one seller's habit; it is the network's norm. Across all 1,675 active listings: 82% (1,366) carry the extensions.bazaar block in-band (challenge body and/or the v2 payment-required header); 463 declare a genuine field-level response-body schema; 934 declare their parameters in some machine-readable shape; 36 hosts additionally serve schemas at /.well-known/x402. Getting these numbers right cost us two same-day corrections — our first derivation undercounted because our own collector truncated 27% of the challenges — and both corpora are retained. Dated entries on /methodology.

Second finding: the money mostly never moved

“Paid” in our verdict names recorded that a signed payment authorization was attached to the request. Our scout's error path never consulted the chain to see whether the seller actually settled it. So we audited retroactively against Base, and validated the instrument in both directions first: the query finds all six known delivered settlements at the same addresses and windows, so its zeros are real absences.

96 of the 99 rejected calls never settled. They cost nothing. Three are chain-confirmed settled-then-rejected: $0.0045 in total. The same audit across our first census (405 rejected paid attempts, 164 listings, 2026-08-16–21): 241 rows chain-proven unsettled at addresses that passed a positive control; 124 remain unknown (no control transaction at the current address — reported as unknown, not folded into either side); at most 34 rows, ≤$0.452, may have genuinely settled — an upper bound that also absorbs settlements from delivered calls whose proof was missing at attempt time. A single operator accounts for 21 of those 34 ceiling rows.

The conclusion we did not expect: on a rejected request, most x402 sellers decline the money. Conditional settlement — debated in the ecosystem as a future protocol feature — is already, in large part, how deployed sellers behave. The real capital loss to this failure class, project-wide, is tenths of a cent plus a bounded residue.

Who fixes what

Buyers: read the contract before paying. Our scout now refuses to pay when a challenge declares required parameters the call omits (declared_params_unmet, shipped 2026-08-27) — one unpaid request, decode the challenge, check the declared inputs, refuse on a mismatch. Paddock's verify_before_pay is the same rule as a product, and they have taken our pinned list of the 99 to run their pre-payment check against; the disagreements will be the interesting rows.

Sellers: let a bare probe reach the challenge. The cleanest fix we watched happen: anchor-x402's param-validation guard was firing on unpaid requests, so a bare GET got a 400 instead of the 402 challenge and 12 listings sat failing here. Reported 2026-08-26; fixed at the source within a day — the guard now runs only when a payment is attached, so discovery works and no one is charged for a call that cannot succeed. The operator's own words: a prober reading a wrong response as broken “is the correct read of a wrong response.”

Protocol: conditional settlement for the residue. For the small set that does settle before validating, moving on-chain settlement after the handler's 200 makes a malformed call cost the buyer nothing. The working group is discussing exactly this; our numbers say the residue is real but small, and the larger win is buyers using the pre-flight that 82% of the network already publishes.

The operators, by the record

We name the concentrations because the record clears more than it accuses. x402.ottoai.services (30 of the 99): every route declared its parameters, and none of the 30 settled — the seller took nothing for calls it rejected. vibesprings.net (11): all 11 declared required parameters we failed to send; none settled; the operator was told the same day and the fault-share is ours. 2s.io (10) and api.onesource.io (5): parameters declared (onesource's typed with enums and defaults, without a required marker — which is what first fooled our extractor); no settlements found. The three chain-confirmed settled-then-rejected calls belong to two hosts and total less than half a cent.

What this does not establish

Declaration status was measured 2026-08-27, one day after the wave; middleware does not usually grow schemas overnight, but the day matters and is stated. Where several endpoints share one payment address, per-call settlement attribution is impossible from the chain; our verdicts are per-address with positive controls, and every group without a control is reported unknown. The 34-row ceiling is an upper bound, not a count. And none of this measures response quality — delivery and settlement, not truth.

Data & replication

The pinned list of the 99 — one row per endpoint with declared inputs, the seller's error body, and settlement status — is at wave5-endpoints.json, CC-BY-4.0, byte-identical to the copy shared in the x402 working group. Machine-readable twin of this report: JSON. Method and the full correction trail: /methodology; census data: the first report. This page was wrong twice before it was right; the trail is the point.

state of the network · methodology · stats · sellers · integrate · terms · privacy