XRPL Public Servers Compared
Every XRPL application needs a server to connect to. Here is a comparison of all public XRP Ledger endpoints -- their capabilities, rate limits, and when to use each one.
Available public servers
Several organizations run public XRPL servers that developers can connect to for free. Each has different characteristics:
s1.ripple.com and s2.ripple.com
Operated by: Ripple. Type: Clio (optimized read-only nodes).
These are the most commonly used public endpoints. They run Clio, a specialized XRPL server optimized for API queries. They have full ledger history and support all read methods. Rate limits are relatively strict -- suitable for development and low-volume production, but not for applications making hundreds of requests per second.
Pros: Reliable, full history, operated by Ripple. Cons: Rate limited, shared with all developers globally, no SLA.
xrplcluster.com
Operated by: XRPL Community. Type: rippled (full node).
A community-run cluster of rippled servers. It supports both read and write operations (transaction submission). Full history available. More generous rate limits than Ripple's servers. Used widely by community projects and tools.
Pros: Full history, supports submit, community operated. Cons: No guaranteed uptime, shared resource.
xrpl.link
Operated by: XRPL Community. Type: rippled.
Another community rippled endpoint with full history. Similar capabilities to xrplcluster.com. Provides an alternative connection point for redundancy.
honeycluster.io
Operated by: Community. Type: Clio.
A Clio-based public server. Good for read queries with reasonable rate limits. Full history available.
XRPL Stream (s1.xrpl.stream)
Operated by: XRPL Stream. Type: 21-node distributed edge network (rippled + Clio + Evernode relay layer).
Unlike single-server endpoints, XRPL Stream runs a distributed network of 21 nodes across 9 regions globally. Requests are routed to the nearest healthy node automatically. Features include:
- Full history: Every transaction from ledger 32,570 (January 2013)
- Dedicated endpoints: Your own API key with guaranteed rate limits
- Global distribution: Sub-50ms latency from most locations
- All networks: Mainnet, testnet, and devnet on one endpoint
- WebSocket and JSON-RPC: Both protocols supported
- Free tier: 15 req/s, 1M monthly credits at no cost
Pros: Dedicated endpoints, global distribution, guaranteed rate limits, free tier. Cons: Higher tiers are paid (starting at $29/mo).
Which server should you use
- Quick testing and prototyping: s1.ripple.com or s2.ripple.com -- easy, no signup needed
- Community projects: xrplcluster.com -- generous limits, supports submit
- Production applications: XRPL Stream -- dedicated endpoints, reliability guarantees, global distribution
- Redundancy: Use multiple endpoints as fallbacks. XRPL Stream handles this internally with 21 nodes.
Rate limits comparison
Public shared servers do not publish official rate limits, but community testing shows approximate thresholds:
- s1/s2.ripple.com: Approximately 25-30 concurrent requests before load warnings
- xrplcluster.com: Higher tolerance, approximately 80-100 req/s for short bursts
- honeycluster.io: Approximately 40-50 concurrent requests
- XRPL Stream (free): 15 req/s guaranteed, no shared contention
- XRPL Stream (pro): 150 req/s guaranteed
Connection examples
All public servers accept the same XRPL protocol. You just change the URL:
- Ripple: wss://s1.ripple.com or wss://s2.ripple.com
- Cluster: wss://xrplcluster.com
- XRPL Stream: wss://s1.xrpl.stream/e/YOUR_TOKEN
Any XRPL client library (xrpl.js, xrpl-py, xrpl4j) works with all of these. Just swap the URL.