X402blockchainsX402 PAYMENT RESEARCH
x402 Blockchains and Assets: Bitcoin, Ethereum, Solana and XRP
Understand protocol support versus live provider coverage, and distinguish blockchains, native assets and stablecoin payments when researching x402.
A protocol is not a blockchain
x402 defines a payment interaction around HTTP requests; it is not itself a new blockchain or a required native coin. A deployment needs compatible buyer and server software plus a settlement path on a selected network. The x402 protocol guide explains the request flow, while the blockchain network directory shows the networks currently surfaced on this platform.
Ethereum and Base are separate networks
Ethereum is both a network ecosystem and the origin of the EVM environment used by several chains. Base is a distinct network with its own chain identifier and transaction history. An address can look identical on two EVM chains while balances and receipts remain separate. Do not use an Ethereum receipt as evidence of a Base purchase just because the sender address matches.
BNB Chain needs its own configuration
BNB Chain is another EVM network, not a synonym for Base or Ethereum mainnet. Confirm the asset contract, decimals and authorization mechanism accepted by the chosen route. XPay’s current public documentation describes Base and BNB integrations; inspect those capabilities rather than inferring all-network support from EVM compatibility. Our BNB x402 guide and Base x402 guide explain the two workflows separately.
Solana uses different transaction conventions
Solana is not an EVM chain. A Solana deployment uses its own network identifier, token mint and signing flow. An EVM address or signature cannot simply be pasted into a Solana request. Read x402 on Solana before selecting a Solana facilitator or comparing an application across chains.
XRP is an asset; XRPL is a network
XRP is the native asset of the XRP Ledger. The current x402 network documentation describes XRPL identifiers and payer-signed payments. That protocol-level documentation does not mean every facilitator or this explorer already offers complete XRPL coverage. Confirm a working production provider and a specific service implementation before advertising support. If platform coverage is planned, label it planned rather than implying a live transaction feed.
Bitcoin references need a concrete implementation
Bitcoin can appear in a project’s research content without being the payment network used by its API. Distinguish native BTC payments, wrapped assets and data about Bitcoin. Do not claim a Bitcoin settlement integration simply because a service returns a BTC price. Check the actual payment challenge and the provider’s maintained network support; this guide does not claim a live Bitcoin payment path on X402blockchains.
Protocol support is not the same as platform coverage
There are at least three checks: can the protocol describe the payment, can the chosen software execute the scheme, and does a working production facilitator or self-hosted settlement path exist? A fourth question is whether this particular explorer indexes it. Support in upstream documentation does not guarantee current provider access, full historical indexing or accurate project attribution.
Compare payment activity using common definitions
Keep chain, asset, time window and event type with every figure. Stablecoin payments, native gas fees, token market volume and deposits should not be merged into one number. The multichain analytics guide explains how to compare figures, and the data coverage page is the place to check the platform’s stated limits.