> ## 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. # Consensus > The Sundial L2's consensus runs as L1 smart contracts: the operator directory, the scheduler, the state queue, settlement and the escape hatch. The Sundial L2's consensus protocol is implemented entirely as L1 smart contracts. It establishes the canonical chain of valid blocks. Its parts: | Component | Role | | - | - | | Time model | Defines operator shifts and the time interval each block claims | | Operator directory | Tracks registered, active and retired operators and holds their bonds | | Scheduler | Names the operator of the current shift | | State queue | Holds committed headers until they merge or are disqualified | | Settlement | Tracks the user events of merged blocks until they are processed | | Reserve and payout | Hold absorbed deposits and pay out withdrawals | | Escape hatch | Restores block production after an outage | | Hub oracle | Stores the policy IDs and addresses of all the components | ## Operators Operators receive L2 transactions, assemble blocks, publish the full blocks to the data availability layer, and commit the headers to the state queue. They share this job on a rotating schedule. ### Lifecycle 1. **Register.** Anyone can register by posting the required bond in ADA. 2. **Wait.** A registrant waits `registration_duration` before activating. If the active set is empty, the earliest registrant activates at once. 3. **Active.** The operator takes its turn in the schedule. 4. **Retire.** An active operator can retire. It recovers its bond only after all its committed headers have matured. ### Bond and slashing The bond backs the operator's promise to commit valid blocks. An operator whose header is proven fraudulent is disqualified and forfeits the bond. The forfeited bond is split: * `fraud_prover_reward` goes to the watcher that proved the fraud. * `slashing_penalty` goes to the settlement L1's treasury. The two always sum to `required_bond`. For a network that secures value, the design range is a bond of 50,000 to 200,000 ADA with 30% to 50% of it as the prover's reward. ### Inactivity Operators that don't commit blocks during their shift, or ignore user events, receive strikes. After `max_inactivity_strikes`, part of the bond is slashed and the operator is retired. ## Time model Time is divided in two independent ways. * **Shifts** are fixed intervals of `shift_duration`, assigned to operators by the scheduler. Only the appointed operator can commit blocks. * **Event intervals** are the intervals `[start_time, end_time)` that blocks claim. A block's `start_time` is the previous block's `end_time`. Its `end_time` is the upper bound of the validity range of its commitment transaction. Because each interval starts where the last one ended, intervals cover time with no gaps or overlaps. And because a commitment transaction is only valid while L1 time is inside its validity range, an operator can't claim an interval far in the future or let it lag behind the clock. ```text theme={null} operator shifts |---------------- Operator A -----------------|--- Operator B ----| 0 46 66 event intervals | E47 | E48 | E49 | E50 | 0 12 26 42 66 ``` An interval can span a shift boundary. An operator can commit blocks as quickly as it likes during its shift. ## Scheduler The scheduler is one L1 UTXO that names the current operator and its shift start. It steps through the active operators in order. At the end of each cycle, registered operators that are eligible must activate before the next cycle starts. The shift only controls when the scheduler advances. If the next operator is inactive, the current one can keep committing. ## State queue The state queue is an L1 linked list of block headers. Its root node holds the confirmed state. It has three operations: * **Commit.** The appointed operator appends a header to the end of the queue. The contract checks the operator's signature, the link to the previous header, and the time bounds. * **Merge.** After `maturity_duration`, the header at the front of the queue is merged into the confirmed state. Blocks merge in order. * **Remove.** When a fraud proof succeeds, the fraudulent header and its descendants are removed, descendants first. After a removal, the next committed header starts where the last remaining one ended. Its interval covers the removed blocks' intervals, so it must include every user event they should have included. ## Settlement When a block that contains deposits, withdrawals or transaction orders merges, a **settlement UTXO** is created holding that block's event roots. Users reference it to absorb confirmed deposits into the reserve and to start payouts for confirmed withdrawals. The current operator can attach a **resolution claim** to a settlement UTXO, stating that all its events have been processed. The claim waits for `maturity_duration`. If it is proven false in that time, the operator is slashed. Otherwise the operator can spend the settlement UTXO and recover its deposit and some fees. An operator's bond stays locked until all its headers and all its resolution claims have matured. ## Escape hatch The escape hatch restores block production when operators have stopped committing blocks. It trades some security for liveness, for a bounded time. **1. Trigger** Anyone can trigger it once the last header in the state queue is older than `escape_hatch_block_age`. This is possible only when every active operator has stopped. **2. Emergency period** For `emergency_duration`, new operators can register with the lower `emergency_required_bond`, so that honest actors can restart production cheaply. **3. Recovery** A grace period of `emergency_grace_period` follows. A reduced-bond operator can retire, or top its bond up to `required_bond` and stay. After the grace period, anyone can retire an operator that is still under-bonded and claim a small penalty from its bond. The escape hatch doesn't change the time model. The first block after an outage has an interval that spans the outage, so it must include every deposit, withdrawal order and transaction order created during it. User funds are not stranded by an outage of any length. > [!NOTE] > > The escape hatch is a mechanism for operators. It is not a button that withdraws your funds directly. You exit with a [withdrawal order](https://docs.sundialprotocol.com/l2/user-events.md#withdrawal-order), which the restarted operators must include. ## Parameters Every name in `code font` on this page is a protocol parameter. [Protocol parameters](https://docs.sundialprotocol.com/reference/parameters.md) lists them with their design ranges. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.