XRP Ledger vs Stellar for payments: RPC, fees and speed

TL;DR

Two blockchains built for payments can produce very different engineering decisions. XRPL offers native financial operations and liquidity routing, while Stellar combines payment primitives with Soroban smart contracts. But choosing between them involves more than transaction speed and fees.

How do their RPC methods differ when querying account state, estimating fees, routing payments and submitting transactions? How does each network handle transaction submission, confirmation and real-time updates? And what do these differences mean for the way you build and operate a payment application?

This guide compares XRPL and Stellar, covering RPC methods, transaction lifecycles, speed, fees and ecosystem growth. The goal: help you choose the right foundation for a reliable payment system.

Building payment systems

Already familiar with XRPL and Stellar? Skip the network overview and head straight to “RPC infrastructure” to explore endpoints, API methods and deployment options.

Networks like the XRP Ledger (XRPL) and Stellar are designed to support payments, asset transfers and currency exchange.

The XRP Ledger (XRPL) is a public blockchain launched in 2012 with a focus on payments and the exchange of digital assets. Its native currency, XRP, is used to pay transaction fees and can serve as a bridge asset for currency conversion. The ledger also supports issued currencies, a built-in decentralized exchange and pathfinding that identifies routes for payments between different assets.

New to XRPL? Here’s a quick guide to how the XRP Ledger works.

Stellar is a public blockchain launched in 2014 to connect financial institutions, payment services and digital asset networks. Its native currency, lumens (XLM), is used to pay transaction fees and maintain account reserves. Stellar supports the issuance of assets such as stablecoins, cross-currency payments through path payments and a decentralized exchange. Its Soroban smart-contract platform extends these capabilities to programmable financial applications, including tokenized assets and contract-based payment workflows.

Want to learn more about Stellar before diving in? Start with this overview.

Understanding how these networks handle transactions, fees, liquidity and ledger data is essential.

A reliable payment architecture needs to:

• Verify settlement: confirm transaction outcomes using validated ledger data before updating payment statuses
• Route assets efficiently: use XRPL pathfinding or Stellar path payments to identify available routes for cross-currency transfers
• Estimate transaction fees: query fee on XRPL or getFeeStats on Stellar to inform transaction preparation
• Retrieve account and transaction data: use native RPC methods to access balances, ledger entries and historical transactions
• Monitor transactions: use XRPL WebSocket subscriptions or Stellar RPC polling to track transaction progress
• Maintain reliable infrastructure: monitor RPC latency, endpoint health, data availability and protocol upgrades

How do XRPL and Stellar handle these requirements differently? To find out, let’s compare their speed, fees, RPC methods and typical transaction lifecycles.

XRPL vs Stellar: speed and fees

Speed

Payment speed directly affects how responsive an application feels. When comparing XRPL and Stellar, the key consideration is how quickly a transaction is confirmed and the application can reflect that result to the user.

XRPL typically settles transactions in around three to five seconds. Stellar’s Protocol 28, known as the Adapter upgrade, went live on Mainnet on September 16, 2026. It adds changes that make ledgers close faster and with less variance, and sampled Mainnet intervals now sit at about five seconds.

Adapter has arrived on Mainnet 🔌 https://t.co/wBznfbMPkx

— Stellar | Meridian Oct 28-29 (@StellarOrg) September 16, 2026

The workload also matters. A Stellar transaction can contain multiple operations, while Soroban execution introduces contract resource requirements. XRPL payment routing can involve multiple offers and liquidity sources.

In practical terms, both networks offer relatively fast settlement. The difference in actual payment confirmation time depends not only on the network itself but also on API response times, network conditions and how the application verifies the transaction before displaying it as successful.

Fees

A low network fee simplifies payment economics. The application’s fee logic still needs to account for network conditions and transaction requirements. While the two look remarkably similar at face value, both charging a fraction of a cent per transfer, they use completely different fee mechanics and network structures to manage those costs.

The fundamental cost structures depend on the native tokens: XRP for XRPL and lumens (XLM) for Stellar.

XRPL: Calculates fees in drops (1 XRP = 1,000,000 drops). Under standard conditions, the reference transaction cost is a 10 drop minimum. Under heavy load, the required fee escalates to price out spam. Complex actions like multi-signed transactions or finishing an escrow have higher base costs.

Stellar: Structures its transactions as a bundle of operations (up to 100 per transaction). Charges are a base fee per operation, measured in stroops (1 XLM = 10,000,000 stroops). During surge pricing, Stellar shifts to an auction where users specify a max_fee they are willing to pay per operation and transactions are ordered by the highest fee bid.

XRPL burns its transaction fees, so every transfer makes the overall supply of XRP slightly scarcer. Stellar collects fees into a designated pool.

Standard transaction fees are virtually unnoticeable on both networks. Account reserves are the larger up-front cost. To keep an account active on the XRPL, you must hold a base reserve, currently 1 XRP on Mainnet, plus 0.2 XRP for each object the account owns, such as a trust line or an escrow. Part of the reserve is recoverable if you delete the account. Stellar also locks a reserve for each account and for each entry it holds, such as a trustline.

A payment gateway processing hundreds of transfers should estimate fees against the intended transaction structure and monitor changing network conditions.

RPC infrastructure

The API methods determine how the application interacts with the ledger. The infrastructure determines how consistently those methods are available and how much historical data the service can retrieve. Chainstack supports each network with deployment options aligned with different workload requirements.

XRPL RPC

XRPL provides native JSON-RPC and WebSocket APIs for querying account state, estimating transaction fees, submitting signed transactions, inspecting liquidity and monitoring ledger activity. Chainstack provides managed RPC access to XRPL Mainnet and Testnet, allowing applications to use these native APIs through HTTPS and WebSocket endpoints.

Deploy an XRPL node in a few steps:

1. Open the Chainstack console and create a project.
2. Select XRP Ledger from the available blockchain protocols.
3. Choose Mainnet or Testnet, then select the deployment type according to the application’s infrastructure requirements.
4. Name the node, review the configuration and click Deploy Node.

Once deployment is complete, the endpoints are ready for API requests.

Network details

Mainnet

• Network name: XRP Ledger Mainnet
• Native currency: XRP
• RPC endpoint: https://xrpl-mainnet.core.chainstack.com

XRPL uses its own JSON-RPC and WebSocket APIs, which are incompatible with Ethereum’s eth_* interface. For EVM compatibility and Solidity smart contracts, the XRPL EVM Sidechain is a separate option.

The XRPL API exposes methods for querying account state, retrieving ledger data, submitting transactions, checking transaction results and interacting with the native decentralized exchange. The full method list is available in the official XRPL public API reference.

Core methods include:

• account_info: retrieves an account’s XRP balance, sequence number, and other account data
• account_tx: retrieves transaction history associated with an account
• ledger: retrieves information about a specific ledger, including its transactions when requested
• fee: returns current transaction-fee information, including fee estimates in drops of XRP
• submit: submits a transaction to the network. Production applications should generally submit a locally signed transaction using tx_blob
• tx: retrieves details and metadata for a transaction by its hash
• book_offers: retrieves offers for exchanging two assets through XRPL’s native order books
• ripple_path_find: finds potential payment paths between accounts, including paths involving currency conversions
• server_info: returns information about the connected server and its operating state

For example, account_info retrieves an account’s validated state and sequence number before a payment transaction is constructed. Setting ledger_index to validated ensures the response reflects a validated ledger rather than the current open ledger.

const response = await fetch("https://xrpl-mainnet.core.chainstack.com/<KEY>",
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      method: "account_info",
      params: [{
          account: "rG1QQv2nh2gr7RCZ1P8YYcBUKCCN633jCn",
          ledger_index: "validated"
        }]
    })
  });

const data = await response.json();
console.log(data.result);

The response includes account data and the ledger index used for the lookup.

For transaction submission, submit accepts a signed transaction blob. The response provides an initial engine result. Follow it with a tx lookup to verify the transaction’s final status in a validated ledger. This separates transaction submission from confirmation and gives payment systems a reliable basis for updating settlement records.

XRPL WebSocket connections allow applications to receive server-pushed updates without repeatedly issuing HTTP requests. This is useful for payment dashboards, exchange interfaces, wallet balance updates and services monitoring multiple accounts concurrently.

The subscribe method supports several monitoring options:

• accounts: receives transaction notifications for validated transactions affecting specified accounts
• accounts_proposed: receives notifications for proposed transactions before they are validated, in addition to validated transaction updates
• streams: ["ledger"]: receives notifications when a new validated ledger closes
• streams: ["transactions"]: receives transaction notifications from the server’s transaction stream

A persistent WebSocket connection can reduce repeated polling requests when monitoring live payment activity. For settlement-critical workflows, transaction notifications should still be checked for validation status and the engine result before a payment is marked complete.

Chainstack’s HTTPS and WebSocket access allows applications to combine request-response queries with real-time subscriptions. For compatible SDKs, development tools, and setup instructions, refer to the XRPL tooling documentation.

Stellar RPC

Stellar provides a native JSON-RPC API for querying ledger data, reading account and contract state, submitting transactions and retrieving transaction results. Chainstack supports Stellar Mainnet and Testnet through Global and Dedicated node deployments with HTTPS access to the network’s stellar-rpc methods.

Deploy a Stellar node in a few steps:

1. Open the Chainstack console and create a project.
2. Select Stellar from the available blockchain protocols.
3. Choose Mainnet or Testnet, then select Global or Dedicated deployment based on the application’s infrastructure requirements.
4. Name the node, review the configuration and click Deploy Node.

Once deployment is complete, the endpoint is ready to accept JSON-RPC requests.

Network details

Mainnet

• Network name: Stellar Mainnet
• Native currency: XLM
• RPC endpoint: https://stellar-mainnet.core.chainstack.com

Stellar RPC exposes methods for checking node health, querying ledger data, reading ledger entries, submitting transactions, monitoring transaction results and interacting with Soroban smart contracts. The full method list is available in the official Stellar RPC API reference.

Core methods include:

• getHealth: checks the RPC service’s health and reports ledger-retention information
• getNetwork: returns information about the connected Stellar network, including its passphrase
• getLatestLedger: retrieves the latest ledger sequence and related ledger information available through the RPC service
• getLedgers: retrieves ledger data, with pagination for processing multiple results
• getLedgerEntries: reads specific ledger entries, including account and contract state
• getFeeStats: returns recent fee statistics to help estimate appropriate transaction fees
• sendTransaction: submits a signed transaction envelope to the network
• getTransaction: retrieves the processing status and result for a transaction hash
• getTransactions: retrieves transaction records for a ledger range, with pagination
• simulateTransaction: simulates a transaction, providing resource estimates and transaction data required to prepare Soroban contract transactions
• getEvents: retrieves events emitted by Soroban contracts, with pagination

For example, getLatestLedger provides a reference point for the most recent ledger known to the RPC service. Applications can use the returned sequence number to track ledger progression and coordinate subsequent ledger queries.

const response = await fetch("https://stellar-mainnet.core.chainstack.com/<KEY>",
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      jsonrpc: "2.0",
      id: 1,
      method: "getLatestLedger",
      params: {}
    })
  });

const data = await response.json();
console.log(data.result);

The response contains information about the latest ledger available through the service, including its sequence number and protocol version.

The distinction from XRPL is operationally important: XRPL supports native WebSocket subscriptions for ledger and transaction streams, while Stellar RPC integrations on Chainstack use HTTPS requests for queries and confirmation checks. This affects how applications implement live payment updates and event processing.

For SDK setup, method examples, and integration guidance, refer to the Stellar tooling documentation.

How much history Chainstack nodes keep. XRPL Global Nodes are Extended nodes that hold roughly 750,000 to 1,500,000 recent ledgers, about 33 to 66 days at the Mainnet close rate. Requests below that window return lgrNotFound, so read complete_ledgers from server_info and use a full-history source for older data. Stellar Global Nodes keep a window longer than the stellar-rpc default of about 7 days, and getHealth reports it. Transaction and event queries are limited to that window. On Mainnet, getLedgers also serves ledgers older than the window. See the XRPL tooling and Stellar tooling docs.

Transaction lifecycle

An RPC response confirms that a request reached a particular stage, but it does not always establish the transaction’s final outcome. The payment service needs to track the transaction through the network and verify its final status before updating the application or notifying the user.

Let’s look at the stages a transaction goes through, how its status changes and when it can be considered final.

XRPL transaction flow

An XRPL payment typically looks like this:

1. Query account_info to retrieve the account sequence and validated state. To construct a transaction, first fetch the account’s current sequence number and verify its status on-chain.
2. Estimate network fees with fee. The method returns details directly in drops of XRP, broken down by base_fee, median_fee and open_ledger_fee.
3. Define parameters like TransactionType: "Payment" and sign the transaction. This is done locally and offline using your private key via an SDK (for example xrpl.js or xrpl-py) to protect your credentials.
4. Submit the transaction with submit, in one of two modes:

• Sign-and-Submit: Passes an unsigned transaction payload and secret key directly to the node. The node signs it and broadcasts it. Best suited for testing or controlled private-node environments.
• Submit-Only: Accepts a pre-signed cryptographic string (tx_blob). No keys are exposed to the node. This is the standard production method for security-first architectures and public endpoints.

1. Confirm the result in one of two ways:

• Polling (tx): Repeatedly making HTTP POST requests for a specific hash with "validated": true until the node finds it. Ideal for simple cron scripts, batch processing or environments restricted from persistent WebSockets.
• Streaming (subscribe): Opening a persistent WebSocket (wss://) and listening to the transactions stream. You filter incoming logs for your target hash. Ideal for high-throughput apps, front-end wallets and user interfaces needing real-time feedback without excessive requests.

Interpret the transaction status:

• Provisional success: tesSUCCESS (provisional): The transaction is well-formed and successfully applied to the local server’s current open ledger. This is not final yet; it could theoretically still fail if the network state changes before consensus.
• Final success: tesSUCCESS (validated): The transaction has been successfully included in a validated ledger. Its changes are permanent and immutable.
• Local failure: tel: A local error. The transaction was rejected by the node you submitted it to and was not broadcast to the network.
• Malformed failure: tem: The transaction is structurally broken or invalid. It is rejected immediately and never included in the ledger.
• Retriable failure: ter: The transaction cannot be applied right now, but it might succeed in a later ledger round. Check the specific result code before retrying.
• Final failure: tec: The transaction failed during consensus evaluation. It is permanently recorded in the validated ledger and charges an XRP fee to prevent network spam.

Stellar transaction flow

A Stellar payment typically follows this sequence:

1. Retrieve the account state: Use the Stellar RPC API (getLedgerEntries, which the JavaScript SDK wraps as server.getAccount) to retrieve the source account’s sequence number and current state. The sequence number determines the transaction’s ordering and must be handled correctly when preparing multiple transactions from the same account.
2. Estimate fees: Query getFeeStats to inspect recent fee conditions and determine an appropriate transaction fee. Standard Stellar transactions pay fees in XLM. Soroban transactions also account for resource fees associated with smart-contract execution.
3. Simulate Soroban transactions when required: Transactions that invoke Soroban smart contracts require additional preparation. Call simulateTransaction to estimate resource requirements and obtain transaction data needed to prepare the transaction before signing and submission.
4. Submit the signed transaction: Send the signed transaction envelope to Stellar RPC using sendTransaction. The response indicates whether the submission was accepted for processing, rejected or already known to the server. An accepted submission is not proof of final transaction success.
5. Verify ledger inclusion: Query getTransaction with the transaction hash to retrieve its processing status and result. If the status is NOT_FOUND, the transaction may still be pending, may have expired from the submission queue or may never have reached the network. Retry checks with an appropriate backoff rather than treating the first missing result as definitive failure.

Monitor getTransaction status:

• Successful (SUCCESS): The transaction was included in a ledger successfully. Persist the transaction hash and result for payment reconciliation.
• Failed (FAILED): The transaction reached a final result but failed. Inspect the returned result details to identify the transaction or operation error before deciding whether to rebuild and resubmit it.
• Not found (NOT_FOUND): The RPC server has no transaction result available for the supplied hash. Check again and investigate submission or transaction-expiration conditions before creating a replacement.

Handle sendTransaction status:

• Pending (PENDING): The transaction was accepted for processing. Confirm the outcome with getTransaction.
• Duplicate (DUPLICATE): The transaction has already been submitted. Query its hash to determine whether it was successfully included in a ledger.
• Temporary submission issue (TRY_AGAIN_LATER): The server could not process the submission at that moment. Retry according to the SDK or provider’s guidance while avoiding duplicate or conflicting submissions.
• Error (ERROR): The submission was rejected. Inspect the returned error result before rebuilding the transaction.

Ecosystem

Network capabilities become more tangible through deployed applications.

MoneyGram 🤝 @StellarOrg

We’re extending our five-year partnership with SDF, continuing to turn stablecoin potential into real-world utility and financial inclusion.

Building on our success in Colombia, the MoneyGram app’s stablecoin balance is now live in El Salvador.

Read… pic.twitter.com/9lbvyZlBeJ

— MoneyGram (@MoneyGram) April 22, 2026

MoneyGram’s Stellar integration connects digital wallets to cash-to-crypto deposit and withdrawal services. Its MoneyGram Ramps integration provides access to off-ramps across more than 170 countries and about 475,000 locations.

Franklin Templeton, with $1.83 trillion under management, keeps 64.97% of its $680.07M BENJI money market fund on Stellar. That is more than the fund's seven other networks combined.@StellarOrg pic.twitter.com/LvH7X2xW0W

— MSB Intel (@MSBIntel) October 21, 2026

Franklin Templeton’s Benji platform provides another example. Its OnChain U.S. Government Money Fund uses Stellar as the public blockchain system for recording fund-share ownership and processing transactions. The fund’s Stellar-based BENJI assets were reported at approximately $605 million as of October 6, 2026.

Stellar is also exploring internet-native payments through x402, which enables applications and AI agents to pay for API resources using stablecoins.

XRPL’s native payment features suit services that require asset transfers, currency conversion, and exchange functionality in the ledger.

🚀 Frii Pay x XRPL = Unlocking the Real Future of Payments

We’re honoured to be featured on the @XRPLF blog! 🙌

Spotlighting how we’re redefining payments with:

⚡ Instant, stablecoin settlements
💳 Compatibility with millions of existing smart POS terminals
🌍…

— Frii World (@FriiWorld) July 24, 2025

Frii Pay, a crypto payment solution focused on merchants and consumers, shows the use of the XRP Ledger for payment settlement and digital-asset payments.

For wallet and exchange developers, native payment routing and order-book queries provide direct access to ledger-level financial functions.

Which is better for payments?

The right choice follows the product’s financial requirements, execution model and integration environment.

Metric / Feature	XRP Ledger (XRPL)	Stellar (XLM)
Primary target market	B2B, institutional, high-value wholesale	P2P, micropayments, retail remittances
Transaction speed	About 3–5 seconds	About 5 seconds
Throughput (project-reported)	~1,500 TPS	~1,000 TPS
Standard payment fee	0.00001 XRP (10 drops), burned	0.00001 XLM (100 stroops), sent to a fee pool
Smart contract capability	Non-Turing-complete native primitives (Escrow, Checks, Payment Channels). Hooks run on Xahau, not XRPL Mainnet	Soroban (Rust-based, Turing-complete WebAssembly engine)
Smart contract fee	N/A (logic executes via native transaction objects)	Resource-based fees for contract execution
SDK ecosystem	TypeScript/JavaScript, Python, Java, C++	JavaScript/TypeScript, Python, Go, Rust, Java, C#
Liquidity and routing	Native DEX + auto-bridging (XRP as an intermediate currency)	Native DEX + path payments (multi-asset hops, atomic)
Fiat on/off ramps	Institutional partners, Ripple Payments (formerly RippleNet and ODL)	Native anchor network (for example, MoneyGram cash-to-crypto integration)
Consensus philosophy	Curation-based trust (Unique Node Lists)	Open-ended web of trust (federated quorum slices)

XRPL

• API-first banking primitives: Pass pre-built transaction types (like EscrowCreate, PaymentChannelCreate or CheckCreate) directly to the ledger.
• Auto-bridging: Designed for cross-border wholesale banking. If a user transfers USD to a receiver wanting EUR, the ledger checks whether routing USD → XRP → EUR provides better liquidity and rates than a direct USD/EUR order book pair. It acts as an automated interbank bridge.
• XRPL reserves: To prevent spam and ledger bloat, XRPL uses an account reserve. An active account must hold a base reserve (currently 1 XRP on Mainnet), and each object it owns, such as an escrow or a trust line, adds an owner reserve (currently 0.2 XRP). This adds some friction when onboarding retail users, as someone must fund these reserves.

The upside: Stability and immediate security. You do not need expensive smart contract audits because the core logic is hardcoded into the protocol.

The downside: Bounded logic. If your payment workflow requires custom compliance (for example, “only release this payment if the receiver holds a specific KYC token”), you must build and host that validation logic on your own backend rather than on-chain.

Build on XRPL if you are developing:

• Wholesale B2B settlement rails moving heavy capital between corporate entities.
• Applications requiring predictable, hardcoded security primitives (Escrows, Checks, Payment Channels) without the risk of smart contract exploits.
• Systems that benefit from deep institutional liquidity and highly vetted, corporate-friendly validator nodes (Unique Node Lists).

Stellar

• Modular cloud with smart contracts: Stellar gives you standard payment endpoints but adds Soroban, a robust, Rust-based smart contract environment.
• Path payments: Optimized for retail consumer experiences. A single PathPayment operation allows developers to execute up to 5 multi-asset hops (for example, user sends USD → converts to XLM → converts to EUR → arrives as local digital fiat) behind the scenes in a single atomic transaction.
• Stroops and anchors: Stellar uses a base fee of 100 stroops (0.00001 XLM) per operation. It also features a native anchor network, allowing fintech applications to plug directly into regulated financial entities globally (like MoneyGram) to handle physical cash-in and cash-out services without building custom banking rails from scratch.

The upside: Architectural freedom. You can deploy custom on-chain compliance workflows, decentralized finance (DeFi) liquidity pools and automated, multi-signature corporate governance systems.

The downside: Complexity. Developers must manage smart contract security audits, code optimization and Stellar’s ledger space rent (stored data eventually expires and is archived unless the application pays ongoing maintenance fees).

Build on Stellar if you are developing:

• Consumer-facing fintech apps, P2P remittance wallets or micro-payment platforms.
• Workflows that require custom on-chain business logic, automated compliance rules or dynamic multi-sig structures written in Rust/Wasm.
• Systems that need to bridge digital assets directly to real-world cash locations using a global, standardized anchor framework.

Builder tools

The available SDKs, test environments, explorers, and infrastructure tooling influence development speed and operational complexity.

• xrpl.js: JavaScript and TypeScript library for XRPL transaction construction, signing, ledger queries and real-time subscriptions
• xrpl-py: Python library for building XRPL payment services, automating transactions and integrating blockchain functionality into applications
• XRPL API reference: Comprehensive reference for XRPL methods, transaction parameters, request formats and response structures
• Stellar JavaScript SDK: JavaScript library for building, signing and simulating Stellar transactions and integrating blockchain functionality into applications
• Stellar Lab: Interactive development environment for exploring Stellar accounts, testing transactions and experimenting with RPC calls
• Stellar developer documentation: Technical resources for Stellar payments, Soroban smart contracts, RPC methods and network upgrades
• XRPL tooling: Managed XRPL RPC infrastructure, SDK integration guides and examples for building and deploying blockchain applications
• Stellar tooling: Managed Stellar RPC infrastructure, method examples and blockchain history monitoring for application development

Conclusion

A successful payment application depends on more than quick settlement and inexpensive transactions. Account state, asset routing, transaction status, historical data and operational monitoring determine how reliably the application handles real payments.

XRPL provides native financial operations, currency routing, order books, and WebSocket subscriptions. Stellar combines native payment infrastructure with Soroban smart contracts, transaction simulation and an ecosystem focused on stablecoins, remittances and tokenized assets.

The most useful next step is to implement the same representative payment workflow on each Testnet. Measure request latency, settlement time, fee behavior and transaction-history availability. Test interrupted submissions and confirm that the application recovers without initiating duplicate payments.

Chainstack provides the managed RPC access needed to run these tests and move toward production. Explore XRPL RPC infrastructure, Stellar RPC infrastructure and the XRPL and Stellar tooling guides to begin building against the network that fits the payment workflow.

Frequently asked questions

Related reading

• What Is XRP Ledger? Consensus, RLUSD, and RPC Explained
• What Is Stellar? Quorum Slices, Soroban, and RPC Access
• x402 protocol: Architecture and payment flow for AI Agents
• Chainstack Introduces Stellar Support
• XRP Ledger tooling and Stellar tooling (Chainstack docs)