XRPL Nodes Guide

Node types

The XRP Ledger network consists of several types of nodes, each serving a different purpose:

• Validator nodes: Participate in the consensus process. They propose and vote on which transactions to include in each ledger. The XRPL uses a unique consensus protocol (not proof-of-work or proof-of-stake) where trusted validators agree on transaction ordering. There are roughly 150+ validators on the network, with about 35 on Ripple's recommended Unique Node List (UNL).
• Stock nodes: Track the current state of the ledger and serve API requests. They do not participate in consensus but maintain a connection to the network and process incoming transactions. Most developers interact with stock nodes.
• Full history nodes: Stock nodes that store the complete ledger history from genesis (ledger 32,570 in January 2013). These require significant storage -- currently around 39 TB and growing. Most stock nodes only keep recent history (days or weeks).
• Clio nodes: Specialized read-only nodes optimized for API serving. Clio stores data in Cassandra/ScyllaDB and is designed for high-throughput query workloads. Ripple's public servers (s1.ripple.com, s2.ripple.com) run Clio.

Hardware requirements

Running your own XRPL node requires dedicated hardware:

• Stock node (recent history): 8 CPU cores, 32 GB RAM, 500 GB SSD. Stores approximately 2-4 weeks of ledger history.
• Full history node: 8+ CPU cores, 64+ GB RAM, 39+ TB NVMe storage. The storage requirement grows by roughly 1-2 TB per month.
• Validator: Same as stock node, plus reliable uptime and network connectivity. Validators should be professionally hosted with redundant infrastructure.

The storage requirement for full history is the biggest barrier. At 39 TB, NVMe storage alone costs $3,000-5,000+ depending on hosting provider. This is why most developers use managed RPC providers instead of running their own full history node.

Public RPC endpoints

Several organizations provide free public access to XRPL nodes:

• s1.ripple.com / s2.ripple.com: Ripple's public Clio servers. Full history, but rate limited. Good for development, not suitable for production workloads.
• xrplcluster.com: Community-run rippled cluster. Full history, relatively generous rate limits.
• xrpl.link: Another community rippled endpoint. Full history.
• XRPL Stream (s1.xrpl.stream): Managed 21-node edge network. Full history, dedicated endpoints, guaranteed rate limits, global distribution.

Connecting via WebSocket

The primary way to interact with XRPL nodes is through WebSocket connections. This allows bidirectional communication -- you can send requests and also subscribe to real-time events like ledger closes and transaction notifications. Most XRPL client libraries (xrpl.js, xrpl-py, xrpl4j) use WebSocket under the hood.

JSON-RPC over HTTP

Nodes also accept JSON-RPC requests over HTTP POST. This is simpler for one-off queries -- you send a request and get a response. No persistent connection needed. XRPL Stream supports both WebSocket and JSON-RPC on the same endpoint.

Mainnet, testnet, and devnet

The XRPL has three networks:

• Mainnet: The production network where real XRP transactions happen.
• Testnet: A parallel network for testing. Free test XRP is available from faucets. Testnet mirrors mainnet features and is reset periodically.
• Devnet: An experimental network where new amendments and features are tested before reaching testnet or mainnet.

Why use a managed provider

Running your own XRPL node is viable for validators and organizations that need complete control. But for API access, a managed provider like XRPL Stream offers significant advantages:

• No infrastructure to maintain: No servers, no storage, no upgrades
• Full history included: Every transaction since 2013, no 39 TB storage bill
• Global distribution: 21 nodes across 9 regions, queries served from nearest node
• Guaranteed uptime: Redundant infrastructure with automatic failover
• Free tier available: Start building immediately, scale when needed