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

# Security model

> The six invariants the Sundial L2 protocol guarantees and the threat model that sets the protocol's parameters.

This page states what the protocol guarantees and the threats that shape the protocol's parameters.

## Protocol guarantees

The protocol guarantees six invariants.

| Invariant | What it means |
| - | - |
| **Block merging order** | Each valid block is merged before its descendants. A block that was valid when committed can't become invalid through an out-of-order merge. |
| **Valid blocks** | Every valid block can eventually be merged. No fraud proof can succeed against a valid block. |
| **Invalid blocks** | Every invalid block can be invalidated by a fraud proof before its maturity period ends. |
| **Open operator set** | Anyone with a sufficient bond can become an active operator, and every active operator gets a shift. |
| **Operator bond** | No operator can recover its bond before its most recent block matures, and every operator can afterwards. |
| **Censorship protection** | While blocks are being produced, operators can't censor deposits, withdrawal orders or transaction orders. |

## Threat model

### An attack on the settlement L1

The L2's consensus runs entirely as L1 contracts. Reverting an L2 state change is as hard as attacking the L1's finality.

Every L2 transaction is confirmed by two L1 transactions, the commitment and the merge, separated by the maturity period. Reverting both would take a long-range fork from before the maturity period began. On Cardano, nodes reject forks deeper than 2,160 blocks, about 12 hours. The whitepaper takes 24 hours, twice that, as the minimum maturity period for any network that secures value.

### Operator abuse

An operator chooses the contents of its blocks, so it can ignore transaction requests. You escalate by posting a [transaction order](https://docs.sundialprotocol.com/l2/user-events.md#transaction-order) on L1, which must be included. If all operators stop, the [escape hatch](https://docs.sundialprotocol.com/l2/consensus.md#escape-hatch) lets new operators restart production.

### Replay

Every L1 transaction of the protocol spends at least one UTXO, so the L1's double-spend rule prevents replaying it. Duplicated contents inside blocks are caught by the ledger rules. Each deposit and withdrawal has its own L1 UTXO that is spent when it is processed, so a confirmed event can't be used twice.

### Data withholding

A watcher can challenge only a block it can read. An operator that commits a header and publishes no data, or data that doesn't match, can't be challenged that way. The protocol therefore treats availability as a security condition. See [Data availability](https://docs.sundialprotocol.com/l2/data-availability.md).

## How the parameters follow

The security argument needs a bond large enough to deter fraud, a reward large enough to keep watchers looking, and a maturity period long enough to detect and prove fraud. The design ranges for a network that secures value:

| Parameter | Design range |
| - | - |
| `required_bond` | 50,000 to 200,000 ADA |
| `fraud_prover_reward` | 30% to 50% of the bond |
| `maturity_duration` | 3 to 7 days |

See [Protocol parameters](https://docs.sundialprotocol.com/reference/parameters.md).

## For node operators

* **Three keys, three duties.** The node uses separate seed phrases for the main operator wallet, block commitments and merges. The faucet key must not reuse any of them, and the node refuses to start if it does.
* **Secrets stay out of plain configuration.** The cloud deployment loads every sensitive value from a secrets manager.
* **Put a gateway in front.** Public deployments place a reverse proxy or firewall in front of the node for authentication, rate limiting and request-size limits.
* **Mainnet mode disables the faucet** and seeds no genesis UTXOs.

## For integrators

* A `200` from `POST /submit` means queued, not accepted. Poll `GET /tx`.
* Delivery is at-least-once. Build submissions so that processing them twice is safe.
* Don't reuse a nonce UTXO across retries once it is spent.
* Set client-side timeouts on every call.

## Independent review

[Status and security](https://docs.sundialprotocol.com/overview/status.md#audits-and-reviews) lists the reviews on record.


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