Security model - Sundial Protocol

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 on L1, which must be included. If all operators stop, the 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.

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.

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 lists the reviews on record.

​Protocol guarantees

​Threat model

​An attack on the settlement L1

​Operator abuse

​Replay

​Data withholding

​How the parameters follow

​For node operators

​For integrators

​Independent review