Every ledger version has a unique header that describes the contents. You can look up a ledger's header information with the ledger method. The contents of the ledger header are as follows:
|Field||JSON Type||Internal Type||Description|
||String||UInt32||The sequence number of the ledger. Some API methods display this as a quoted integer; some display it as a native JSON number.|
||String||Hash256||The SHA-512Half of this ledger version. This serves as a unique identifier for this ledger and all its contents.|
||String||Hash256||The SHA-512Half of this ledger's state tree information.|
||Number||UInt32||The approximate time this ledger closed, as the number of seconds since the Ripple Epoch of 2000-01-01 00:00:00. This value is rounded based on the
||Boolean||bool||If true, this ledger version is no longer accepting new transactions. (However, unless this ledger version is validated, it might be replaced by a different ledger version with a different set of transactions.)|
||String||UInt64||The total number of drops of XRP owned by accounts in the ledger. This omits XRP that has been destroyed by transaction fees. The actual amount of XRP in circulation is lower because some accounts are "black holes" whose keys are not known by anyone.|
||String||Hash256||The SHA-512Half of the transactions included in this ledger.|
||Number||Uint8||An integer in the range [2,120] indicating the maximum number of seconds by which the
||(Omitted)||UInt8||A bit-map of flags relating to the closing of this ledger.|
A ledger index is a 32-bit unsigned integer used to identify a ledger. The ledger index is also known as the ledger's sequence number. The very first ledger was ledger index 1, and each new ledger has a ledger index 1 higher than that of the ledger immediately before it.
The ledger index indicates the order of the ledgers; the Hash value identifies the exact contents of the ledger. Two ledgers with the same hash are always the same. For validated ledgers, hash values and sequence numbers are equally valid and correlate 1:1. However, this is not true for in-progress ledgers:
- Two different
rippledservers may have different contents for a current ledger with the same ledger index, due to latency in propagating transactions throughout the network.
- There may be multiple closed ledger versions competing to be validated by consensus. These ledger versions have the same sequence number but different contents (and different hashes). Only one of these closed ledgers can become validated.
- A current ledger's contents change over time, which would cause its hash to change, even though its ledger index number stays the same. The hash of a ledger is not calculated until the ledger is closed.
The ledger has only one flag defined for closeFlags: sLCF_NoConsensusTime (value
1). If this flag is enabled, it means that validators had different close times for the ledger, but built otherwise the same ledger, so they declared consensus while "agreeing to disagree" on the close time. In this case, the consensus ledger version contains a
close_time value that is 1 second after that of the previous ledger. (In this case, there is no official close time, but the actual real-world close time is probably 3-6 seconds later than the specified
closeFlags field is not included in any JSON representations of a ledger, but is included in the binary representation of a ledger, and is one of the fields that determine the ledger's hash.
For ledger basics, see Ledgers.