← x402 Reputation Index

We tried to buy from 1,984 x402 endpoints. 52% wouldn't complete the sale — and HTTP 200 is not delivery.

Updated continuously from the live index · raw numbers: /api/v1/status

x402 is having a moment. 100M+ agentic payments on Base, Google/Visa/AWS/Anthropic in the foundation, AWS shipping native x402 support in Bedrock AgentCore. Agents can now discover an API in the Bazaar catalog, sign a USDC authorization, and buy data in one round trip — no signup, no API key.

Which raises a question no catalog can answer about itself: when your agent autonomously pays a stranger's API, what actually comes back?

We built the infrastructure to answer that. We enumerated the entire CDP Bazaar catalog (Base + USDC), probed every endpoint's unpaid 402 handshake, attributed on-chain settlements to endpoints via facilitator-sender filtering, ran wash-traffic heuristics, and — for endpoints that looked good on paper — spent real USDC to see if they'd deliver.

Here's what the catalog actually looks like.

The numbers

Of 57,749 endpoints indexed (96% probe coverage):

Roughly a third of the catalog is simply gone: DNS failures, 5xxs, or servers that no longer speak x402 at all. They're still listed, still discoverable, and an agent that trusts the catalog will still try to pay them.

Then we tried to buy things

Probing a 402 handshake is easy, and every directory in this ecosystem does it. It answers neither of the questions a buyer actually has: will this endpoint sell to me? and is what it sold me real? So we attempted a real purchase — signed USDC authorization, facilitator settlement, the whole flow — against 1,984 endpoints.

Fewer than half of the endpoints we tried to buy from would complete a sale. The honest caveat, which we'd rather state than bury: some of those refusals are endpoints that need request parameters the catalog never declares. That is itself the finding — the catalog does not carry enough information to buy what it lists, and an agent shopping from catalog metadata alone will hit this wall constantly.

HTTP 200 is not delivery. 30 endpoints returned a clean 200 wrapped around nothing — an error object, an empty array, a stub. One took payment and returned a Node.js module-resolution crash ({"success":false,"error":"Cannot find package 'node-fetch'..."}). You cannot catch this by probing. You catch it by paying and reading the body.

And some just keep it. 26 endpoints settled our payment on-chain and then answered the paid request with an error. Two more sit in a nastier category: they complete the handshake, accept the signed payment authorization, and return 401 Unauthorized. Whether they ever submit that authorization is entirely up to them — under EIP-3009 they hold a valid signature they can cash any time before it expires. Your agent has no way to know.

Volume lies. A large share of on-chain x402 traffic is speculative or wash: pay-to-mint "resources" that exist to farm transaction counts, and micro-transaction clusters where enormous settlement counts come from a handful of addresses. The worst payout address in our corpus has 25,675,946 facilitator-confirmed settlements from just 1,555 distinct buyers, averaging $0.0167 each — that's 16,512 purchases per buyer. 33 payout addresses show that same shape. On raw volume these look like the most popular APIs in the ecosystem. Any index that ranks by settlement count is ranking them first.

Attribution is subtle. Naively counting "USDC received by the endpoint's payout address" over-counts wildly. Our settlement data only counts transfers sent by a known facilitator contract (~40 facilitators tracked). And even then: one payout address can back thousands of endpoints — the record in our corpus is 14,408 endpoints sharing a single payTo. A dead endpoint on that address inherits the settlement history of its working siblings. That's why our index refuses to grade shared-payTo endpoints as Trustworthy on on-chain signals alone: they have to pass a real paid-delivery test. As far as we can tell, no other index does this.

Why this matters

Agent frameworks are getting spend policies, budgets, and wallets. What they don't have is a pre-spend trust check. On-chain history is public but misleading; catalog metadata is self-reported. The only signal that can't be faked is: someone paid this endpoint recently and verified what came back. That's the dataset we're building, endpoint by endpoint, with a budget-capped pipeline that pay-tests everything that qualifies.

Don't take our word for it

Every verified delivery in this post corresponds to USDC leaving a wallet on Base — 924 settlement transactions, $9.94 USDC, from 0xb92a…1E0f. "We verify delivery" is becoming a claim everyone in this category makes; a transaction hash is not a claim.

We rotate buying wallets, and we'd encourage anyone doing this work to do the same. A tx hash names its payer, so an auditor's address is public by construction — which means an endpoint can whitelist it and serve the auditor better responses than it serves you. Concealment can't fix that. Rotation can, because a whitelist is only as good as its last entry.

The whole ledger is public and free — every settlement, its transaction hash, and what came back:

curl https://x402rep.invoitech.com/api/v1/ledger

Check an endpoint yourself

HTTP — the first few lookups each day are free, after that the endpoint answers 402 Payment Required and any x402 buyer client pays $0.01 USDC and retries automatically. Yes, we eat the protocol we audit:

Coverage note: 96% of the catalog has been probed; paid delivery testing runs continuously under a monthly budget, so the verified-delivery set grows every day. Verdicts carry last_probed and verdict_computed_at so you can always see how fresh a given answer is.

curl "https://x402rep.invoitech.com/api/v1/reputation?url=<endpoint_url>"

MCP, for your agent:

claude mcp add --transport http x402-reputation https://x402rep.invoitech.com/mcp

Corpus stats: GET /api/v1/status — the numbers in this post are live there.