Networks#

All networks use the same Net payment envelopes. Enabling another network may require asset-registry entries, facilitator configuration, conformance fixtures, and implementation in the relevant x402 scheme module. Net core does not add a new envelope type for each chain.

CAIP identifiers and the asset registry#

Networks and assets are named with CAIP-2 (chain, e.g. eip155:8453) and CAIP-19 (asset) identifiers. IDs compare exactly and case-sensitively — eip155:8453/erc20:0xABC and …0xabc are distinct ids; equivalence is registry policy, never string normalization.

The asset registry is a signed document (net.payment.asset_registry@1) mapping registry entries (symbol, decimals, CAIP id) that both provider and caller reference by hash. A capability's price references the registry it was authored under, so a caller can confirm they're pricing the same asset the provider meant. An asset absent from the registry is a hard reject, not a guess.

Enablement is a ladder, and each rung has its own state#

Enablement is deliberate and per-rung. Do not read the ladder as "all shipped." As of this writing:

Enabling a real network for a deployment means: list it in the spend policy's allowed_networks, wire a facilitator config pack, provide an ExternalSigner, and — to serve above observed — have a chain checker for it. The registry is the asset allowlist; it is not the enablement switch.

Config packs#

A pack is a pre-filled FacilitatorConfig for a known facilitator — endpoint, the (scheme, network) pairs it offers, chain RPC endpoints for the independent checker, and the tier to require before serving:

use net_payments::facilitator::packs;
 
let sepolia = packs::x402_org_base_sepolia();          // no credentials needed
let base    = packs::cdp_base_mainnet("secret://cdp"); // secret *ref*, not a key
let solana  = packs::cdp_solana_mainnet("secret://cdp");
let xrpl    = packs::t54_xrpl_mainnet();

Credentials are passed as references the deployment resolves, never as literals in config — the same reason the signer seam takes a callback rather than a key.

Two fields on the config are worth setting deliberately rather than inheriting. required_tier is per CAIP-2 network and defaults to observed, which is receipt-trust; if you want depth, say so. And rpc_endpoints is what the independent checker queries — without one, nothing can promote a payment above observed no matter what the facilitator reports.

Mock is the conformance backbone#

Every example in this section, and the compiled docs_payments.rs, runs against MockFacilitator and default_mock_registry. That's deliberate: the mock rung exercises the identical lifecycle with no real value at stake, so a demo can't quietly train the policy path wrong. Under SpendProfile::Production, even a mock spend needs an approval.

Why config-not-code matters#

A new payment scheme (EVM exact, SVM exact, XRPL exact) is real code — but it lives quarantined in the x402 scheme modules, the one place chain-specific reality is allowed. Net core never grows a per-network branch. So "support chain X" is a pack + registry entries + a conformance run, and the commercial-fact envelopes are unchanged.