📂 Separate ledgers page into entries and headers

docs/build/smart-contracts/example-contracts/storage.mdx

@@ -136,7 +136,7 @@ env.storage().instance().extend_ttl(50, 100);
 
 All contract data has a Time To Live (TTL), measured in ledgers, that must be periodically extended. If an entry's TTL is not periodically extended, the entry will eventually become "archived." You can learn more about this in the [State Archival](../../../learn/fundamentals/contract-development/storage/state-archival.mdx) document.
 
-For now, it's worth knowing that there are three kinds of storage: `Persistent`, `Temporary`, and `Instance`. This contract only uses `Instance` storage: `env.storage().instance()`. Every time the counter is incremented, this storage's TTL gets extended by 100 [ledgers](../../../learn/fundamentals/stellar-data-structures/ledgers.mdx), or about 500 seconds.
+For now, it's worth knowing that there are three kinds of storage: `Persistent`, `Temporary`, and `Instance`. This contract only uses `Instance` storage: `env.storage().instance()`. Every time the counter is incremented, this storage's TTL gets extended by 100 [ledgers](../../../learn/fundamentals/stellar-data-structures/ledgers/README.mdx), or about 500 seconds.
 
 ## Tests
 

docs/build/smart-contracts/getting-started/storing-data.mdx

@@ -122,7 +122,7 @@ env.storage().instance().extend_ttl(100, 100);
 
 All contract data has a Time To Live (TTL), measured in ledgers, that must be periodically extended. If an entry's TTL is not periodically extended, the entry will eventually become "archived." You can learn more about this in the [State Archival](../../../learn/fundamentals/contract-development/storage/state-archival.mdx) document.
 
-For now, it's worth knowing that there are three kinds of storage: `Persistent`, `Temporary`, and `Instance`. This contract only uses `Instance` storage: `env.storage().instance()`. Every time the counter is incremented, this storage's TTL gets extended by 100 [ledgers](../../../learn/fundamentals/stellar-data-structures/ledgers.mdx), or about 500 seconds.
+For now, it's worth knowing that there are three kinds of storage: `Persistent`, `Temporary`, and `Instance`. This contract only uses `Instance` storage: `env.storage().instance()`. Every time the counter is incremented, this storage's TTL gets extended by 100 [ledgers](../../../learn/fundamentals/stellar-data-structures/ledgers/README.mdx), or about 500 seconds.
 
 ### Build the contract
 

docs/data/analytics/hubble/analyst-guide/history-vs-state-tables.mdx

@@ -64,7 +64,7 @@ As seen in the table, each row shows the distinct operation with its unique `id`
 - [History Assets](../data-catalog/data-dictionary/history-assets.mdx)
 - [History Contract Events](../data-catalog/data-dictionary/history-contract-events.mdx)
 - [History Effects](../data-catalog/data-dictionary/history-effects.mdx)
-- [History Ledgers](../data-catalog/data-dictionary/history-ledgers.mdx)
+- [History Ledgers](../data-catalog/data-dictionary/history.mdx)
 - [History Operations](../data-catalog/data-dictionary/history-operations.mdx)
 - [History Trades](../data-catalog/data-dictionary/history-trades.mdx)
 - [History Transactions](../data-catalog/data-dictionary/history-transactions.mdx)

docs/data/apis/rpc/api-reference/methods/README.mdx

@@ -12,7 +12,7 @@ All you need to know about available RPC methods, parameters and responses, and
 Don't know which endpoint you need to get what you want? A lot of the returned fields are deeply-nested [XDR structures](../../../../../learn/fundamentals/data-format/xdr.mdx#more-about-xdr), so it can be hard to figure out what kind of information is available in each of these. Here's a bit of a dive into what the "workhorse" endpoints provide, in decreasing order of granularity:
 
 - [`getLedgers`](./getLedgers.mdx) operates at the block level, providing you with the full, complete details of what occurred during application of that ledger (known as "ledger metadata", defined in the protocol by the [`LedgerCloseMeta`](https://github.com/stellar/stellar-xdr/blob/v22.0/Stellar-ledger.x#L539) union, specifically the `V1` iteration). Each of the subsequent endpoints is just a microscope into a subset of the data available provided by this endpoint. Metadata includes things like:
-  - Details for recreating the blockchain's state (see [Ledger Headers](../../../../../learn/fundamentals/stellar-data-structures/ledgers.mdx#ledger-headers) for more).
+  - Details for recreating the blockchain's state (see [Ledger Headers](../../../../../learn/fundamentals/stellar-data-structures/ledgers/headers.mdx) for more).
   - The consensus information that led to the block closing (see [Stellar Consensus Protocol](../../../../../learn/fundamentals/stellar-consensus-protocol.mdx)).
   - The set of transactions, their respective operations, and the results of applying those transactions in this block (see [Transactions](../../../../../learn/fundamentals/transactions/operations-and-transactions.mdx)).
 - [`getTransaction(s)`](./getTransactions.mdx) operates across a span of ledgers or on a single transaction hash depending on the variant. The structured data here includes details such as:

docs/data/apis/rpc/api-reference/methods/getLedgerEntries.mdx

@@ -10,28 +10,15 @@ import rpcSpec from "@site/static/stellar-rpc.openrpc.json";
   method={rpcSpec.methods.filter((meth) => meth.name === "getLedgerEntries")[0]}
 />
 
-# Building ledger keys
+## Constructing Calls
 
-The Stellar ledger is, on some level, essentially a key-value store. The keys are instances of [`LedgerKey`](https://github.com/stellar/stellar-xdr/blob/v25.0/Stellar-ledger-entries.x#L588) and the values are instances of [`LedgerEntry`](https://github.com/stellar/stellar-xdr/blob/v25.0/Stellar-ledger-entries.x#L548). An interesting product of the store's internal design is that the key is a _subset_ of the entry: we'll see more of this later.
+The `getLedgerEntries` method returns the "values" (or "entries") for a given set of "keys." Ledger keys come in a lot of forms, and we'll go over the commonly used ones on this page alongside tutorials on how to build and use them.
 
-The `getLedgerEntries` method returns the "values" (or "entries") for a given set of "keys". Ledger keys come in a lot of forms, and we'll go over the commonly used ones on this page alongside tutorials on how to build and use them.
+The source of truth should always be the XDR defined in the protocol. `LedgerKey`s are a union type defined in [Stellar-ledger-entries.x](https://github.com/stellar/stellar-xdr/blob/v25.0/Stellar-ledger-entries.x#L588).
 
-## Types of `LedgerKey`s
+An interesting product of the store's internal design is that the key is a _subset_ of the entry: we'll see more of this later.
 
-The source of truth should always be the XDR defined in the protocol. `LedgerKey`s are a union type defined in [Stellar-ledger-entries.x](https://github.com/stellar/stellar-xdr/blob/v25.0/Stellar-ledger-entries.x#L588). There are 10 different forms a ledger key can take:
-
-1. **Account:** holistically defines a Stellar account, including its balance, signers, etc. (see [Accounts](../../../../../learn/fundamentals/stellar-data-structures/accounts.mdx))
-2. **Trustline:** defines a balance line to a non-native asset issued on the network (see [`changeTrustOp`](../../../../../learn/fundamentals/transactions/list-of-operations.mdx#change-trust))
-3. **Offer:** defines an offer made on the Stellar DEX (see [Liquidity on Stellar](../../../../../learn/fundamentals/liquidity-on-stellar-sdex-liquidity-pools.mdx))
-4. **Account Data:** defines key-value data entries attached to an account (see [`manageDataOp`](../../../../../learn/fundamentals/transactions/list-of-operations.mdx#manage-data))
-5. **Claimable Balance:** defines a balance that may or may not actively be claimable (see [Claimable Balances](../../../../../build/guides/transactions/claimable-balances.mdx))
-6. **Liquidity Pool:** defines the configuration of a native constant liquidity pool between two assets (see [Liquidity on Stellar](../../../../../learn/fundamentals/liquidity-on-stellar-sdex-liquidity-pools.mdx))
-7. **Contract Data:** defines a piece of data being stored in a contract under a key
-8. **Contract Code:** defines the Wasm bytecode of a contract
-9. **Config Setting:** defines the currently active network configuration
-10. **TTL:** defines the time-to-live of an associated contract data or code entry
-
-We're going to focus on a subset of these for maximum value, but once you understand how to build and parse some keys and entries, you can extrapolate to all of them.
+For more on the types of `LedgerKey` entries and their purposes, see [Ledger Entries](../../../../../learn/fundamentals/stellar-data-structures/ledgers/entries.mdx).
 
 ### Accounts
 

docs/data/indexers/build-your-own/ingest-sdk/README.mdx

@@ -9,13 +9,13 @@ The SDK is composed of several published Golang packages under `github.com/stell
 
 ## Why use the Ingest SDK?
 
-Applications can leverage the SDK to rapidly develop ingestion pipelines capable of acquiring real-time or historical Stellar network data and deriving custom data models. The SDK enables applications to traverse the hierarchal data structures of the network: [history archives](../../../../validators/admin-guide/environment-preparation.mdx#history-archives), [ledgers](../../../../learn/fundamentals/stellar-data-structures/ledgers.mdx), transactions, operations, ledger state changes, and events.
+Applications can leverage the SDK to rapidly develop ingestion pipelines capable of acquiring real-time or historical Stellar network data and deriving custom data models. The SDK enables applications to traverse the hierarchal data structures of the network: [history archives](../../../../validators/admin-guide/environment-preparation.mdx#history-archives), [ledgers](../../../../learn/fundamentals/stellar-data-structures/ledgers/README.mdx), transactions, operations, ledger state changes, and events.
 
 Use the SDK for an intuitive, compile-time, type-safe developer experience to work with the main types of network data:
 
 ### Ledger Entries
 
-Obtain the final state of [ledger entries](../../../../learn/fundamentals/stellar-data-structures/ledgers.mdx) on the network at close of any recent or historically aged checkpoint ledger sequence. A Checkpoint ledger occurs once every 64 ledgers, during which the network will publish this data to [history archives](../../../../validators/admin-guide/environment-preparation.mdx#history-archives) in the format of compressed files which contain lists of `BucketEntry`, wherein each contains one `LedgerEntry` and the `LedgerKey`.
+Obtain the final state of [ledger entries](../../../../learn/fundamentals/stellar-data-structures/ledgers/entries.mdx) on the network at close of any recent or historically aged checkpoint ledger sequence. A Checkpoint ledger occurs once every 64 ledgers, during which the network will publish this data to [history archives](../../../../validators/admin-guide/environment-preparation.mdx#history-archives) in the format of compressed files which contain lists of `BucketEntry`, wherein each contains one `LedgerEntry` and the `LedgerKey`.
 
 Ledger entries are cryptographically signed as part of each ledger and therefore represent the trusted, cumulative state at a point in time for [assets](../../../../learn/fundamentals/stellar-data-structures/assets.mdx) related to an [account](../../../../learn/fundamentals/stellar-data-structures/accounts.mdx) or [contract](../../../../learn/fundamentals/contract-development/storage/persisting-data.mdx). Examples of asset types:
 

docs/learn/fundamentals/stellar-data-structures/ledgers/README.mdx

@@ -0,0 +1,23 @@
+---
+title: "Ledgers Store Accounts, Balances, Orders, Smart Contract Data & More"
+sidebar_position: 10
+sidebar_label: Ledgers
+hide_table_of_contents: false
+description: "A ledger captures the state of the Stellar network at a point in time, storing accounts, balances, orders, smart contract data, and other persistent information."
+---
+
+import DocCardList from "@theme/DocCardList";
+
+# Ledgers
+
+A ledger represents the state of the Stellar network at a point in time. It is shared across all Core nodes in the network and contains the list of accounts and balances, orders on the distributed exchange, smart contract data, and any other persisting data.
+
+:::note
+
+Blockchains typically refer to the **ledger** as the entire record of all transactions on the blockchain and **blocks** as individual units of data that contain a collection of transactions. In Stellar, "ledger" can refer to both.
+
+:::
+
+During each [Stellar Consensus Protocol](../../stellar-consensus-protocol.mdx) round, validators agree on a transaction set to apply to the last closed ledger. When that set is applied, a new last closed ledger is defined. Each ledger is cryptographically linked to the unique previous ledger, creating a historical chain that goes back to the genesis ledger.
+
+<DocCardList />

docs/learn/fundamentals/stellar-data-structures/ledgers/_category_.json

@@ -0,0 +1,9 @@
+{
+  "label": "Ledgers",
+  "position": 10,
+  "link": {
+    "type": "doc",
+    "id": "learn/fundamentals/stellar-data-structures/ledgers/README"
+  },
+  "description": "Learn how Stellar ledgers snapshot the entire network state, from accounts and balances to DEX orders and smart-contract data."
+}