> ## 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.

# Sundial L2: an optimistic rollup for UTXO ledgers

> How the Sundial L2 works: operators commit block headers to L1, watchers prove fraud, and blocks merge into the confirmed state after a maturity period.

The Sundial L2 is an optimistic rollup for UTXO-based networks, built on the Midgard design and settling to Cardano. It processes blocks of transactions off-chain and commits only fixed-size block headers to a set of L1 smart contracts.

A block header has 10 fields and hashes to 28 bytes, however many transactions the block holds. That size difference between a block and its header is how the rollup multiplies the L1's throughput.

> [!NOTE]
>
> This section summarizes the [whitepaper](https://docs.sundialprotocol.com/overview/whitepaper.md), which is the authoritative specification.

## How it works

```mermaid theme={null}
flowchart TB
  U["Users"] -->|"submit L2 transactions"| OP["Operators<br/>rotating shifts"]
  U -->|"deposits, withdrawal orders,<br/>transaction orders"| UE["L1 user event contracts"]
  OP -->|"publish full block"| DA["Data availability layer"]
  OP -->|"commit header"| SQ["L1 state queue"]
  UE -->|"inclusion times bind blocks"| OP
  W["Watchers"] -->|"read blocks"| DA
  W -->|"submit fraud proof"| FP["L1 fraud proof contracts"]
  FP -->|"remove header, slash bond"| SQ
  SQ -->|"merge after maturity"| CS["Confirmed state<br/>and settlement"]
```

1. **Operators** take turns, on a schedule enforced by an L1 contract, to receive L2 transactions, assemble blocks, publish them and commit their headers. Anyone can become an operator by posting the required bond and waiting the registration period.
2. **The state queue** is an L1 linked list of committed headers. A header is appended by the operator whose shift it is, and merged into the confirmed state after its maturity period.
3. **Watchers** read each committed block from the data availability layer and check it against the ledger rules. Anyone can be a watcher.
4. **A fraud proof**, verified on L1, removes an invalid block from the queue, slashes the operator's bond and pays the watcher a share of it.
5. **Settlement** turns merged blocks into L1 UTXOs that let users absorb deposits into a reserve and pay out withdrawals from it.

## The security argument

An optimistic rollup offers security similar to processing the transactions on L1, provided four conditions hold:

* the operator bond is large enough to discourage fraud;
* the watcher reward is large enough to keep watchers vigilant;
* the maturity period is long enough for watchers to detect and prove fraud;
* the data availability layer is open to everyone throughout the maturity period.

When the last three make detection near-certain, the bond is a strong deterrent. A disqualified block never enters the confirmed state, so fraud earns nothing to set against the forfeited bond.

## Why UTXO helps

Sundial's ledger is a UTXO ledger with deterministic transactions. A fraud proof isolates the one transaction that broke a rule. Violations that involve a second transaction, or the previous UTXO set, need Merkle proofs for those pieces alone. No fraud proof reads the rest of the block or any other block.

This keeps fraud proofs small and cheap to verify on L1, which makes it practical for more people to police the rollup. On account-based chains, a much larger part of the global state has to be inspected.

## Censorship resistance

Fraud proofs protect the validity of blocks. They don't stop an operator from ignoring you. Two further mechanisms do:

* **Inclusion times.** Deposits, withdrawal orders and transaction orders are created on L1 and carry an inclusion time. A block whose time interval contains that inclusion time must include the event, or the block is invalid. See [Deposits, withdrawals and transaction orders](https://docs.sundialprotocol.com/l2/user-events.md).
* **The escape hatch.** If operators stop committing blocks altogether, the bond requirement for new operators drops for a limited period so that honest actors can restart production. See [Consensus](https://docs.sundialprotocol.com/l2/consensus.md#escape-hatch).

## Headline figures

| Property | Value |
| - | - |
| Block header | 10 fields; Blake2b-224 hash, 28 bytes |
| Ledger rules | 21 rules with 30 violations, plus 4 data availability violations. Each violation has a fraud proof construction. |
| Fraud proof categories in the reference catalogue | 4, each a multi-step computation thread of 2, 3 or 4 steps |
| Node rule engine | 22 checks in two phases |
| Sustained load measured | 800 and 1,000 TPS accepted for 30 minutes, with 718 and 873 tx/s committed |
| Inclusion latency | p95 of 15 s at 100 and 200 TPS |

## Three layers, one protocol

The protocol exists at three levels of detail, all in the [monorepo](https://github.com/sundial-protocol/sundial-monorepo):

* **A formal specification** in Lean 4 that models the protocol's state machines and proves properties of them (`technical-spec/`).
* **A validator implementation** of the L1 contracts in Aiken for Plutus V3 (`onchain/aiken/`).
* **A node implementation** of the off-chain half: sequencing, the rule engine, block production, commitment, merge and the API (`midgard-node`, `midgard-sdk`, `midgard-ts`).

## Read next

> **[Ledger and transactions](https://docs.sundialprotocol.com/l2/ledger.md)**
>
> Blocks, headers, the UTXO set and the L2 transaction type.

> **[Consensus](https://docs.sundialprotocol.com/l2/consensus.md)**
>
> Operators, shifts, the state queue, settlement and the escape hatch.

> **[Fraud proofs](https://docs.sundialprotocol.com/l2/fraud-proofs.md)**
>
> The ledger rules and how a violation is proven on L1.

> **[Performance](https://docs.sundialprotocol.com/l2/performance.md)**
>
> What was measured, on what hardware.


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