Ledger Structure and the Close Process
How the XRP Ledger organizes state and history into successive, immutable ledger versions.
Ledger versions
The XRPL's history is organized as a sequence of numbered ledger versions, each one representing a complete snapshot of account balances and object state at a point in time, plus the list of transactions that were applied to produce it from the previous version. A new ledger version is produced roughly every 3–5 seconds via the consensus process.
What's inside a ledger version
Each closed ledger version contains:
- A ledger header, including its sequence number, a hash referencing the previous ledger, and a timestamp.
- A state tree, containing every account, its balance, its owned objects (trust lines, offers, escrows, and so on), encoded in a Merkle-like tree structure so that any piece of state can be cryptographically proven.
- A transaction tree, listing every transaction applied in that ledger version, also in a Merkle-like structure.
The close process
"Closing" a ledger is the act of the network reaching consensus on the next version and finalizing it. Once closed:
- The transaction order within that ledger is fixed and cannot be changed.
- The resulting account balances and state are final.
- The next ledger version begins building on top of it.
Because finality happens at ledger close rather than probabilistically over many subsequent blocks, there is no equivalent to waiting for "confirmations" the way there is on Bitcoin — a transaction included in a closed ledger is done.
Sequence numbers and the "last ledger sequence" safety feature
Every account has a sequence number that increments with each transaction it submits, preventing replay or reordering of that account's own transactions. Transactions can also specify a LastLedgerSequence value, after which they are automatically considered expired and will never be applied — this makes it possible to know with certainty that a transaction has either succeeded or definitively failed, rather than being stuck in limbo.
Full history vs. current state
Running a full-history XRPL server requires storing every ledger version back to genesis, which is data-intensive; most validators and API-serving nodes instead keep a recent rolling window of ledger history (plus the current state) unless specifically configured as a full-history node, with dedicated full-history servers and third-party archives available for historical queries.