> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sundialprotocol.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Data availability

> Why block data must stay retrievable through the maturity period, how a watcher retrieves and verifies a block, and which storage backings satisfy the protocol.

Operators commit only block headers to L1. They publish each full block to a data availability (DA) layer for at least the maturity period. Confirmed blocks then pass to archive nodes.

DA is critical to security. A watcher can only challenge a block it can read. An operator that withholds a block's data could merge an invalid block once the maturity period ends.

## Requirements

A DA backing must provide all of the following for every committed block:

1. **Availability through maturity.** The full block is retrievable from the moment its header is committed until the block is merged.
2. **Open retrieval.** Anyone can retrieve it without permission and without paying the operator.
3. **Content addressing.** The block is retrievable by its header hash, so the content can be checked against what is on L1.
4. **Timestamping.** The backing attests when the block first became retrievable.
5. **Reconstructibility.** The data is enough to rebuild the four tries of the block body and the transaction contents that fraud proofs work on.

Requirements 1 to 3 make fraud detectable. Requirement 4 makes withholding attributable. Requirement 5 makes every violation provable.

## How a watcher retrieves a block

**1. Read the state queue**

Take a node's header hash and header from L1.

**2. Retrieve the block**

Fetch it by header hash from the DA backing. Check that the retrieved header hashes to that value and matches the header on L1.

**3. Rebuild the tries**

Parse the body's four sorted sets and rebuild the four Merkle Patricia Tries.

**4. Compare roots**

Check each rebuilt root against the corresponding root in the header.

**5. Replay the block**

Start from the previous block's UTXO set, apply withdrawals, transactions and deposits in order, and evaluate the ledger rules.

A watcher that finds a violation submits the matching [fraud proof](https://docs.sundialprotocol.com/l2/fraud-proofs.md) within the block's maturity period.

## Serialization

A block is serialized as its header followed by its body. Each of the body's four sets is written as key-value pairs sorted by key. The sort order is part of the format: it makes the serialized set canonical, so every honest party derives the same trie.

| Set | Trie key | Trie value |
| - | - | - |
| `utxos` | Serialized output reference | Serialized output |
| `transactions` | Transaction ID | Serialized transaction |
| `deposits` | Deposit ID | Serialized deposit info |
| `withdrawals` | Withdrawal ID | Serialized withdrawal info |

The codec's schema is `cddl-files/codec.cddl` in the monorepo, and its reference implementation is the [`midgard-ts`](https://docs.sundialprotocol.com/sdk/midgard-ts) package.

## Root verification

If a header's root doesn't match the published data, that mismatch can be proven on L1.

The procedure streams over a set's key-value pairs in ascending key order, building the trie along the path of the latest key and finalizing each subtrie as soon as the ordering guarantees it is complete. Its working state is bounded by the depth of the trie, not the size of the set.

On L1 it runs as a computation thread, each transaction processing a bounded chunk. It runs only when a watcher challenges a block, so honest blocks never pay for it.

## Storage backings

The protocol fixes the interface, not the substrate. Three kinds of backing fit it:

| Backing | How it works | Security |
| - | - | - |
| **L1-native transient blob storage** | The settlement L1 stores the block for a bounded period, timestamps it and serves it to anyone. | Secured by the L1's own consensus. |
| **Certified availability** | A stake-weighted quorum of independent parties retrieves each block, checks it against the header and signs a certificate. A header can't be committed without one. | Rests on the stake in the quorum. |
| **Operator-served storage** | The operator serves its own blocks over an open interface. | Withholding is detectable but not provable on L1. |

## Archive nodes

Archive nodes store the data of confirmed blocks. This is simpler than DA for unconfirmed blocks: the confirmed state's chained header hash pins the whole history, so an archive either matches it or doesn't.

Every operator keeps the latest confirmed UTXO set, because it needs that set to build valid blocks. That set, plus the block data in the DA layer, is the minimum needed to keep producing blocks. The rollup's security doesn't depend on older history.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.