How x402 Lens counts.

Three kinds of evidence, never blended.

x402 Lens combines three kinds of evidence. Each is labeled wherever it appears, and they are never blended into one number.

• Discovery listings. Services are discovered from public x402 directories and facilitator listings. A listing tells us a service exists and what it advertises, not that anyone uses it.
• Payment-challenge probes. Every listed resource is verified with one safe, unpaid request that expects an x402 payment challenge. Probes power uptime, latency, the chains and prices a service is shown with, and listing-versus-live comparisons. A service is flagged as a listing mismatch only when the live challenge directs payment to a wallet none of its listings advertise; price or chain differences are noted on the endpoint and never count against the service. Probes never pay.
• On-chain settlements. We index Base and Solana mainnet continuously, and a transfer counts as x402 activity only on positive evidence: it was settled by a known facilitator, or it emitted a settlement event from a canonical x402 contract, the Exact Permit2 proxy or the batch settlement escrow, neither of which exists for anything else. Arbitrary token transfers are never classified as x402 payments.

Test calls made from a service page with a connected wallet are real x402 payments signed by that wallet and relayed unchanged. They settle on-chain like any other payment and are counted the same way.

What each number means.

Transactions

Observed on-chain x402 settlements in the selected window, deduplicated by chain, transaction and event index. Under batch-settlement schemes one on-chain claim can stand for many off-chain paid requests: we count claims, never inferred calls.

Volume

Sum of settled transfer amounts, normalized by token decimals. USD values are assigned only to issuer-verified stablecoins (USDC on the indexed chains). Where a scheme settles a variable amount, the amount observed on-chain is recorded, not the listed maximum.

Unique buyers

Distinct payer wallets observed in settlements during the window, counted exactly rather than estimated. One person or agent may control many wallets.

Services live

Distinct indexed services that received at least one attributed settlement in the window.

Indexed services

Services present in at least one discovery source that are not dead and not on an ephemeral host. A service is marked unreachable when its endpoints stop answering payment challenges for three days, and dead once it has been unreachable for 30 days with no payments in that time; a successful challenge or a new payment restores it. Duplicates merged into another listing are folded into that listing rather than counted.

Uptime

Share of probe attempts over the trailing 30 days that returned a parseable 402 payment challenge, measured per service across its endpoints.

Latency (p50)

Median round-trip time of successful probes over the trailing 30 days.

Rank

A service’s position in the x402 Lens ranking, shown as #N in the services directory and used as its default order. It is computed per time range — 24 hours (the last full UTC day), 7 days and 30 days — so the position follows the range you select. The ranking is proprietary; a service without enough evidence in a range is unranked there and sorts last.

Reported calls

The 30-day call count a directory publishes for a resource. This is facilitator-reported data we store for context and cannot independently verify. It is never mixed into on-chain transaction counts.

Wallets, not URLs.

Payments are attributed to a service by its payee wallet. A wallet is linked to a service only on first-party evidence, what the service advertises and what its live payment challenges return, never third-party labels.

What we cannot see.

What we cannot see, stated plainly. Every total is a lower bound, and coverage grows as the registry does.

• Unregistered facilitators. Attribution starts from a maintained registry of facilitator settlement identities. Facilitators rotate accounts; until a new account is registered, its settlements are invisible to us, because a transfer is never assumed to be an x402 payment. Settlements through the canonical x402 contracts are indexed whoever sends them, but an unregistered sender leaves them without a facilitator.
• Off-chain and private settlement. Payments settled outside public chains, or batched off-chain, may be unobservable. Batch-settlement claims are counted as single settlements and never expanded into estimated call counts. The escrow deposit that funds a channel is not counted as a payment, and a claim against a channel whose creation we never observed is dropped rather than attributed to a guessed payer.
• Chain scope. Settlements are recorded only once they are final on their chain. Only Base and Solana are indexed. A chain we do not index is not shown, even when a service advertises it. Historical coverage begins at each chain’s backfill start.
• Retention. Raw history is archived in full and never discarded, and every figure can be rebuilt from it. Charts, lifetime totals and unique-buyer counts do not depend on any retention window.

Listings are claims, not facts.

• Resources are deduplicated across sources with their provenance retained. Conflicting listings are never silently merged, and what a listing claims is stored apart from what a probe observed.
• One live service per host. Duplicate catalog entries for the same host are merged, and their history moves with them.
• The chains and prices shown for a service are what it advertises now, taken from its latest verified observation. A chain a service stops offering disappears with the next observation.
• Services on ephemeral tunnel hosts (trycloudflare, ngrok and similar) are indexed but flagged and excluded from headline metrics and default views.
• Delisted resources are marked stale rather than deleted.
• Service categories are derived heuristically from listing text. Search ranking uses machine-generated keywords and task phrases, which never feed metrics.

Current, and traceable.

Settlement data typically trails the chain by minutes and listings refresh several times a day. The “Indexed … ago” chip on every page is the authoritative freshness signal.

Raw listings and chain responses are retained so that any figure can be traced back to its evidence. Facilitator settlement identities are on-chain facts assembled from public sources and spot-verified against chain data. Corrections are welcome.