Full-History Servers and Clio
How the XRP Ledger's complete historical record is stored and served, and why most nodes don't keep all of it.
Why not every node stores everything
As mentioned in Ledger Structure and the Close Process, the XRP Ledger has been producing a new ledger version roughly every 3–5 seconds since 2012 — accumulating a very large volume of historical data over more than a decade. Storing the complete history back to genesis is resource-intensive, so most rippled servers are instead configured to keep only a recent rolling window of ledger history sufficient for normal operation (validating current transactions, serving recent account and transaction lookups), rather than the full historical archive.
Full-history servers
A full-history server is a rippled node specifically configured to retain the complete ledger history from genesis onward, rather than just a recent window. These are run by a smaller number of operators — often specifically to support block explorers, research, compliance/audit tooling, or other applications that genuinely need to query arbitrarily old transactions and account states.
Clio
Clio is a specialized server implementation, separate from the core rippled validator software, purpose-built for serving historical XRPL data efficiently at scale. Rather than a validator that also happens to store history, Clio is optimized specifically as a read-heavy API server: it ingests validated ledger data (often from a full-history rippled node) and serves it to applications through the same familiar API interface, but with infrastructure specifically tuned for high-volume historical queries rather than for participating in consensus.
Why separating these roles makes sense
Splitting "producing and validating new ledgers" (the core job of a validator) from "efficiently serving large volumes of historical data to applications" (Clio's specialty) lets each piece of infrastructure be optimized for its actual job, rather than forcing a single piece of software to be good at both a latency-sensitive consensus role and a storage- and query-heavy archival role simultaneously.
Why this matters for developers and researchers
Anyone building an application that needs to query old transaction history — a tax-reporting tool, a compliance/audit system, a historical analytics dashboard, or a research project studying the ledger's activity over time — will generally rely on a full-history source (whether a self-hosted full-history node, a Clio deployment, or a third-party historical data API) rather than a standard, recent-history-only public node. See Developer Tools & SDKs for the broader toolkit available for building on the XRPL.