We probed 20,338 x402 endpoints. 161 are agent honeypots.
x402 lets HTTP servers charge per request via cryptographic micropayments. It's the rail under agentic.market, a directory of paid endpoints AI agents can call autonomously. The catalog has grown to 20,338 endpoints across 516 services in a few months.
I ran a probe over every one of them. The results are bad news for any agent that picks endpoints by price filter or randomly samples the catalog.
TL;DR
161 endpoints are listed at ≥ $1,000 USDC per call. Aggregate "sticker price" across them: $4,521,000. Most of them are anti-scraper traps. An agent that reads the manifest and pays one of them drains its wallet.
~10 services are 100% erroring in the last hour but still listed and discoverable. Facilitator-based monitors don't see them because nobody completes a payment to them.
One provider — lowpaymentfee.com — owns 10,657 of the 20,338 endpoints (52% of the entire catalog). Pick a "random" x402 endpoint and you're overwhelmingly picking the same provider.
The open community facilitator at x402.org/facilitator only supports testnets. Coinbase CDP (the mainnet facilitator) rejects any payment under $0.001. So whatever oracle or pre-flight you build for mainnet, the floor is $0.001. Useful to know before wiring billing.
I wrote a $0.001-per-call oracle to expose this data structurally — preflight(url), forensics(url), catalog_decoys(). It got its first real on-chain mainnet settlement two hours ago. More on that at the end.
Why agents need a pre-flight check
The default x402 flow is naive on purpose:
Agent calls POST endpoint.example/api.
Server returns HTTP 402 with a base64 payment-required header listing price, asset, network, recipient.
Agent signs an EIP-712 authorization (ERC-3009 transferWithAuthorization) with its wallet, retries with X-PAYMENT.
Facilitator verifies + settles on chain. Server runs the handler.
Nothing in that protocol stops a server from advertising price: $5,000 USDC and waiting for an agent to sign. If the agent's wallet has $5k of USDC and the agent isn't paranoid about price ceilings, the money is gone the instant wrapFetchWithPayment retries.
The agent frameworks I tested (Claude Code's MCP integration, Cursor's, Daydreams') don't currently set a default per-request budget cap. Most agents that opt into x402 are doing it for $0.01 calls — none of the SDK examples mention price-trap protection.
What I probed
Every active endpoint on the catalog, every 10 minutes, with a naked HTTP request. No payment — just observe what comes back. The probe records:
HTTP status (200, 402, 404, 5xx, ...)
Response latency
Body size (cap'd at 1 MB; we don't actually keep the body)
Network errors (DNS failure, refused, timeout, ...)
Stack: Postgres 17 + TimescaleDB 2.26 hypertable for the probes, Bun for the worker, single Hetzner CAX11 ARM box ($5/mo). The whole probe pass takes ~7 minutes; ingest of the catalog runs every 5 minutes on a separate timer.
Important: this is what facilitator-based monitors can't see. Tools like x402gle, 402index.io, x402list.fun see only successful payments — i.e. the endpoints agents already pay. They miss everything that's broken, never paid, or designed to attract one-off "test" payments.
Findings
- The decoy zone — 161 endpoints ≥ $1k USDC The pricing distribution across the catalog has a long sad tail:
price band (USDC) endpoints
= 0 134
0 < p ≤ 0.001 1,672
0.001 < p ≤ 0.01 2,743
0.01 < p ≤ 0.1 11,504
0.1 < p ≤ 1 403
1 < p ≤ 10 81
10 < p ≤ 100 13
100 < p ≤ 1000 3
1000 146
That last bucket aggregates to roughly $4.5M in sticker price. 146 of those are clustered around a single provider that uses ≥ $1000 USDC listings as anti-scraper soft locks for "swarm" routes. Hit one with wrapFetchWithPaymentFromConfig and you've signed away your wallet.
Why it works as a trap: the catalog API exposes price but not expected value. The endpoint's description sounds plausible ("Coordinated multi-agent search"). An agent ranking by capability + price will skip these because they're expensive, but an agent doing breadth-first sampling, or filtering "all endpoints in category X" without an upper-bound check, will hit them. Some I probed return HTTP 402 consistently — they're functional payment requesters, just at trap-level prices.
- Zombie services — listed but 100% broken About ten services in the catalog return errors on every probe over the last hour. The catalog still exposes them with current prices, marked is_active: true, with a quality score that hasn't been updated since the last successful interaction. Agents browsing categories will pick them, sign payments, and the request will fail post-settlement (or pre-settlement, depending on whether the server even speaks 402 anymore).
The reason these survive: the catalog is updated from provider self-reports plus aggregated payment outcomes. A zombie that nobody pays simply doesn't generate the negative signal needed to be deactivated.
- One provider owns half the catalog This one surprised me. Top-5 providers by endpoint count:
provider endpoints % of catalog
lowpaymentfee.com 10,657 52%
(long tail) ≤ 200 each …
Strip the multiplicity-providers and the "real" diversity is closer to ~500 distinct services. When agent prompts say "pick any random x402 inference endpoint", they're overwhelmingly picking inside one provider's billing namespace.
The lowpaymentfee.com endpoints are not necessarily fraudulent — they look like programmatically-generated sub-routes for an inference platform — but agents and frameworks talking about "x402 ecosystem health" should know that one provider going down or changing pricing affects half the catalog atomically.
- Uptime baseline Out of the most recent full probe pass (20,338 active endpoints):
outcome share
HTTP 402 (healthy x402 handshake) 87.3%
HTTP 404 4.2%
HTTP 308 / 307 redirects ~2%
HTTP 403 / 401 (auth wall) ~1.3%
HTTP 429 (rate-limited us) ~0.3%
Timeout ~0.9%
Network error (DNS, reset, refused) ~0.8%
Latency on responses under 5xx:
p50: 316 ms
p90: 686 ms
p99: 2131 ms
max: ~7.8 s
A 402 from a free endpoint (price = 0) is still healthy — it just means the service insists on a 402 handshake before responding. We classify it as up.
- The mainnet facilitator floor The community facilitator at https://x402.org/facilitator is open and supports a long list of testnets (Base Sepolia, Solana devnet, Stellar testnet, ...) without any auth. It does not support Base mainnet. If you want to settle on eip155:8453 (the only EVM mainnet x402 has meaningful adoption on right now), you need Coinbase CDP credentials.
The CDP facilitator rejects any payment under 1000 atomic units = $0.001 USDC with invalid_payload. There's no invalid_amount_too_low enum value in the response — it's a generic invalid_payload. I burned three CDP API keys debugging this before finding it; documenting in case anyone else hits the same wall.
So: on Base mainnet, today, the smallest payment you can ship is $0.001. Any pricing ladder for a paid agent service should start there.
The oracle
I wrapped the probe data behind three x402-paid endpoints, paid via x402 itself:
endpoint price (USDC) what it does
POST /api/v1/preflight 0.001 { ok, warnings, metadata } for one URL — detects decoy/zombie/dead/slow/new-provider in a single round-trip
POST /api/v1/forensics 0.001 7-day uptime hourly buckets, latency p50/p90/p99, status-code distribution, concentration-group stats, decoy probability — superset of preflight
POST /api/v1/catalog/decoys 0.005 the full known-bad list (every endpoint flagged decoy/zombie/dead_7d/mostly_dead) in one JSON, for caching as a local blacklist
Manifest at https://x402station.io/.well-known/x402. Agent card at /.well-known/agent-card.json. OpenAPI 3.1 at /api/openapi.json.
For Claude Code / Cursor / Windsurf / Continue, drop this in your MCP config:
{
"mcpServers": {
"x402station": {
"command": "npx",
"args": ["-y", "x402station-mcp"],
"env": {
"AGENT_PRIVATE_KEY": "0xYOUR_PRIVATE_KEY"
}
}
}
}
Three tools — preflight, forensics, catalog_decoys — are now in your agent's context, billed per call.
First on-chain settlement
Two hours ago the oracle received its first real Base mainnet payment: 1000 micro-USDC = $0.001. The settlement is on chain at the prober address 0x4053338C7cB38624C0bc23c900F78Cf8470b4E38.
The test agent asked the oracle about a Venice / Gemini route on agentic.market. The oracle replied:
{
"ok": false,
"warnings": ["zombie"],
"metadata": {
"service": "Google Gemini",
"uptime_1h_pct": 0,
"avg_latency_ms": 195,
"is_active": true
}
}
The endpoint is listed in agentic.market as active. It is in fact returning errors on every probe over the last hour. An agent that paid that endpoint without preflighting would have its payment go through and the response come back as a 5xx — money for nothing. The preflight call cost less than the payment that would have been wasted.
What's next
More signal types: price-drift detection over the catalog snapshot history (we keep a TimescaleDB hypertable of service_quality_history updates, the data is there).
Webhook (/api/v1/watch) and consensus (/api/v1/consensus) endpoints — both planned, gated on real demand from the first three.
Direct middleware PRs to Daydreams Lucid, Coinbase AgentKit, CrewAI, LangChain, Mastra so preflight() becomes a default before-pay hook.
Source code, manifests, the probe worker, the schema, the deploy: github.com/sF1nX/x402station. The probe data is the moat; the code is open.
If you're building an agent that touches x402 endpoints — please call preflight before signing anything you didn't generate the URL for yourself. The decoys are out there.
Try it (zero setup):
curl -X POST https://x402station.io/api/v1/preflight \
-H 'content-type: application/json' \
-d '{"url":"https://api.venice.ai/api/v1/chat/completions"}'
Top comments (0)