What Goes Into the State Queue
The State Queue stores block headers only, not block bodies. Full block data — transactions, UTxO sets, deposits, and withdrawals — is stored off-chain on the Data Availability (DA) layer. On-chain, each header is a compact, fixed-size structure derived from Merkle roots of the off-chain data:
The header hash itself is a Blake2b-224 digest of the full header structure. Because each header commits to
prev_header_hash, the queue forms a cryptographically linked chain: you cannot swap or reorder blocks without breaking every subsequent header hash.
The Three State Queue Operations
- Commit
- Merge
- Remove
An operator adds a new block header to the end of the queue.To commit a block, an operator must be currently registered in the Active Operator Registry and scheduled to produce a block in the current VRF slot. The commit transaction:
- Mints a new block NFT token (named with the
MBLCprefix followed by the header hash). - Creates a new linked-list node UTxO carrying the header as its inline datum.
- Updates the previous tail node to point to the new block.
The Maturity Window
Every committed block enters a maturity window before it can be finalized. During this period, Provers (watcher nodes) download the block body from the DA layer, replay the block’s transactions against the prior UTxO set, and verify that every claim in the header is correct.The maturity window is the security guarantee of the optimistic rollup. Sundial does not verify every block on L1 — it assumes blocks are valid and only intervenes when a watcher provides proof that something is wrong. A longer maturity window gives watchers more time to detect and challenge fraud; a shorter window reduces withdrawal latency.
The Confirmed State
The Confirmed State is a single UTxO on L1 — identified by theMIDGARD_CONFIRMED_STATE asset name — that represents the finalized tip of the L2 chain. It stores:
Withdrawals, the Settlement Queue, and cross-chain bridges all read from the Confirmed State to validate user claims. Because the
utxo_root is a Merkle root of the full UTxO set, a user can prove ownership of an L2 UTxO by providing a Merkle inclusion proof against this root.
What Happens When a Block Is Removed
When a fraud proof succeeds, the consequences are:1
Operator bond is slashed
The operator who committed the fraudulent block loses their entire bond deposit. The bond is transferred to the address of the watcher who submitted the fraud proof.
2
Fraudulent block is removed
The block NFT is burned and the linked-list node is removed. If the fraudulent block had successor blocks that built on it, those blocks must also be removed — any chain built on an invalid root is invalid.
3
Queue resumes from the last valid block
The State Queue reverts to its pre-fraud state. Operators can then recommit blocks starting from the last confirmed valid block.
The Escape Hatch
If the State Queue stops progressing — no new blocks are committed for an extended period — Sundial activates the Escape Hatch. This emergency mechanism allows you to exit the L2 directly, bypassing the normal withdrawal flow, by proving ownership of your L2 UTxOs against the last Confirmed State. The Escape Hatch exists to protect you even in scenarios where all operators are offline, the operator set is compromised, or the network halts for any reason. Your funds are never permanently locked in the L2.Block Data and the DA Layer
Only block headers are stored in the State Queue on L1. Full block bodies — including all transactions, UTxO diffs, deposit events, and withdrawal events — are stored on the Data Availability layer. Archivists (a type of watcher node) replicate and serve this data. The on-chain headers are sufficient for fraud proofs because every claim in a block body is committed to by the Merkle roots in the header.