Back to Blog

XRPL Full History Node

A full history node stores every transaction on the XRP Ledger since January 2013. That is over 100 million ledgers and 2.8 billion transactions. Here is why it matters, what it costs, and how to access it without running your own.

What is full history

The XRP Ledger has been running continuously since ledger 32,570 in January 2013. A full history node stores every single ledger and every transaction since that first public ledger. This means you can query any account balance at any point in time, look up any transaction ever made, and verify the complete state of the ledger at any historical moment.

Most XRPL nodes do not keep full history. A typical stock node stores only recent ledgers -- anywhere from a few days to a few weeks. Once a ledger falls outside the retention window, the data is pruned. These nodes work fine for current-state queries but cannot answer historical questions.

Why full history matters

Several critical use cases require access to the complete ledger history:

  • Analytics and research: Analyzing trading patterns, token distribution, and network growth requires historical data spanning years
  • Compliance and auditing: Financial institutions need to trace the complete history of accounts and transactions for regulatory requirements
  • Tax reporting: Calculating capital gains requires knowing the exact price and time of every trade, potentially going back years
  • Token analysis: Understanding a token's full distribution history -- who received tokens, when, and from whom
  • Forensics: Tracing the flow of funds through multiple accounts over time
  • Application data: Apps that show complete account history, not just recent transactions

The storage challenge

Full XRPL history currently requires approximately 39 TB of storage and growing by 1-2 TB per month. At NVMe SSD prices, that is $3,000-5,000 in storage hardware alone, plus the server costs to run it.

Beyond raw storage, a full history node needs:

  • 64+ GB RAM for efficient query serving
  • 8+ CPU cores for processing concurrent requests
  • High-bandwidth networking for serving query results
  • Ongoing maintenance including software upgrades, storage expansion, and monitoring

Most organizations find it impractical to run their own full history node. The cost and complexity far exceed what a managed API service costs.

Full history vs partial history

When you query a partial-history node for data it does not have, you get one of these responses:

  • account_tx returns incomplete data: Only recent transactions, missing the full history. The ledger_index_min field shows where history starts.
  • ledger returns lgrNotFound: The requested ledger has been pruned.
  • account_info at historical ledger fails: Cannot look up past account state.

This is a silent data quality problem. Your application might work correctly for recent accounts but return incomplete results for older ones. You cannot tell from the response alone whether you received all the data or just a subset.

Clio vs rippled for history

There are two types of XRPL server software:

  • rippled: The reference server. Stores ledger data in RocksDB. Can maintain full history but the 39 TB requirement is challenging.
  • Clio: An optimized read-only server. Stores data in Cassandra/ScyllaDB. Designed for high-throughput API serving. Can maintain full history more efficiently through its distributed database backend.

Ripple's public servers (s1.ripple.com, s2.ripple.com) run Clio with full history. XRPL Stream uses both rippled and Clio nodes for different query types, routing each request to the node best suited to answer it.

How XRPL Stream provides full history

XRPL Stream runs a 21-node distributed network that maintains complete XRPL history from ledger 32,570 to present. Instead of one massive full history node, the data is distributed across multiple nodes with range-based sharding and peer-to-peer cache sharing.

Every API query -- whether it asks for a transaction from 2013 or a balance from 5 seconds ago -- is routed to a node that has the data. The routing is automatic and transparent. You get one endpoint that serves the full history of the XRP Ledger.

  • account_tx: Returns complete transaction history from genesis. ledger_index_min is always 32,570.
  • tx: Look up any transaction by hash, no matter how old.
  • ledger: Query any historical ledger, including state and transactions.
  • account_info at historical ledger: See any account's state at any point in time.

Getting started

Sign up for a free XRPL Stream account to get instant access to full XRPL history. No server to run, no storage to manage, no software to maintain. Free tier includes 15 req/s and 1M monthly credits.

Get Full History Access Compare Servers