How x402 List Measures

What verified, payment-ready, listed, and not listed mean

A badge has four states, derived only from the directory row. verified is the strong tier: x402 List paid a real x402 call to the endpoint and it delivered (see below). payment-ready is the base tier: the endpoint answers a valid x402 challenge and is live, established for free by the monitor at scale. listed means it is in the directory but currently carries neither badge. not listed means there is no matching service in the directory at all. There is no self-attested state: a service cannot mark itself, and the strong badge cannot be bought, only earned by a delivered paid call.

How a service gets listed

A listing enters the directory one of two ways, recorded on each service as a source field. submitted means an operator or a user sent it in through /submit. imported means it was auto-imported from a public x402 discovery source: the x402 Bazaar (imported:bazaar) or x402scan (imported:x402scan), with the swader facilitator list read the same way to find settler addresses. Much of the directory is discovered and imported rather than hand-submitted, and every imported row is flagged as such: filter it with the SRC control on /services or with ?source=submitted|imported on the API.

An import is a discovery, not an operator endorsement: it means the service turned up in a public index we read, nothing more. An imported listing earns the payment-ready badge the same probe-based way as any other, and can rise to the paid verified tier the same way too; its operator can claim and correct it through the owner-update flow. Measured signals such as uptime and on-chain traction begin only when x402 List first observed the service, never when the service itself launched, and on-chain measurement began in 2026: a short measurement history is a floor set by when we started watching, never a claim about how old or how active the service really is.

What earns a service the verified and payment-ready badges

A listing carries at most one of two positive badges, and they mean different things. payment-ready is the base tier: the service's endpoint returned a real HTTP 402 with a well-formed accepts[] payload under an automatic x402 handshake probe, and is still responding. It is a protocol-conformance signal the monitor establishes for free, at scale, on every listing. It says the endpoint speaks x402 and is alive: a discovery signal, not an endorsement, and not a promise that a paid call will deliver.

verified is the strong tier, and it is earned only by a paid delivery probe. x402 List pays a real x402 call to the endpoint, and if that call settles on-chain and the service actually delivers a response, the service becomes verified. A checkmark here means one specific, tested thing: we paid this endpoint and it delivered. The fee covers the cost of the probe (the real outbound payment plus a small handling fee), never the badge itself: a call that does not deliver still costs the fee and earns nothing, and there is no refund. The badge cannot be self-declared, and paying does not buy it: only a delivered call earns it. The purchase is agent and API only, since humans do not sign x402 in the browser, and it is documented on the API page.

The two tiers decay differently. payment-ready is derived at read time from the last successful probe: after 7 days of consecutively failing probes it drops back to listed and re-earns itself automatically on the next good probe, so a service that went down for a while is not punished forever (a service that requires an API key, which the monitor cannot probe on its own, is exempt from this decay). verified has no time-based clock: once earned it stays until the endpoint's payTo address or payment schema changes on the wire, at which point it is revoked and can be re-earned only by paying again. A price change alone never revokes it, because changing a price is ordinary business.

The delivery probe can only reach endpoints it can actually pay: USDC on Base, at a non-templated path. Most of the directory qualifies, but a small number of services priced only on other networks cannot be probed this way, so they stay payment-ready and simply cannot rise to verified. That is a limit of what we can pay, stated plainly, not a judgement on the service and not a silently capped list. Once a service is listed, measured data such as uptime, pricing, and both badges 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.

Counting volume per service, not just per facilitator

The same settler attribution also produces a per-service figure, narrowed from the facilitator aggregate down to one service at a time. The attribution predicate is explicit: a USDC Transfer counts toward a service only when its recipient is one of that service's known payTo addresses and its sender is one of the settler addresses we already measure. Nothing is inferred from function names or amounts. This is the block exposed as assessment.traction on the service, and as the /api/v1/services/{slug}/volume and /api/v1/services/{slug}/buyers time-series.

It is a conservative undercount, and we say so plainly. Only settlements that reach a settler we already track are counted, so a direct wallet-to-wallet payment, or a settlement routed through a facilitator not in our registry, is not seen and not counted. A service can have real volume this figure does not yet show; it is a measured floor, never an estimate or an upper bound. The scope is USDC only: settlements in other assets are out of scope here, not counted as zero.

When a payTo address is shared across more than one service, for instance a shared fee router that several services settle through, the on-chain volume on that address belongs to the operator, not to any single service. Rather than reward the sharing by exempting it, or over-count it by letting every member claim the whole address (which would invite cloning), we attribute each member its pro-quota slice: the operator-level figure divided by the number of services currently sharing the payout. Such a service is flagged shared_payout, and its volume_usd_30d is the address total over that number of members, while its buyer and transaction counts stay whole operator-level figures. This is a declared convention, not an individually observed measure, and we say so in-band; spawning another clone dilutes the slice instead of adding volume. The daily /volume and /buyers series stay address-level (the full shared address, not pro-rata), so do not sum them across the services that share an address. The concentration ratios we publish, such as the top-buyer share, are left whole: a ratio does not change when the volume is divided.

One limit is worth stating outright: an operator can pay itself. Because the figure is counted from settlements, a service that settles to its own payTo from its own wallet can push its volume up with demand that is not real. We do not guess intent from this, so we publish top_buyer_share_30d next to the volume: the share of the last 30 days that came from the single largest buyer. A share near 100% means one address is behind almost all of it, which you can read as concentration and weigh yourself. This signal is published for the reader and folded into the score as a concentration discount, up to half the traction term. It is also part of why traction stays a small input, weighted around 10% of the assessment and never allowed to dominate, so a self-paid number cannot buy a top ranking. In ranking, the traction term also gates on recency: a service with no settlement in the last 30 UTC days, the same window as its published 30-day volume, contributes nothing to the term. Recent activity is a threshold to clear, not points you bank for settling a cent today.

If your settlements route through a facilitator we do not measure yet, the fix is in your hands. Submit your facilitator together with its settler wallets from the submit page: the form takes a service and a facilitator in one pass, so once we can see your settler addresses your per-service numbers start filling in. That is the honest way to close the undercount, rather than us estimating a figure we cannot verify on-chain.

The null-versus-zero rule carries through. A service with a mapped payTo on a measured network reports real numbers, where 0 is an honest "never settled on-chain via a facilitator we track", not a gap. A service with no known payTo, or whose payTo sits only on a network we do not measure yet, nulls every metric instead of faking a zero, and its status says which case it is. Traction is one small input to the assessment, never a dominant one.

One disclosure about our own payments. Two of our flows make real x402 micropayments to listed services: the paid assessment endpoint can, at the caller's request, run a live probe, and the paid verify flow pays a delivery probe to earn the verified badge. Both make an ordinary on-chain payment to the service and report what came back. Those payments are ordinary on-chain settlements, so when the probed service is measured they are counted in its traction exactly like any other buyer's payment. We do not exclude our own probe spend from the measured totals, and we do not special-case it out of a service's volume. The undercount rule still holds in the other direction: we only ever count what settler attribution observes on-chain, never an estimate.

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 the per-service assessment measures

Each service page carries an assessment: a set of evidence-backed signals, not a single score. The measured parts are computed only from data we observe. Reliability comes from the same uptime and response monitoring described above. x402 compliance is a checklist run against the service's own HTTP 402 response: whether the accepts[] payload is well formed, the payTo address is present and coherent, the price is a sane atomic amount, and the endpoint is served over HTTPS. Site and docs reachability records whether a homepage, an OpenAPI spec, a pricing page, llms.txt, robots, and terms are actually reachable. Domain and economics record the domain age and how the price sits against others in the same category. Every one of these is measured, and a signal with no data reads unknown or null, never zero.

Three of those compliance checks look at whether the 402 envelope can actually be signed by a standard x402 client, not just whether it is well formed: whether the captured payload declares the current x402 version (2), whether every EVM entry carries the EIP-712 domain parameters (extra.name and extra.version) a standard client needs in order to build the signature, and whether an envelope declaring version 2 travelled in the payment-required response header rather than only in the body. A service with at least one EVM route missing those domain parameters does not grade above C, however clean the rest of its envelope is, because an agent that lands on that route cannot pay for it. The other two are recorded as facts and do not cap the grade: a version 1 envelope is signable by a version 1 client, and an envelope delivered in the body is harder to discover, not impossible to pay. What all three describe is the payment envelope on the wire, never the quality of what the service sells: the claim behind the ceiling is precisely that a standard client cannot sign a payment for that route, not that the service is unreliable. A check we could not evaluate (nothing captured yet, or nothing to apply it to, such as the EIP-712 domain on a Solana-only service) reads unknown and leaves the denominator, never counting as a failure.

These three checks were added on top of the eleven that came before them, so the checklist went from 11 to 14 and the /scores history carries a visible step at that date. Earlier points keep the denominator they were measured with: recomputing them would mean rewriting an observation after the fact, so we leave them as recorded and say so instead.

A separate risk flag is deterministic only. It fires as danger solely on an exact match against a blocklist, or as warning only when a name resembles a reserved brand and the verified payTo does not match, both at once. It is never raised from low uptime, a high price, a new listing, or a language-model guess.

On top of the measured signals sits an AI synthesis: a short summary, capability tags, and a category. Every AI-derived field is labelled with its own value, a confidence from 0 to 1, and source: ai, so it can never be mistaken for a measured fact, and it never overrides one. There is no composite trust score, by design: we publish the parts and let you weigh them.

The measured sub-scores and the captured price are also served as machine-readable time-series, at /api/v1/services/{slug}/scores and /api/v1/services/{slug}/price, and the full assessment is embedded in the service detail JSON at /api/v1/services/{slug}.

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 earned by a delivered paid call, never self-attested or bought; 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.

Reusing this data

Everything measured here is meant to be reused. The directory data (listings, uptime, pricing, and on-chain settlement figures) is published under the Creative Commons Attribution 4.0 license (CC BY 4.0): reuse, redistribute, and build on it, including commercially, as long as you credit x402-list.com as the source. Every API response also carries a machine-readable provenance block and a ready-to-use attribution line, and the full license terms live on the API page.