Correction: "76% dead" was our bug — and what "live" actually means · PulseFeed

Correction: “76% dead” was our bug, not the market’s

Published 2026-07-30 · the permanent home of this correction · live data · methodology

On 2026-07-18 we published an audit of the x402 agent-payment economy headlined “76% is dead.”<br>That figure measured our own parser, not the ecosystem. Our prober read payment requirements only<br>from the HTTP response body; x402 v2 moved them into the PAYMENT-REQUIRED header.<br>Live services were recorded as dead. 3487 endpoints are live today and the dead share is<br>38% . Everything below is reproducible from public endpoints.

1,869 endpoints wrongly marked dead

166 operators affected

3,920 false history records removed

38% dead share, corrected

The mechanism

In x402 v1 the challenge lives in the JSON body. In v2 it moved into a base64-encoded<br>PAYMENT-REQUIRED response header, and the body became a server implementation detail —<br>many v2 services return no accepts in the body at all. A body-only parser sees HTTP 402,<br>finds no requirements, and concludes the endpoint is broken.

curl -sD - -o /dev/null https://api.onesource.io/api/chain/block-number \<br>| grep -i '^payment-required' | sed 's/^[^:]*: //' | base64 -d

That returns a complete, valid challenge. We had published this endpoint with a trust score of 8/100,<br>0% uptime and the advice “do not pay: dead or invalid.” Among the 1,869 affected endpoints was<br>pro-api.coingecko.com.

The same bug distorted our comparison against the 402index catalog. We had been publishing that only<br>~30% of what it lists as “healthy” really is. Corrected, the figure is 69% .<br>The catalog was substantially more honest than we said.

What we changed

Parser. Both sources are read; the header wins when they differ, because that is what a v2 client pays against.<br>A disagreement between them is now recorded as a signal in its own right.

History. Uptime was computed from past verdicts, and for these services every past verdict was our bug.<br>We removed 3,920 malformed records from 1,869 endpoints that now return a valid header challenge, kept all<br>unreachable and no-402 records (the bug could not produce those), and stamped each repaired<br>record with historyRepairedAt, historyRepairedEntries and a note — visible in the free<br>/verify response, so anyone reading a track record can see that it was edited and why.

Confidence. Uptime is null below three observations, with an explicit<br>insufficient flag. A track record you cannot state is better than one you invent.

Time series. Each daily snapshot carries a probeVersion, and deltas across a version<br>boundary are suppressed with a stated reason — otherwise our own fix reads as the market doubling overnight.

Prior publications. Archived daily reports produced by the old prober carry a banner telling readers not<br>to cite their liveness numbers, and /llms.txt carries a machine-readable correction next to the link to<br>the original article. The article itself is on a third-party platform under a personal account; until its author<br>adds a notice, treat this page as the correction of record for it.

Four more mistakes of the same kind

While building detectors for endpoints that return a valid 402 but are not payable products, we made<br>three further errors within hours — each one our code encoding an assumption about the protocol instead of<br>the protocol — plus one about language.

1. We called a standard scheme unpayable

We treated exact as the only settleable scheme. The specification has four:<br>exact, upto, auth-capture, batch-settlement. The service we<br>flagged uses upto — normal, in-spec, and by on-chain volume one of the largest receivers in the<br>ecosystem. Three separate claims in that alert were false. The real distinction is outside the spec<br>(settlement bypasses the facilitator, funds are not in escrow) versus in-spec but not exact<br>(a default client cannot pay it without work — a compatibility note, not an accusation).

2. We read an authorization ceiling as a price

The same service advertises amount: 1000000000. In upto that is the maximum the<br>service may draw, not the cost of a call. We compared a ceiling against other services’ per-call prices and<br>called the difference an absurd price. Ceilings now live in a separate field and never enter price comparisons.

3. We described a mechanism we never tested

We wrote that placeholder URLs return 402 “before the route is resolved” and that a payer “gets a 404.”<br>Both were guesses. A genuinely nonexistent path on those hosts returns 308 or 502, not 402 — the route did<br>match, and the placeholder was accepted as a parameter value. What a payer receives we do not know, because<br>we did not pay. The claim is now limited to what is observable.

4. We attached intent to companies we had just been wrong about

Our feed labeled named businesses with “bait-and-switch pricing,” “price gouging,” “honeypot receiver,”<br>“possible hijack.” Intent cannot be demonstrated from an HTTP response, and we...