Forem: AFX

A $1 verified-badge for x402 services — fully autonomous, machine-paid

AFX — Sat, 02 May 2026 20:07:58 +0000

A $1 verified-badge for x402 services — fully autonomous, machine-paid
TL;DR: We just shipped POST /api/v1/verified on x402station — a $1 USDC audit endpoint for x402 service operators. Pay once, get a 30-day signed certificate + HTML/SVG badge to embed in your docs. The badge re-runs the audit on every public-page render so it stays honest. Eligible services pulled from our independent probe data are listed live at x402station.io/verified. Pure machine-to-machine: your CI bot signs the X-PAYMENT, no human signups, no email captured. 59 endpoints in the catalog already pass the criteria right now.

Why this exists
Half a year into the x402 agentic-commerce protocol, two things are true:

The catalog is noisy. Of ~35,000 active endpoints we probe every 10 minutes, ~17% are landmines (decoy honeypots, zombie services, dead endpoints). Our earlier post covered the long tail in detail.
Honest operators have no way to differentiate. A well-built x402 service has the same surface as a Questflow $1000-USDC honeypot, from an agent's perspective. Both return 402 with payment requirements, both have a .well-known/x402 manifest, both look the same in the Coinbase Bazaar.
We've been the oracle solving the agent side: "is this URL safe to pay?" → /api/v1/preflight ($0.001 USDC). Today we shipped the operator side: "prove my URL is safe to pay" → /api/v1/verified ($1 USDC).

What you get for $1
POST https://x402station.io/api/v1/verified
{ "url": "https://your-endpoint.example.com/route", "name": "Your Service" }
Response includes:

certId — UUID v4
verified — boolean (yes/no diagnostic with full pass/fail reasons)
tier — verified or verified_plus (more on tiers below)
badgeUrl — SVG you can embed in your README
pageUrl — public verification page
htmlSnippet — drop-in HTML
validUntil — 30 days from issuance
Embed:

/badge.svg"
alt="Verified by x402station" height="20"/>

The SVG re-fetches every 5 minutes (cache-control). The public page re-runs the audit on every render. If your service degrades after issuance, the badge auto-flips to "failing" within minutes. Honesty enforced by infrastructure, not pinky-promise.

Audit criteria
Five predicates, applied at issuance AND on every public-page recheck:

Criterion Threshold Why
probes_7d ≥ 20 Need real signal, not 1-2 probes
uptime_7d_pct ≥ 95% Below this, agents would routinely fail calls
Critical signals none firing dead, zombie, decoy_price_extreme, dead_7d, mostly_dead, never_paid_zombie
latency_p99_ms ≤ 5000 Long-tail timeouts ruin agent UX
price_usdc ∈ [$0.0001, $5] Sane band — out of range = price trap or freebie
The same predicates drive the live /verified/ recheck — the badge can't claim more than the data supports today.

"Verified" vs "Verified+"
verified — passes all five baseline criteria
verified_plus — passes baseline AND CDP confirms ≥1 paid call in the last 30 days (cdp_l30d_calls > 0)
The + tier surfaces real-payer demand. We pull this from the Coinbase CDP raw discovery API — payment-volume data no probe-based source can derive (facilitator-based competitors only see their own settlements). More on that ingestion here. (forthcoming follow-up post)

Eligible services right now
Live snapshot at x402station.io/verified:

59 endpoints currently pass all five criteria
All 59 are verified_plus tier (CDP-confirmed real demand)
Top of list: Exa /search (api.exa.ai), Otto AI /supported-tokens (x402.ottoai.services), and others
If you operate one of these and want the badge, the page shows the exact @x402/fetch snippet your CI bot needs to mint a cert. One command, $1 USDC, 30-day cert.

Why this is pure machine-to-machine (and not a Stripe pivot)
x402station's core principle: no humans as customers. Every endpoint we ship is consumable by an agent without human intervention — no email signups, no OAuth, no dashboard logins.

The verified-badge endpoint preserves this:

Your CI bot signs the X-PAYMENT header with your wallet's private key
We verify the payment via Coinbase CDP's facilitator
We INSERT the cert row, return the response with embed-ready URLs
Your CI bot can store the badge URL in a CI-managed env file or commit it into your README
The only "human" thing is that a human DECIDES to set up the CI step the first time. After that, the renewal is whatever cron schedule the CI bot wants — every 25 days, weekly, daily. Pre-paid USDC sits in the bot's wallet.

Distribution
Endpoint manifest: x402station.io/.well-known/x402 (machine-readable)
OpenAPI: x402station.io/api/openapi.json (12 operations now, including verifiedBadge + getVerifiedCertificate)
A2A agent card: x402station.io/.well-known/agent-card.json (8 skills now, verified listed)
Coinbase Bazaar: auto-indexed via the bazaar extension — search "verified" in their discovery API to find us
MCP tool surface: forthcoming in x402station-mcp v1.1.0 (coming next week)
What's next
A single $1 cert from a single provider validates the channel. Two open questions:

Will providers actually mint? The eligibility list shows 59 candidates. We'll watch settlement count over the next 7 days.
Does the badge drive agent traffic to verified endpoints? We probe everything anyway — easy to A/B over time.
If you operate an x402 service and would benefit from a trust signal embeddable in your docs, the eligibility page is at x402station.io/verified. If your endpoint isn't there, fix the failing criterion first — then run the curl.

Questions / methodology pushback / weird edge cases — GitHub Issues or hello@x402station.io.

We graded every x402 endpoint with Cloudflare's agent-readiness scanner

AFX — Wed, 29 Apr 2026 12:59:34 +0000

TL;DR: Cloudflare quietly shipped isitagentready.com — a public scanner that grades any URL for AI-agent readiness on a 0–5 scale across 19 checks (robots.txt, MCP server cards, A2A agent cards, x402, OAuth resource metadata, etc.). We ran it against every active host on the x402 catalog: 549 unique hosts covering 25,950 endpoints, 4-hour polite sweep, zero failures. 53.3% of endpoints are at level 0 — no agent-readiness signals beyond what a 1995 web server gives you. Only 6 hosts (1.5%) have x402 itself detected by the scanner. But the most interesting finding was the long tail: five small experimental hosts hit level 5 — the highest grade — beating Cloudflare's own site (which is at level 4). Most of the catalog is bare metal; the people building real agent-native services are not the providers carrying the volume.

Why this matters
x402 is the agent-payment standard. The whole point is agents — not humans — discovering and paying API endpoints autonomously. So whatever signals AI agents and their tooling actually use to decide "is this site ready for me to talk to" matters more than dashboard polish or documentation prose.

Cloudflare's isitagentready.com is the first public, independent, multi-vendor benchmark for that. It checks 19 things across five categories:

Category Checks
Discoverability robots.txt, sitemap, Link headers
Content Accessibility Markdown content negotiation
Bot Access Control AI-bot rules in robots.txt, Content Signals, Web Bot Auth
Protocol Discovery MCP Server Card, A2A Agent Card, Agent Skills, WebMCP, API Catalog, OAuth discovery, OAuth Protected Resource
Commerce x402, MPP, UCP, ACP, AP2
The 5-level grade collapses into:

Level 0 — Basic web presence missing
Level 1 — Has robots.txt + sitemap (basic web)
Level 2 — Bot-Aware (Content Signals declared)
Level 3 — Agent-Readable (Markdown content negotiation works)
Level 4 — Agent-Integrated (MCP / Link headers / A2A)
Level 5 — Agent-Native (full OAuth Protected Resource + Agent Skills + API Catalog)
Cloudflare's own site is at level 4. x402station.io started this scan at level 4 too — and finished at level 5 after we shipped the four remaining well-known files (more on the climb at the end). Five other hosts in the catalog were already at level 5 when we surveyed.

Methodology
We pulled every is_active = true endpoint from our database (25,950 rows across 573 services), deduped by hostname (the scanner looks at host-level artifacts: /robots.txt, /.well-known/*, MCP/A2A cards), and POSTed each unique host's first endpoint URL to https://isitagentready.com/api/scan.

Cloudflare rate-limits the scan API at concurrency ≥ 4 — a faster sweep against 549 hosts trips the 50-scan window and returns HTTP 429 for everyone after that. So we ran a polite sweep: --concurrency=1 --delay-ms=20000, ~3.85 hours wall-clock for 549 hosts, 0 failures, 0 retries needed. This dataset covers 100% of the active catalog, no extrapolation.

The scan script is part of the x402station backend (private repo); the data is fully reproducible against public sources. Pull the active endpoint list from the agentic.market catalog API, dedup by hostname, POST each unique host's first endpoint URL to https://isitagentready.com/api/scan, persist the response. Raw results.jsonl written incrementally so a SIGINT never loses what was already scanned. Drop us a note via the dev.to comments or GitHub Issues if you want a copy of our run's JSONL.

Results
Level distribution
Level Hosts Hosts % Endpoints reached Endpoints %
0 — Basic web missing 323 58.8% 13,830 53.3%
1 — Basic web 52 9.5% 11,245 43.3%
2 — Bot-Aware 8 1.5% 19 0.1%
3 — Agent-Readable 1 0.2% 5 0.0%
4 — Agent-Integrated 3 0.5% 5 0.0%
5 — Agent-Native 5 0.9% 7 0.0%
unknown (CF couldn't classify) 157 28.6% 839 3.2%
The bulk story is the same as the partial sweep: 96.6% of the catalog by endpoint reach (level 0 + level 1) emits no agent-readiness signals beyond robots.txt + a sitemap. The big providers are bare metal.

But the long-tail surprise is the 9 hosts that scored level 3 or higher — and especially the 5 hosts at level 5, the highest grade Cloudflare's scanner can issue. Those five exceed Cloudflare's own grade.

isCommerce: false for 70.7% of hosts
Cloudflare gates the commerce-category checks (x402, MPP, UCP, ACP, AP2) behind a heuristic called isCommerce. With full coverage we now see:

70.7% false (388 hosts) — scanner thinks they're not commerce
28.6% unknown (157 hosts) — scanner couldn't classify (mostly DNS/auth/edge errors)
0.7% true (4 hosts) — scanner confirms commerce
The four hosts Cloudflare's heuristic recognises as commerce: x402.valoria.net, brapi.dev, fleawinder.com, x402.clashofcoins.com (the last is also at level 5). Note that the heuristic is independent of the dedicated x402 check — most x402-detected hosts still fail isCommerce.

Per-check pass rates
What signals do x402 hosts actually emit? (Sorted by % of hosts passing each check. Denominator is 392 — the hosts where the scanner returned a check breakdown; the 157 unknown hosts have no checks to grade.)

Check % passing Notes
robotsTxt 34.2% (134/392) The most-passed check, but still only a third
robotsTxtAiRules 34.2% Wildcard User-agent: * rules count — very low bar
contentSignals 17.3% One line in robots.txt (Content-Signal: ai-train=no, …)
sitemap 17.1%

mcpServerCard 7.4% A static JSON file at /.well-known/mcp/server-card.json
markdownNegotiation 5.9% One Next.js middleware
linkHeaders 3.8% Two lines of nginx config
agentSkills 3.1%

apiCatalog 2.3% RFC 9727 draft, almost nobody implements yet
oauthDiscovery 2.0%

oauthProtectedResource 1.5%

webMcp 1.5%

x402 1.5% (6 of 392) The check this catalog most needs to pass
a2aAgentCard 1.0%

ucp 1.0%

acp 0.8%

webBotAuth 0.5%

mpp 0.0% Zero adoption in this catalog
ap2 0.0% Zero adoption
The full-coverage rate for x402 (1.5%) is dramatically lower than the partial-sweep estimate (5%) because the long-tail hosts — small projects, bridge endpoints, single-route services — almost never declare anything. Only 6 of 549 hosts in the entire active catalog have x402 detected by the scanner today.

Five small projects beating Cloudflare's own grade
The headline finding of the full sweep is the level-5 cluster. These are the five hosts Cloudflare's scanner ranks as fully agent-native — the highest grade — exceeding Cloudflare's own site:

Host Endpoints x402 detected isCommerce
trader.rigoblock.com 2 yes false
x402.clashofcoins.com 2 yes true
fastsend.dev 1 yes false
kenoodl.com 1 no false
picoads.xyz 1 no false
None of them carries large endpoint volume — these are 1-2-route services, hand-built. But every one passes the full Cloudflare check matrix: OAuth Protected Resource Metadata, Agent Skills, API Catalog, the works. x402.clashofcoins.com is the most complete signal: level 5 + x402 detected + isCommerce: true simultaneously — the prototype "what good looks like" host.

Three more hosts hit level 4 (Agent-Integrated): x402station.io (us, 3 endpoints), dlf-gateway.agentlabel.workers.dev, socialintel.dev. One host at level 3: x402.naiko.io.

Compare those nine hosts at level ≥ 3 against the nine biggest providers by endpoint reach:

Top provider Endpoints % of catalog Level
lowpaymentfee.com 10,659 41.1% 0
orbisapi.com 9,882 38.1% 1
freepik.x402.paysponge.com 466 1.8% 0
x402.aurelianflo.com 339 1.3% 0
bridge.eruditepay.com 284 1.1% 0
x402.quicknode.com 136 0.5% 0
Eighty percent of the catalog by endpoint reach lives at hosts that pass two or fewer of the 19 checks. The hands-on builders running 1-2 endpoints implement everything; the big providers running thousands implement almost nothing. Single-provider concentration is also single-readiness concentration, and the concentration is at the bottom.

The big finding: Bazaar registration is high-probability, not strictly required
Of the 6 hosts where Cloudflare detected x402, 5 are registered in Coinbase's Bazaar discovery API:

x402.quicknode.com — Bazaar-registered
trader.rigoblock.com — Bazaar-registered (also level 5)
x402.clashofcoins.com — Bazaar-registered (also level 5, also isCommerce: true)
fastsend.dev — Bazaar-registered (also level 5)
x402.quiknode-cf.pro — Bazaar-registered
The exception is bridge.eruditepay.com (284 endpoints, level 0) — Cloudflare's scanner says x402 payment protocol detected on /api/v1, but the host is not in Bazaar discovery. So Cloudflare also probes URLs directly to detect x402, not just lookup against Bazaar. That said, the ratio is striking: 5 of 6 detections come through the registered path, and registration takes one self-pay to bootstrap.

The high-probability path:

Add the bazaar extension to your 402 response payload (one helper call: declareDiscoveryExtension from @x402/extensions/bazaar)
Self-pay $0.001 once through CDP facilitator (or wait for organic traffic — anyone paying you with the extension echoed in payload triggers indexing)
Within ~30 seconds, your endpoint shows up in CDP's discovery API
Cloudflare's scanner then sees you when it queries https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources
Cost to fix: zero engineering effort if your facilitator is already CDP, plus $0.001 per route to bootstrap.

How x402station.io climbed from level 1 to level 5
The agent-discovery layer that lifted us:

Level 1 → 4 (took an afternoon earlier this month):

robots.txt with Content-Signal: ai-train=no, search=yes, ai-input=yes → unlocks level 2
/.well-known/mcp/server-card.json describing the npm-installable MCP adapter → unlocks mcpServerCard
/llms.txt served as text/markdown with Accept: text/markdown content negotiation on / → unlocks level 3 + markdownNegotiation
Link headers on / pointing at the manifest, OpenAPI spec, agent-card, MCP card → unlocks linkHeaders
bazaar extension on every paid route + one $0.001 self-pay each → unlocks x402 (until we crossed the isCommerce boundary, anyway — see note)
Level 4 → 5 (shipped right after the survey closed, in the same session as this article):

/.well-known/api-catalog (RFC 9727 linkset+json) — one document linking every machine-readable artefact (OpenAPI, agent-card, MCP card, manifest, llms.txt, blog) → unlocks apiCatalog
/.well-known/oauth-protected-resource (RFC 9728) — minimal stub with empty arrays. We don't speak OAuth (payment is x402), and an honest empty-array body declares that fact in machine-readable form. Same pattern every level-5 host in the catalog uses → unlocks oauthProtectedResource
/.well-known/oauth-authorization-server (RFC 8414) — same empty-array stub → unlocks oauthDiscovery
supportedInterfaces[] field added to A2A agent card so scanners can pivot to the new well-known files inline → strengthens a2aAgentCard
Total spend across both phases: ~$0.014 in self-pay USDC across four paid routes (preflight + forensics + decoys + watch). Engineering: a focused afternoon for level 4, another two hours for the level-5 climb.

A subtle gotcha: when x402station.io flipped to level 5, the dedicated x402 check turned neutral instead of pass — Cloudflare's isCommerce heuristic returns false for our domain (we look like documentation/dashboard, not a checkout), so the scanner doesn't bother running commerce-category checks against us. Only 4 hosts in the entire catalog trip isCommerce=true (x402.valoria.net, brapi.dev, fleawinder.com, x402.clashofcoins.com). That's the next dial to turn, but it doesn't move you past level 5 — it just lights up extra commerce-category checks.

Four things this scan made obvious
Agents using Cloudflare's readiness scan as a filter would skip 96.6%+ of the x402 catalog by endpoint reach. They'd never even see most x402 endpoints. There's a real distribution gap closing there for any project willing to ship the missing signals.
Decoys cluster at level 0. Every $1000+ endpoint we previously flagged as a Questflow-style honeypot sits at level 0 with zero signals. They aren't trying to be findable — they want random scrapers to stumble in and lose money. A pre-flight call catches them.
Single-provider concentration is single-readiness concentration. lowpaymentfee.com (10,659 endpoints, 41.1% of the catalog) is at level 0. orbisapi.com (9,882 endpoints, 38.1%) is at level 1. Together those two hosts are 79% of the catalog and pass none of the agent-protocol checks.
Hands-on small builders out-build the big providers. The five level-5 hosts run 1–2 endpoints each. The top two providers run 20,000+ between them, at level 0/1. Volume and agent-readiness are anti-correlated in this catalog.
Reproduce this
The data is reproducible from public sources — no x402station internals needed. Rough recipe (any language):

// 1. Pull the active endpoint list from agentic.market's public catalog API
const catalog = await fetch("https://api.agentic.market/services").then((r) => r.json());

// 2. Dedup endpoints by hostname (Cloudflare's scanner is per-host)
const hosts = new Map(); // host → first endpoint URL
for (const svc of catalog.services) {
for (const ep of svc.endpoints ?? []) {
const u = new URL(ep.url);
if (!hosts.has(u.host)) hosts.set(u.host, ep.url);
}
}

// 3. POST each host's URL to Cloudflare's scanner. Polite mode: concurrency=1,
// delay=20s — full catalog in ~4 hours, zero 429s. Concurrency=4 trips
// Cloudflare's ~50-scan rate limit and leaves the long tail unscanned.
for (const [host, url] of hosts) {
const res = await fetch("https://isitagentready.com/api/scan", {
method: "POST",
headers: { "content-type": "application/json" },
body: JSON.stringify({ url }),
});
// … persist await res.json() keyed by host
await new Promise((r) => setTimeout(r, 20_000));
}
Drop us a note via the dev.to comments or GitHub Issues if you want a copy of our 549-host JSONL — we're happy to share for verification.

If you're an agent operator paying x402 endpoints
Our oracle will tell you whether a URL is safe before you spend USDC on it, and alert you when state changes:

npx -y x402station-mcp
Six tools wired through MCP, all priced in USDC on Base mainnet via x402:

preflight ($0.001) — {ok, warnings[], metadata} for any URL
forensics ($0.001) — 7-day uptime, latency p50/p90/p99, decoy probability
catalog_decoys ($0.005) — full known-bad list as one JSON, cache locally
watch_subscribe ($0.01 = 30-day subscription + 100 prepaid alerts) — HMAC-signed webhooks when an endpoint goes zombie / decoy / dead
watch_status (free, secret-gated) — current state + recent alert deliveries
watch_unsubscribe (free, secret-gated)
npm · client SDK source · live oracle

Earlier piece: We probed 20,338 x402 endpoints. 161 are agent honeypots.

We probed 20,338 x402 endpoints. 161 are agent honeypots.

AFX — Sat, 25 Apr 2026 17:24:33 +0000

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"}'

returns 402 first, sign + retry, get the report