A claim circulating on social media that XRP Ledger RPC nodes can process 30,000 messages per second sounds impressive. The problem is that verified benchmarks don’t actually support that number.
What the actual numbers show
XRPL Labs, one of the primary infrastructure developers for the XRP Ledger, has been focused on latency rather than raw message throughput. Their public endpoint currently posts a p50 latency of approximately 371 milliseconds for ledger_current calls, making it the lowest-latency option among public XRPL servers.
Public server clusters have been observed handling over 10,000 reads per second during peak usage periods. That’s a solid number for blockchain infrastructure, but it’s a third of the claimed 30,000 figure.
GetBlock, another infrastructure provider, claims its XRPL nodes can process upward of 1,000 requests per second without rate limitations on dedicated setups.
The closest anyone has gotten to the headline figure involves validator messaging, which is a fundamentally different category of traffic. Validator message handling has recorded averages around 3,260 messages per second under optimal testing conditions, with peaks above 6,100 messages per second. But validator-to-validator consensus traffic and client-server RPC requests are apples and oranges.
In production environments, the XRPL network’s actual transaction throughput has historically ranged between 100 and 230 transactions per second during daily peaks. Theoretical maximums in controlled testing settings have reached over 1,500 TPS, which is still an order of magnitude below the 30,000 figure being tossed around.
Why the gap matters
The distinction between messages per second and transactions per second is important here. An RPC node might handle thousands of read requests (balance lookups, ledger queries, subscription updates) that never result in a transaction being written to the ledger. Counting all inbound messages, including pings, status checks, and failed requests, will always produce a bigger number than counting actual processed transactions.
For XRP specifically, this matters because Ripple has been positioning the XRPL as infrastructure for institutional payment processing and decentralized exchange activity. Both use cases require predictable, verifiable performance under sustained load, not theoretical peaks achieved in lab conditions.
Where XRPL infrastructure is actually headed
The 371ms p50 latency figure represents meaningful progress for a decentralized network handling cryptographic verification on every request. A payment network that consistently processes requests in under 400 milliseconds is more useful to a bank or payment provider than one that claims sky-high throughput but delivers unpredictable response times.
The infrastructure stack is also diversifying. Multiple providers now offer dedicated XRPL node services, which spreads the load and reduces single points of failure. The 10,000+ reads per second observed on public clusters suggests the network can handle significant query volume even before dedicated enterprise setups enter the picture.