Start from the payment, not the chain
Chain selection usually begins with the ecosystem a team already knows, and the requirements are fitted to it afterwards. For a payments product that order is backwards. A payments system has a small number of properties that are not negotiable — how quickly a payment is final, what it costs and whether that cost is predictable, what the issuer of an asset can do when something goes wrong, and whether there is enough liquidity in the currencies users actually hold. The chain should be chosen against those properties, because each of them is set by the protocol and cannot be engineered around later at reasonable cost.
This piece compares the XRP Ledger with EVM networks — Ethereum and the layer 2 networks that settle to it — on exactly those properties. Both are public ledgers with years of production use. They were designed for different things, and the differences show up most clearly in payments.
Settlement and finality
On the XRP Ledger, validators reach consensus on a new ledger version every few seconds, typically three to five, and a transaction in a validated ledger is final. There is no probabilistic waiting period and no reorganisation to account for. For a payments product this is the most important property on the list: a merchant, a wallet or a reconciliation job can treat a validated payment as settled.
Ethereum produces a block roughly every twelve seconds, and a transaction reaches economic finality after about two epochs, around thirteen minutes. Layer 2 networks confirm transactions in seconds, but those confirmations are the operator's promise; final settlement comes when the layer 2 posts its state to Ethereum, and for optimistic rollups withdrawals to Ethereum carry a challenge period measured in days. None of this prevents payments on EVM networks. It does mean the product has to define what "paid" means, and design for the gap between a fast confirmation and final settlement.
Cost, and its predictability
XRP Ledger fees are a fraction of a cent and rise only modestly under load, because the fee exists to deter spam rather than to auction scarce block space. Ethereum fees vary with demand and can make small payments uneconomic during congestion. Layer 2 fees are low, often below a cent, but they are set by the rollup operator and still depend on the cost of posting data to Ethereum.
For a payments product the level matters less than the predictability. A fee that is usually tiny and occasionally large is hard to price into a product that charges its own users a fixed fee.
What the protocol does for you
The XRP Ledger has payments features built into the protocol: direct payments, escrow, checks, payment channels for high-frequency micropayments, and cross-currency payments that route through its built-in exchange and automated market makers. These are protocol objects, not contracts, so they carry no custom code to audit.
On EVM networks every one of these is a smart contract — widely used standards such as ERC-20 for tokens, and either audited libraries or bespoke code for escrow and payment logic. That is the source of EVM's strength: anything expressible as a contract can be built. It is also the source of its cost, because each contract is code the product owns, audits and operates.
Controls for regulated assets
A regulated payments product usually needs the asset issuer to be able to act: freeze an account under a legal order, recover funds sent in error, or restrict holding to verified customers. On the XRP Ledger these are protocol features available to issuers — freezes, clawback, authorised trust lines and deposit authorisation. On EVM networks they are features of the token contract, such as allowlists, pause functions and forced transfers, and they work only as well as that contract is written and governed.
Neither approach is wrong. The protocol route is narrower and needs no custom code; the contract route is flexible and puts the controls, and the responsibility for them, inside the product's own codebase and audit scope.
Liquidity and stablecoins
A payments product moves the currencies its users hold, which today mostly means dollar stablecoins. The deepest stablecoin liquidity sits on Ethereum and the major EVM networks. The XRP Ledger hosts a smaller but growing set of issued stablecoins, including RLUSD. If a product must accept or settle in a particular stablecoin at volume, check where that stablecoin's liquidity actually is before choosing a chain.
The comparison
Comparison
Requirement | XRP Ledger | EVM networks |
|---|---|---|
Finality | Deterministic, typically three to five seconds | Ethereum: economic finality in about thirteen minutes; layer 2s confirm in seconds and settle to Ethereum later |
Fees | Fractions of a cent, stable under load | Variable on Ethereum; low on layer 2s but set by the operator |
Native payment features | Payments, escrow, checks, payment channels, cross-currency paths | Built as smart contracts, on standards such as ERC-20 |
Issuer controls | Protocol-level freeze, clawback and authorised trust lines | In the token contract: allowlists, pause, forced transfer |
Programmability | Limited on the ledger; an EVM-compatible sidechain runs alongside it | Full smart contracts |
Stablecoin liquidity | Smaller and growing, including issued dollar stablecoins such as RLUSD | The deepest dollar stablecoin liquidity |
Account model | Accounts hold a small XRP reserve | No reserve; every action pays gas |
Tooling and talent | Smaller ecosystem, focused on payments | The largest ecosystem and hiring pool |
Privacy | Public ledger | Public ledger; privacy needs additional layers |
When each fits
Choose the XRP Ledger when payments are the core flow, when settlement must be final in seconds, when fees must be predictable enough to price, and when the issuer controls a regulator expects should come from the protocol rather than from custom code. In our own work — including a health payments wallet rebuilt for compliance on the XRP Ledger — those properties did most of the architectural work.
Choose an EVM network when the product's value is in logic that only a smart contract can express, when the stablecoin or asset it depends on lives there, or when the team and the audit market it relies on are EVM-native. Many products end up hybrid: settlement on the chain whose payment properties fit, with programmable logic kept off-chain or on a separate network.
Key custody deserves its own decision whichever chain is chosen. Users can hold their own keys, the platform can hold them, or a regulated custodian can, and each option carries different recovery procedures, security obligations and regulatory consequences.
Questions to settle first
- What does "paid" mean in the product, and how long can it take to become true?
- Which currencies will users hold, and where is their liquidity?
- Which issuer controls will a regulator or a partner bank expect, and who operates them?
- How much custom contract code is the product willing to own, audit and run?
We work through these questions in Blockchain Engineering engagements, most often with clients in financial services, where the answers are shaped as much by regulation as by technology.