A 2xx Is Not a Delivery

teppi-xyz — Wed, 28 Oct 2026 07:26:09 +0000

We paid 422 x402 APIs 3,618 times and checked every answer. 69 were wrong, and every one was billed.

A transaction hash proves money moved. Nothing records whether anything came back for it.

x402 lets an agent pay for an API call with a stablecoin in the same HTTP request: the server answers 402 Payment Required, the client signs a payment, the server settles it and returns the answer. By the time the answer arrives the money has moved, and nothing in the protocol ever reads the answer. A 200 OK means the seller replied. It does not mean the reply was right.

So we measured it. From 31 August to 28 October 2026 we paid 422 x402 endpoints on 355 hosts, 3,618 times, at their listed prices, and held every answer to a check the seller could not see.

What came back

	Calls	Share
Paid	3,618
Answered 2xx	3,434	94.9% of paid
Could be checked against an independent answer	2,695	78.5% of 2xx
Answered 2xx and wrong	69	2.6% of checked
Answered 2xx with nothing to check against	739	21.5% of 2xx
No usable answer (error status, timeout, broken body)	184	5.1% of paid

Two facts in that table matter more than the rate.

Every one of the 69 wrong answers was billed. Not most: all 69 settled. In x402 a wrong answer costs exactly what a right one does.

Money moved for 144 calls that delivered nothing usable: the 69 wrong answers, 64 calls that returned an error or nothing at all after the payment settled, and 11 that answered 2xx with a body that could not be used.

Wrong answers cluster where checking is hard

Endpoints that report a public fact were almost never wrong: price feeds, chain reads and code runs gave 2 wrong answers in 1,133 checked. Endpoints that do judgment work were wrong far more often:

Class	Checked	Wrong	Share
research	159	16	10.1%
inference	239	12	5.0%
extraction	240	12	5.0%
search	554	24	4.3%
market data, onchain, compute	1,133	2	0.2%

This is the uncomfortable shape for agent builders: the calls an agent is least able to verify itself are the ones most likely to be wrong.

Three cases, each with its transaction

Every case below links to the published evidence: the request, the response hash, the settlement transaction and the check that ran. A seller who disagrees can publish its own probe in the same format, and it appears beside ours.

1. A search that ignored the query. A Federal Register search endpoint was asked for documents on a named regulation. Its answer echoed "term": null, reported 10,000 available results and returned the day's newest documents, none of them about the question. It did this on 5 of the 6 calls we could check, between 27 and 28 October, at $0.005 each, every one settled. Evidence

2. A number that froze for sixteen days. A market index endpoint returned 24,427 on every call from 3 to 19 October. Over the same days the public source it reports rose from 24,520 to a peak of 46,341. Ten of those answers were outside tolerance and every one was billed. Nothing about the response looked broken: right shape, right field, a plausible number. Evidence

3. Paid, then 503. An LLM endpoint settled our $0.002525 payment and answered 503 Service Unavailable with an error body. The payment is on Base: 0x101d4616…a4c4e7. Evidence

How an answer is checked

Held-out answers. For each endpoint we write tasks whose answer we know and the seller never sees: an RFC number that must appear among search results, a sum a chat model must get right, a sentence that must appear in a fetched page. The task's expected answer is never published; the request and the response are.
Questions written at call time. For endpoints that report a public fact, the question is generated at the moment of the call from recent chain activity, and the true value is read from two independent nodes at the same block (or the median of three exchanges within 0.3%). A seller cannot prepare for a question that did not exist before the call.
Agreement with a public source. Index and feed values are compared with the source they claim to report, fetched at call time, within a stated tolerance.
Unknown stays unknown. If there is nothing to check an answer against, it is counted as unchecked, never as right. That is the 739.

What this does not say

The sample leans toward sellers that work. Tasks are written for endpoints that answered at least once, so endpoints that never worked are under-represented in the checked set.
Probes are recognisable. Payments come from a pool of wallets funded from one address; a seller who looks can tell. A seller that behaves only when watched would look better here than it is, not worse.
We get things wrong too. This month we found 35 answers we had scored wrong that were right: one seller streams its reply unless asked not to, and our tasks for it did not ask. They are withdrawn by a published correction that names each record, not deleted. 168 calls are withdrawn this way in all, and none of them is in the figures above.

Why this matters now

Agents are being given wallets. Amazon Bedrock AgentCore Payments (built with Coinbase and Stripe) lets an agent pay x402 endpoints during a run and offers it more than 10,000 of them to discover. Cloudflare has announced capped wallets for agents. Both put a limit on how much an agent can spend. Neither looks at what it got back.

A spending limit bounds the loss. It does not stop an agent from paying, again and again, for an answer that is wrong.

You do not have to take our word for any of it

Every figure in this post is a count over one public file:

curl -s https://api.teppi.xyz/v1/market/records > records.ndjson
jq -s '[.[] | select(.source == "probe" and (.first_party | not) and (.corrected | not))
  | select(.liveness == 1 and .correctness != null and .correctness < 1)] | length' records.ndjson

Each line is one paid call: the url, the chain, the settlement transaction, every check's score, and a link to its evidence. Pick any line, look its transaction up on Basescan, open the evidence, and rerun the check. The live page is teppi.xyz/report.

Before an agent pays, it can ask what paying an endpoint delivered: GET https://api.teppi.xyz/v1/check?url=<endpoint> (signed, free), or put the same check inside the official x402 client with teppiHook from teppi-client. More at teppi.xyz/check-before-paying.

DEV Community: teppi-xyz