DEV Community: Нико Лайф

76% dead was my bug, not the market's — and then I made four more mistakes exactly like it

Нико Лайф — Thu, 30 Jul 2026 17:25:17 +0000

Two weeks ago I published an audit of the x402 agent-payment economy with the headline finding that 76% of listed endpoints were dead or invalid.

That number was wrong. It was measuring my own parser.

The real figure is 38%. Not because the ecosystem recovered — because my prober had been reading the wrong half of the HTTP response. This post is the correction, the mechanism, and the four additional mistakes I made in the same family while fixing the first one. That last part is the useful bit.

Everything here is reproducible with curl. Commands are inline.

The mistake

x402 puts payment requirements in a 402 Payment Required response. In v1 they live in the JSON body:

{ "x402Version": 1, "accepts": [{ "scheme": "exact", "maxAmountRequired": "10000", ... }] }

In v2 they moved into a PAYMENT-REQUIRED response header (base64-encoded JSON), and the body became a server implementation detail. Many v2 services return a body with no accepts at all — sometimes just {}.

My prober only parsed the body. So a live v2 service looked like this: HTTP 402 received, no accepts found, verdict malformed, public advice "do not pay: dead or invalid."

Here is one of them:

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

A complete, valid challenge: scheme: exact, network eip155:8453, amount: 1000 (0.001 USDC), a real payTo. The service works. It always worked. My oracle told agents it was dead, with a trust score of 8 out of 100 and 0% uptime.

1,869 endpoints across 166 operators were in that state. Among them, pro-api.coingecko.com.

I also owed a catalog an apology. I had been publishing that 402index overstates health — that only ~30% of what it lists as "healthy" really is. After the fix, the same comparison gives ~68% (live figure in catalogAudit.accuracyPct at /status.json — it moves with each crawl). The catalog was substantially more honest than I said it was. Mine was the unreliable measurement.

The fix, and what it cost

Fixing the parser was ten lines: read the body, read the header, prefer the header (that is what a v2 client pays against), record which one carried the challenge.

The expensive part was history. My uptime metric is the share of past observations with a healthy verdict, and for these services every past observation said malformed. That is not their downtime — it is my bug, recorded as their track record. I removed 3,920 malformed history entries from 1,869 endpoints that now return a valid header challenge, kept every unreachable and no-402 entry (my bug could not produce those), and stamped each repaired record with historyRepairedAt, historyRepairedEntries and a note. Those markers are in the free /verify response, so anyone reading a track record can see it was edited and why.

Which created a new problem: services with one observation and a "100% uptime" badge. So uptime is now null below three observations with an explicit insufficient confidence flag, and the trust score no longer grants full uptime credit on a thin history. A track record you cannot state is better than one you invent.

The daily time series had the same hazard. Live endpoints went 1,452 → 3,487 in one snapshot. Any reader — including future me — would see a market doubling overnight. Each snapshot now carries probeVersion, and day-over-day deltas across a version boundary are suppressed with a stated reason instead of rendered as green arrows.

Current numbers, checkable right now:

curl -s https://pulsefeed.dev/status.json | jq '.ecosystem'

Then I made four more mistakes of exactly the same kind

This is the part I would want to read.

Having just been burned by a parser that knew less than the spec, I added detectors for endpoints that return a valid 402 but still are not payable products. Within hours, three of them were wrong, in the same way, for the same reason: my code encoded my assumption about the protocol instead of the protocol.

1. I called a standard scheme unpayable

I decided the only settleable scheme was exact, flagged everything else as "no standard client can settle this — funds leave escrow, irreversibly," and published it at high severity.

The x402 spec has four schemes:

curl -s https://api.github.com/repos/x402-foundation/x402/contents/specs/schemes \
  | jq -r '.[] | select(.type=="dir") | .name'
# auth-capture, batch-settlement, exact, upto

The service I flagged, api.bitrefill.com/x402/invoice/pay, uses upto — a normal scheme, in the spec, and by on-chain volume one of the largest receivers in the ecosystem. Three separate claims in my alert were false. I had reproduced my own bug against a different protocol field.

The real distinction is not payable versus unpayable:

outside the spec → settlement does not go through a facilitator, funds are not in escrow — worth flagging;
in the spec but not exact → a default x402-fetch client cannot pay it without work. That is a compatibility note, not an accusation.

One endpoint in my index is genuinely outside the spec: api.dynsuplabs.com advertises exact-prepay-proof, and its own extra.doc field instructs the client to broadcast the USDC transfer itself, outside any facilitator, stating that payment is final and non-refundable. That one deserved a flag. The other did not.

2. I read an authorization ceiling as a price

Same service, second false alarm. Its challenge carries amount: 1000000000 — 1,000 USDC. My price detector saw a thousand-dollar API call and flagged "absurd price."

In upto, amount is the maximum the service is authorized to draw, not the price of a call. It is a gift-card purchase flow; the actual charge is usage-based. Comparing a ceiling against other services' per-call prices means comparing two different quantities and calling the difference fraud.

Ceilings now live in a separate field with an explicit note — never in the price field, never in price comparisons.

3. I described a mechanism I never tested

Hundreds of listed URLs are documentation placeholders — /api/chain/tx/:hash, /v1/{id}, /example — that still return a valid 402. I wrote that the 402 is served "by middleware before the route is resolved," and that a paying agent "gets a 404."

Both were guesses. Requesting a genuinely nonexistent path on the same hosts:

curl -s -o /dev/null -w '%{http_code}\n' https://skills.onesource.io/api/chain/zzz-not-real-route    # 308
curl -s -o /dev/null -w '%{http_code}\n' https://api.gocreativeai.com/definitely-not-a-real-zzz999   # 502

Not 402. So the route did match — the placeholder was accepted as a parameter value. And what a payer receives I do not know, because I never paid. The claim is now limited to what is observable: the URL is a string from documentation, the challenge is valid, and catalogs count it as a live service.

4. I attached intent to companies I had just proven myself wrong about

My public feed labeled named, identifiable businesses with "bait-and-switch pricing," "price gouging," "honeypot receiver," "possible hijack." In the US the first two carry statutory and FTC meaning; all four assert intent. I cannot demonstrate intent from an HTTP response — and I had just been wrong about the mechanism three times in one day.

Labels now describe the observation. "Advertised price differs from the amount actually requested." "Receiver address changed between observations," with the note that routine key rotation and a compromise are indistinguishable from outside. A high price now carries "may be entirely legitimate for what it returns — we measure the number, not its fairness."

What "live" actually means

Every one of these mistakes came from treating "returned a 402" as if it meant "is a payable product." It does not. Here is the checklist I run now, written so you can apply it to your own index. Copy it.

#	Check	Why it exists
1	Parse the challenge from both the body and the `PAYMENT-REQUIRED` header, preferring the header	v2 moved it; body-only readers see live services as broken
2	Compare the two when both are present	If they disagree, a v2 client pays what the header says — which is not what a body-only check displays
3	Check the scheme against `specs/schemes/`	Outside the spec means settlement bypasses the facilitator; in-spec-but-not-`exact` is a client compatibility matter
4	Know whether `amount` is a price or a ceiling	`upto` and `auth-capture` state a maximum, not a per-call cost
5	Check that the network is mainnet	A testnet sandbox priced in dollars is not a product
6	Check the URL for unfilled path placeholders	`:id`, `{id}`, `/example` are documentation strings
7	Know the token's decimals per chain	USDC is 6 decimals on most chains and 18 on BSC; assuming 6 everywhere is a 10¹² error
8	Count distinct operators, not endpoints	One host can list hundreds of routes
9	State the observation count next to any uptime figure	A percentage over one observation is not a track record
10	Version your measurement method and mark the break	Otherwise your own fixes read as market movement

What my own numbers look like under that checklist

The same discipline, applied to me. My index currently reports 3,487 live endpoints. Inside that:

682 are documentation placeholders — and honesty requires the next sentence: 582 of them are a single host, api.gocreativeai.com. Without it, 100 placeholders across 22 domains. Reporting "682 across 23 domains" and stopping there would be exactly the inflation I criticize.
29 are on test networks.
1 advertises a scheme outside the spec.
1 has a body/header disagreement.

Honest remainder: 2,775 endpoints across 338 operators.

And those 3,487 endpoints resolve to only 350 distinct hosts, with the top three accounting for 1,575 of them. This is a far narrower ecosystem than any endpoint count suggests.

Other limits, stated plainly: my observations begin 2026-07-06, which is shallow. Other trackers have deeper history and broader coverage — x402.fuchss.app publishes on-chain data complete since 2025-05-09 across roughly 97k listed endpoints, and it separates reachability from envelope compliance, which is precisely the distinction I got wrong. Where our numbers differ, the longer series is more likely to be right about trends. I am confident only about what I can re-probe today.

Verify everything here yourself

# ecosystem totals, composition, catalog comparison
curl -s https://pulsefeed.dev/status.json | jq '.ecosystem, .catalogAudit'

# one endpoint, free
curl -s 'https://pulsefeed.dev/verify?endpoint=https://api.onesource.io/api/chain/block-number' | jq

# every anomaly currently observed, with on-chain references
curl -s https://pulsefeed.dev/incidents.json | jq '.byCategory'

# the v2 header, straight from the source
curl -sD - -o /dev/null https://api.onesource.io/api/chain/block-number \
  | grep -i '^payment-required' | sed 's/^[^:]*: //' | base64 -d | jq

The dataset is CC-BY-4.0 on Hugging Face. The original article now carries a correction notice at the top, archived daily reports produced by the old prober carry a banner telling readers not to cite their liveness numbers, and /llms.txt carries a machine-readable correction beside the link.

If you run a catalog, a wallet, or an agent that decides whether to pay an endpoint: run check #1 today. It is ten lines, and in your own dashboard it is the difference between a live ecosystem and a mostly-dead one.

If you find an error in this post, tell me. That is now demonstrably the fastest way to improve this dataset.

I audited the entire x402 agent-payment economy. 76% is dead — and the live half has scams.

Нико Лайф — Sat, 18 Jul 2026 04:38:11 +0000

CORRECTION — 2026-07-30. The headline figure in this article is wrong. The "76% dead" number measured my own prober, not the ecosystem: it read x402 payment requirements only from the HTTP response body, while x402 v2 moved them into the PAYMENT-REQUIRED header. 1,869 endpoints across 166 operators were live and recorded as dead. The corrected figure is 38%. Full write-up of the mechanism, the four further mistakes I made while fixing it, and a checklist for deciding whether an endpoint is genuinely payable: https://pulsefeed.dev/correction

The scam and anomaly findings below are unaffected; the liveness numbers are not reliable.

x402 is the protocol everyone in the AI-agent space is excited about: HTTP 402 Payment Required + stablecoins, so an AI agent can pay for an API call autonomously, no accounts, no API keys — the wallet is the identity. Coinbase, Cloudflare, Stripe, AWS and Google have all shipped support. The narrative is enormous.

So I did the boring thing: I pointed a crawler at every x402 endpoint I could find and actually probed them. Then I kept probing them, every day, and recorded what changed.

The results are not what the narrative suggests.

Finding #1: most of it is dead
Of 5,077 tracked x402 endpoints, ~76% are dead or invalid — they don't return a valid x402 payment challenge when you actually call them. Of what's left, only about half of the endpoints that public catalogs label "healthy" actually work under a strict probe.

Strip the duplicates (a handful of providers list hundreds of endpoints each) and you're left with roughly 135 genuinely live services. The agentic-payment economy is real, but it's small, and a lot of what's listed is noise.

Finding #2: the live half has a scam problem
Dead endpoints waste an agent's time. The live ones can waste its money — and x402 payments are irreversible. There's no chargeback for an autonomous agent.

Probing continuously surfaces a recurring set of failure modes. Right now there are 35 active incidents, 18 of them high-severity, across a few categories:

Bait-and-switch pricing — the endpoint advertises one price in its x402 challenge, then requires a different amount at payment. Example caught live: headlessoracle.com (receiver 0x26D4…0AD3), plus agents.dyoeway.org and lionx402.com doing the same thing. An agent that trusts the advertised price pays the higher one.

Receiver hijack — the payTo address silently changes on an endpoint that previously had a stable, established receiver. Maybe it's the operator rotating keys; maybe it's a compromise. Either way, an agent that paid it yesterday should re-verify before paying it today.

Honeypot receivers — a zero or malformed payTo. Money sent here is simply gone.

Unverified receivers — a payTo with no on-chain USDC history at all. Not proof of fraud, but a real risk signal: nobody has ever actually paid this address, yet it's asking your agent to be the first.

Price gouging — anomalously high prices relative to the rest of the ecosystem. Example: x721.dev at $40.20 per call while comparable services charge fractions of a cent.

Every one of these is linked to on-chain proof you can verify yourself — the receiver address on Base, open in a block explorer. I'm not asking you to trust my verdict; the evidence is public.

An honesty note (this matters)
I state findings as facts from the data, not as accusations of intent:

"bait-and-switch" = advertised price ≠ amount actually charged (observable).
"unverified receiver" = payTo has no on-chain USDC history (a risk signal, not a conviction).
"possible hijack" = the receiver changed on an established baseline — could be a legitimate key rotation.
By-design receiver rotation (some services rotate a per-session address on purpose) is excluded so it doesn't pollute the signal. If you're going to publish security findings about named services, you have to be precise, or you're just spreading FUD.

Why nobody had this data
Here's the part that's structurally interesting. You cannot reconstruct this after the fact. "This endpoint's payTo changed three times last month," "this receiver has been stable for 60 days," "this price crept up 4×" — none of it exists unless someone was watching continuously and writing it down as it happened. A snapshot taken today can't tell you what an endpoint was.

That's the whole game with trust: it's accumulated history, and history can't be back-filled. A catalog can list what's live right now. It can't tell you what's trustworthy over time.

It's not just x402 — MCP has the same shape
The same independent-audit lens applied to the MCP (Model Context Protocol) server ecosystem finds a parallel problem: of 938 audited MCP servers, ~11% run an arbitrary install script on npm i (code execution the moment you connect them), dozens are abandoned, and 85 ship no repository to review at all. Install scripts aren't always malicious — native builds use them — but each is an unreviewed code-execution vector, and most people connect a server without ever checking.

Different protocol, same failure: the tooling shipped faster than the trust layer.

What to actually do about it
If you're building agents that pay for things or connect to tools:

Verify before you pay. Don't let an agent pay an x402 endpoint it hasn't checked for liveness, price consistency, and receiver sanity. A free check: GET https://pulsefeed.dev/trust?endpoint= → verdict + on-chain receiver profile + scam flags.
Verify before you connect. Same for MCP servers: GET https://pulsefeed.dev/mcp/verify?package= before you install.
Watch what changes. A safe endpoint can be hijacked or repriced overnight. The live incident feed is free to read: pulsefeed.dev/incidents (also as RSS if you want a machine to watch it).
The audit, the incident feed, the ecosystem reports and the methodology are all free and public — I built PulseFeed because I needed this data to exist and it didn't. There's a paid cross-domain data feed for people building trust/monitoring tools, but you don't need to pay anything to check an endpoint or read the incidents.

The agent economy is coming. The trust layer under it is mostly not built yet. That's the interesting problem — and right now, most of what's live is worth being suspicious of.

Data as of the latest daily crawl. Methodology: pulsefeed.dev/methodology. Live disclosures with on-chain proof: pulsefeed.dev/incidents.