Networks

Coverage is counted per capability, never per network. There is no network_ready flag, because the standings become true in different orders on different chains.

The counts, from this deployment

Live from `GET /v1/networks`. Each is a count of networks with that capability *established*.
Standing	Count	What it means
`NETWORK_REGISTERED`	66	In the registry with a finality model, a family, a trust ceiling and a route profile.
`NANO_ACCESS`	66	The commercial catalogue offers reads on this network.
`VERIFIED_ACCESS`	66	Answers carry the five dimensions. This says the dimensions are attached, not that trust is high.
`WALLET_DATA_ENABLED`	10	ethereum, bitcoin, tron, solana, base, bsc, arbitrum, optimism, polygon, avalanche.
`MONITOR_ENABLED`	4	ethereum, bitcoin, tron, solana — qualified through the Data plane.
`PAYMENTS_ENABLED`	4	The same four, by Data-plane qualification. See the note below.
`LOCAL_DATA_WARM` / `HOT`	0	No local history anywhere. It is earned by real usage, never allocated in advance.

Two answers to "how many payment networks". /v1/networks reports PAYMENTS_ENABLED: 4 — networks qualified through the Data plane. /v1/payments/acquisition reports 13 — networks with a real acquisition path. Neither is wrong on its own terms. The operational number for this deployment is 9: the light path is following nine, and the Data plane that covers the other four is not running here.

The fleet and the broad layer

Two registries, deliberately:

15 networks have a dedicated engine — ethereum, bitcoin, tron, solana, base, bsc, arbitrum, optimism, polygon, avalanche, hyperliquid, sui, aptos, ton, xrpl. Each has a published acceptance record.
66 are registered for access. A network XRPC can read a balance from is not a network XRPC has an acceptance record for, and one list cannot say both.

Adding every network to the engine fleet would demand an engine, an acceptance record and a fleet entry for each. Access is broad; data is selective; trust is explicit; heavy infrastructure is earned by real usage.

Routes and independence

35 of 66 networks have a single route and no failover. The registry says which, rather than hiding it behind an aggregate.
0 networks claim independent sources. XRPC reads public endpoints and cannot learn whose upstream is whose, so agreement between two of them establishes nothing.

Payments coverage in detail

Followed on this deployment (9), via the light path: arbitrum, avalanche, base, bsc, celo, polygon, stellar, ton, xrpl.

One bounded read per session per pass, every 12 seconds, up to 200 sessions per pass. No block scan, no history, no local store — the state is a cursor per session.

Qualified through the Data plane (4), not running here: ethereum, tron, solana, bitcoin. These are ingested properly rather than followed per subject, which is why they are a separate path.

Per-network detail

GET /v1/networks/{slug} returns one network in full: every capability standing with the evidence behind it or what it is waiting for, the finality profile with its basis in prose, the trust ceiling, the route count and the family.

{
  "capability": "LOCAL_DATA_HOT",
  "standing":   "NOT_ESTABLISHED",
  "needs":      "demand evidence from Beta. Local history is earned by
                 real usage, never allocated in advance"
}

Networks that are not onboarded

Eight registry entries are NOT_ONBOARDED and say why in their own words — for example, that the route this build tried answered Unknown network because the provider does not serve that chain at that host. A chain being live is not the same as XRPC reaching it.