The x402 registry coverage playbook: Bazaar, x402scan, and the chain
Being payable and being findable are different properties, written by different systems. This is the coverage map we operate our own endpoints by: what writes each surface, how to read it back for free, and where the latencies are.
The map
| surface | a listing is written by | read it back | latency |
|---|---|---|---|
| CDP Bazaar | a settled payment against that exact resource while its 402 carries a valid declaration — per resource, never by deployment | page the public catalog API (limit=1000 + offset) and search it — the documented payTo filter is accepted and ignored |
minutes after a qualifying settlement |
| x402scan | registering at x402scan.com/resources/register — it imports an openapi.json and validates against live discovery data |
search the explorer by your payTo or resource URL | immediate on registration |
| x402‑list | a manual submission form, reviewed by a human | read the list | days — it is a human queue |
| the chain itself | nothing to submit — every settlement is a USDC transfer to your payTo on Base, visible to anyone | any Base explorer, by your payTo address | a block |
The two habits that keep coverage
- Settle one call per resource, after every declaration change. The Bazaar row is a snapshot of the declaration that was live when a payment settled. Fix your envelope and stop there, and the catalog keeps serving the old one. This is the cheapest self-test in the ecosystem: one minimum-price call to your own endpoint, from any funded wallet.
- Give each endpoint a distinct price. The amount is the one field a bare chain explorer shows. Unique prices make every settlement attributable to its endpoint with no analytics at all — we run our own price sheet this way, and it has already paid for itself in debugging time.
Verify the whole map by hand, free
# Bazaar: is the resource in the catalog? (page through; total is in .pagination)
curl -s "https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources?limit=1000&offset=0" \
| grep -c "your-host.example.com"
# chain: has anything ever settled to your payTo?
curl -s "https://base.blockscout.com/api?module=account&action=tokentx&address=0xYOURPAYTO&page=1&offset=10&sort=desc"Two operating notes from doing this daily: explorer APIs rate-limit shared egress IPs, so an occasional 429 means "try again", not "no data" — and an answer you could not read is never evidence of absence.
Or buy the whole read in one call
POST /presence ($0.15) fetches
your live 402, reads the payTo and resource it declares, and checks the full Bazaar catalog,
the x402scan explorer, and Base transfer activity in one report — per-surface verdicts of
listed, not_found, or unknown with the evidence
attached. A surface it cannot read is reported unknown, never guessed. Pair it
with POST /lint ($0.25) when a
not_found needs explaining: coverage tells you where you stand, the lint tells
you what is blocking.