> For the complete documentation index, see [llms.txt](https://pegasys.gitbook.io/pegasys-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://pegasys.gitbook.io/pegasys-docs/technical-details/pegasys-ledger.md). # PegaSys Ledger The PegaSys ledger is a core component of the network, responsible for recording transactions, maintaining account balances, and ensuring the integrity of the system. Every time the PegaSys Hub generates a valid aggregated signature for a transaction, the transaction will be added to a block’s operation log through an additional consensus round. Each block in the ledger consists of the following elements: * Block Number: The block number provides a logical ordering for all blocks. * **Account Tree**: A MS-SMT (Merkle Sum Sparse Merkle Tree) \[6] that stores every user’s current balance (deposit + fees accrued). The root of this tree therefore commits to the total User Deposits DT as of block time T. * Lightning Channel Commitment Tree: A Merkle Sum Tree built over an exhaustive list of the Lightning Channel Commitment Transactions describing the latest state of each Lightning Channel the System is a participant of. The leaves commit to a lightning channel commitment, while the internal nodes commit to their children as well as the sum of the System’s share in each of the Lightning Channels described by each of their children at the block number T. The root of this tree therefore commits to the total amount RT deployed by the network into all Lightning Channels at T. * **Operation Log**: The operation log is a regular Merkle Tree that commits to the list of all actions signed by the network since the last block. This will include the actions for channel bootstrap, channel settlement, intermediate routing HTLC commitments and post-routing commitments. The Merkle Sum Tree structure for the Account Tree and the Commitment Tree is chosen for efficient verification of the solvency of the network, and a fraud-proof construction based on this data is described in this section. ### Withdrawals PegaSys employs an optimistic withdrawal scheme. Initially, the user sends a withdrawal request to at least f+1 PegaSys nodes - guaranteeing that at least 1 honest node receives the request and broadcasts it to the rest of the network. Then, the system reaches consensus on how to compose a withdrawal payment for the user’s current balance in the Account Tree. Once these actions are completed, the system creates a transaction with a UTXO spendable by the user’s public key. In the case that the network does not comply to the user’s request, the user can initiate a forced withdrawal by appealing to a “higher” authority. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://pegasys.gitbook.io/pegasys-docs/technical-details/pegasys-ledger.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.