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.
Top comments (0)