Every transaction on the XRP Ledger is permanent. Once consensus closes a ledger version, that data is part of the chain's immutable record. But here is the catch: most nodes do not actually keep all of it. If your application needs to look further back than the last few thousand ledgers, you need a full-history node — and understanding what that means is critical for anyone building serious infrastructure on the XRPL.

A full-history node is an XRP Ledger server that stores every ledger version and every transaction from the network's genesis (ledger #32570, the earliest available) all the way through to the present. That includes every payment, every offer, every trust line change, every escrow, and every NFT mint — billions of transactions spanning over a decade of network activity.

By contrast, a default rippled node only retains a rolling window of recent ledger history, typically the last 256 to several thousand ledger versions. Once a ledger ages out of that window, it is deleted from the local store. The node still validates and forwards new transactions perfectly well, but it cannot answer questions about what happened last month, let alone last year.

The distinction between full-history and pruned (default) nodes comes down to what queries you can serve. Here is a comparison:

A pruned node is perfectly adequate for real-time operations — submitting payments, subscribing to live transaction streams, or checking current account balances. But the moment you need to look backward beyond the retention window, those requests will fail with a lgrNotFound or txnNotFound error.

Running a full-history node is not trivial. The XRP Ledger has been operational since 2012, and the cumulative dataset is substantial:

• •
  Raw rippled full history: Requires upward of 12-18 TB of NuDB or RocksDB storage, depending on configuration and compaction.
• •
  Clio-based full history: Uses Apache Cassandra or ScyllaDB as the storage backend, which can reduce space to roughly 4-8 TB due to more efficient data representation, but requires a distributed database cluster to operate.
• •
  Hardware: High IOPS SSD or NVMe storage is essential. Spinning disks cannot keep up with the random read patterns of ledger queries.
• •
  Initial sync: Downloading and verifying the complete history from the peer network can take weeks to months, depending on bandwidth and peer availability.
• •
  Ongoing growth: The ledger closes a new version every 3-5 seconds. Storage requirements grow continuously, adding hundreds of gigabytes per year.

Not every application needs full history. But when you do need it, there is no substitute. Here are the scenarios where full-history access is essential:

Building dashboards that show historical trends — transaction volume over time, DEX trading activity, NFT minting patterns — requires querying ledger data spanning months or years. A pruned node simply cannot provide this data.

Regulated entities need to produce transaction records on demand. If a compliance team asks for proof of a payment from six months ago, you need to retrieve the exact transaction, its metadata, and the ledger it was validated in.

Tracing the flow of funds across accounts, identifying wash trading patterns, or investigating suspicious activity all require the ability to walk transaction chains backward through time.

Some applications need to know what an account's balance, trust lines, or offers looked like at a specific point in the past. The ledger_entry and account_info methods accept a ledger_index parameter, but that only works if the node has that ledger.

Services that let users search for any transaction by hash, or look up the complete history of any account, are inherently full-history workloads.

Here is a practical example. Suppose you want to retrieve all transactions for an account going back to its creation using the account_tx method:

Json
{
  "method": "account_tx",
  "params": [
    {
      "account": "rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe",
      "ledger_index_min": -1,
      "ledger_index_max": -1,
      "limit": 20,
      "forward": true
    }
  ]
}

Setting ledger_index_min and ledger_index_max to -1 tells the server to search across all available history. On a pruned node, "all available" might mean the last few minutes. On a full-history node, it means every transaction that account has ever sent or received.

Similarly, retrieving a specific historical transaction by hash:

Json
{
  "method": "tx",
  "params": [
    {
      "transaction": "E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7",
      "binary": false
    }
  ]
}

If this transaction was validated in a ledger from 2019, only a full-history node can return it.

You can also inspect the state of any object at a historical point in time:

Json
{
  "method": "account_info",
  "params": [
    {
      "account": "rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe",
      "ledger_index": 75000000
    }
  ]
}

This returns the account's balance and settings as they existed at ledger 75,000,000. Without full history, the server rejects this request outright.

Beyond the raw cost, operating a full-history node introduces significant complexity:

• •
  Resyncing after downtime: If your node goes offline and misses ledgers, backfilling the gap requires fetching history from peers — a slow and unreliable process.
• •
  Database maintenance: Multi-terabyte databases require regular compaction, backup strategies, and careful capacity planning.
• •
  Monitoring and alerting: You need to detect and respond to issues like storage exhaustion, replication lag, and peer connectivity problems.
• •
  Redundancy: A single full-history node is a single point of failure. Production workloads need at least two, ideally behind a load balancer with health checks.

For most teams, the operational burden of maintaining full-history infrastructure is a distraction from their core product.

This is exactly the problem Honeycluster was built to solve. Our infrastructure provides complete XRPL history from ledger 32570 to the present, served through both Clio and rippled nodes distributed across multiple regions.

• •
  Full dataset, zero maintenance: Access the entire XRP Ledger history without managing terabytes of storage or database clusters.
• •
  Sub-50ms response times: Our optimized Clio backend delivers fast query performance even for deep historical lookups.
• •
  99.9% uptime: Redundant nodes, automated failover, and 24/7 monitoring keep the service reliable.
• •
  WebSocket and JSON-RPC: Connect using whichever protocol fits your architecture.

If your application only submits transactions and reads current state, a pruned node or standard public endpoint works fine. You need full-history access when:

• •
  You query account_tx with wide ledger ranges
• •
  You look up transactions by hash that may be old
• •
  You inspect historical account state at past ledger versions
• •
  You run analytics over weeks, months, or years of data
• •
  You have compliance requirements that mandate transaction retrieval

For many production applications, the answer is a mix — real-time operations against fast nodes, with full-history access available for the queries that need it.

Honeycluster provides full-history XRPL access as a public service. Connect to our endpoints and start querying the complete ledger history today. Visit honeycluster.io to explore our documentation, grab your API endpoint, and see what you can build when history is not a constraint.