How x402 List Measures
This page documents how x402 List measures what it publishes, and what each label actually means. The point is that every figure here is verifiable: measured, not claimed. The directory is curated by hand and small on purpose. It is not the biggest list, and it does not try to be. What it is: a list where a checkmark is earned and every number can be checked against the chain.
What verified, listed, and not listed mean
A badge has three states, derived only from the directory row. verified means the service is in the directory and carries the verified flag. listed means it is in the directory but does not (yet) carry that flag. not listed means there is no matching service in the directory at all. There is no self-attested state: a service cannot mark itself.
What earns a service the verified checkmark
A service earns the verified flag when its endpoint returns a real HTTP 402 with a
well-formed accepts[] payload under an automatic x402 handshake probe, and
the result passes manual review. This is a protocol-conformance check: the endpoint has
to actually answer the way the x402 standard requires. A new submission starts unverified,
and the flag cannot be self-declared or bought. Once a service is listed, measured data
such as uptime, pricing, and the verified flag stays read-only for its owner: an operator
can update descriptive metadata, never the measured numbers.
How a facilitator is verified on-chain
Facilitators use a separate gate. A facilitator, or one of its chains, is marked on-chain verified only when measured USDC settlement volume greater than zero is read directly from the chain. A declared facilitator with no measured volume stays listed, not verified. The submission probe here checks on-chain presence (settler addresses that actually originated USDC settles in a recent window), not an HTTP 402 response. That probe is advisory only: it never auto-verifies, never auto-rejects, and routes to manual review. Volume is measured directly from blockchain transactions, not self-reported.
Counting volume without double-counting
Volume is attributed by settler address: the engine anchors on transactions whose sender
is one of a facilitator's known settler EOAs, never by function signature. It then counts
only the settler-sent leg(s) per transaction: one leg for a direct or escrow settle, and
all N settler-originated legs for a batch settle. A direct settle emits a single USDC
Transfer and counts once. An escrow-style settle emits both an incoming and
an outgoing leg; the engine sums only the legs sent by a settler address, and if none
match it falls back to the single largest leg, so an in-and-out pair is never
double-counted. On Solana, where the settler is the fee-payer rather than a token owner,
the same logic almost always reduces to the single largest leg, and settles are de-duplicated
by signature first. All amount math is done in BigInt and converted to human units only at
the very end, so the figure is exact rather than floated.
Where the numbers come from
The volume figure is measured independently on-chain. x402scan, and the swader facilitator list, are used only to discover the current set of settler addresses worth measuring. The published volume is then computed from those addresses directly on the chain: EVM chains such as Base through HyperSync, and Solana through the Helius transaction API, across the chains we currently measure. x402scan's own amounts are used only for logging and sanity checks, never as the source of a published number. On each facilitator page, the date a discovery source last reported an address is labelled as not an on-chain measurement, precisely because on-chain activity can be more recent.
Why some settles are filtered
A small set of facilitators run mixed rails on Solana: their settler wallets also carry traffic that is not x402. On Solana, for that short list (coinbase, payAI, bitrefill) a settle must additionally carry an on-chain x402 memo marker to count. On EVM chains such as Base, settlement is attributed by dedicated settler address alone and no memo filter applies, so this safeguard is Solana-specific. Every other facilitator is treated as clean and gets no filter at all, because its genuine x402 settles are unmemo'd and a blanket memo filter would wrongly drop most of its real volume. The filter is per-facilitator and removal-only: it runs after attribution and can only drop an already-counted settle, never add or inflate one.
How uptime is measured
The one official per-network method is the
per-service mean of the latest daily uptime rollup, and it is published
verbatim in the /api/v1/stats
and /api/v1/networks payloads so the method documents itself. Per service,
uptime is successful checks divided by total checks over the window, built from daily
snapshots; a window with no checks reads null (not yet measured), not zero, so an
unmonitored service is never shown as down. Rollups recompute uptime from the summed
counts rather than averaging daily percentages, which would mis-weight days with unequal
check counts. Services are checked about every 15 minutes, over rolling 24h, 7d, 30d, and
90d windows.
How far back the data goes
Raw per-check records are kept for 30 days, then purged. Daily uptime rollups and facilitator volume snapshots are kept perpetually and are never pruned. As a result the 90-day window is a genuine 90 days once a service has been monitored that long; a younger service simply has fewer daily rows, and its 90d figure converges toward 30d until enough history accrues. We do not claim raw-check retention beyond 30 days.
What we deliberately do not claim
x402 List is curated and small on purpose. We do not pad the directory to inflate counts, and we do not list spam. We do not claim to be the only directory measuring settlement on-chain: other dashboards do this too now, and that is fine. The claim we do make is narrow and testable: a checkmark is measured, never self-attested; volume is read from the chain, not from a third party; and every published figure can be checked. Small, curated, verifiable, in the spirit of a guide rather than a phone book.
Everything here is verifiable
Every figure on the site is mirrored as machine-readable JSON. Facilitator volume is at /api/v1/facilitators, aggregate statistics and the published uptime method are at /api/v1/stats, the full catalogue and data model are at /llms-full.txt, and the human-readable views live at /facilitators and /services. Settler addresses on each facilitator page link straight to the relevant block explorer, so the on-chain numbers can be recomputed from scratch.