x402 on Base vs Solana: how buyers should choose

Network identifiers matter

Current x402 uses explicit network identifiers such as CAIP-2 forms. Human labels like Base or Solana are useful in navigation but should not replace the value the server returns. A client that supports one chain cannot safely assume it can satisfy a requirement for another.

Facilitator compatibility

A facilitator verifies and settles only the scheme, network and asset combinations it supports. The x402.org default facilitator is intended for specific test networks, while production facilitators advertise their own coverage. Buyers should verify facilitator and client support before authorizing a mainnet workflow.

A practical policy

Allow the smallest set of networks your workflow needs. Bind maximum payment, accepted asset and endpoint host to each tool. When a service changes its payment requirement, pause and review instead of silently switching networks or tokens.

The network is one part of a payment requirement

A buyer does not pay a human label such as "Base" in isolation. It selects one offered requirement containing a scheme, CAIP-2 network identifier, asset, amount or maximum, destination and timing constraints. The client must support that combination. Two routes on the same chain can still require different schemes or assets, so chain compatibility alone does not guarantee payment compatibility.

This is also why a directory filter is for discovery rather than execution. TOLL·402 can help a buyer find Base or Solana services, but the current 402 response controls the transaction. If the live requirement differs from the listing, the agent should apply policy to the new requirement instead of rewriting it from cached directory data.

How signing differs for Base and Solana

Base belongs to the EVM family. Current x402 clients use an EVM signer and register the payment schemes they are prepared to satisfy. Solana uses an SVM signer with different key material and signing libraries. A wallet application may display both networks, but application code still needs the correct signer adapter and mechanism package.

Keep signing behind a small policy-controlled interface. The model should request a tool operation; trusted code should validate the requirement and ask the appropriate signer to authorize only that payment. Do not let model output choose a raw transaction or read either private key.

Does one network make x402 calls cheaper or faster?

The price in the requirement is the amount the seller asks the buyer to authorize. Network fees, facilitator design, settlement timing and wallet operations can add different operational costs, but a broad chain comparison does not tell you the effective cost of a particular service. Some payment schemes are designed to reduce the impact of settling every small authorization individually.

Measure the real route. Record the quoted amount, time from initial request to useful response, settlement result and any wallet or facilitator cost the buyer bears. A service's own latency often dominates the user experience. Avoid choosing a network from generic speed claims when the endpoint, facilitator and payment scheme determine the actual path.

A practical decision sequence

Start with capability: find the service that produces the required output. Next list the requirements it actually offers. Remove options your client, signer or facilitator cannot support. Apply organizational policy for allowed networks, assets and destinations. Finally, compare effective cost and reliability using one controlled call.

If two equivalent services remain, prefer the network already used by the agent's dedicated wallet and monitoring. Adding a second chain creates another balance, signer path, incident procedure and reconciliation source. That overhead can be justified by a uniquely good service or meaningful redundancy, but it should be a conscious choice.

• Capability and output fit
• Live supported requirements
• Signer and facilitator compatibility
• Allowed network, asset and destination
• Observed cost, latency and failure behavior

How to support both without unsafe fallback

A multi-network client can register both EVM and SVM schemes, but it should not pay whichever requirement happens to be first. Rank requirements through policy: known destination, allowed network, approved asset, maximum amount and preferred settlement path. If none qualify, return a clear refusal to the agent.

Failover should switch services or requirements only after checking that the output is equivalent and the new spend remains inside the task budget. A Solana fallback for a Base route is not a transport retry; it is a new purchasing decision with different signing and reconciliation. Log it accordingly.

Related directory entries

Sources and methodology

TOLL·402 distinguishes public claims, registry discovery, unpaid quote checks and settled paid-call verification. Sources below support the visible claims; presence in a registry is not treated as verification.

1. x402 network and token support — Authoritative network identifiers and facilitator guidance.
2. x402 buyer quickstart — EVM and SVM signer setup.
3. TOLL·402 network filters — Curated network coverage.