Ledger and transactions - Sundial Protocol

The Sundial L2 ledger is a chain of blocks. Each block turns the previous block’s set of unspent transaction outputs (UTXOs) into a new one. Unlike an L1 ledger, it is an open system. Blocks create and destroy UTXOs in response to events on L1 (deposits and withdrawal orders) as well as L2 transactions.

Blocks

A block is a header hash, a header and a body. The body holds four sets:

Set	Contents
`utxos`	The unspent outputs after applying the block
`transactions`	Transaction requests and transaction orders
`deposits`	Deposit events from L1
`withdrawals`	Withdrawal orders from L1

The full block is published to the data availability layer. Only the header hash and header go to L1. That is sufficient because the header holds the Merkle Patricia Trie root of each set, and each root can be checked on L1 by streaming over the set.

Order of application

A block applies its events in a fixed order:

Withdrawals
Transaction orders
Transaction requests
Deposits

A block that breaks this order is invalid. Orders come before requests so that a transaction order, which costs more to create, is never invalidated in favour of a request.

The block header

Field	Meaning
`prev_utxos_root`	The previous block’s `utxos_root`
`utxos_root`	Trie root of the block’s UTXO set
`transactions_root`	Trie root of the block’s transactions
`deposits_root`	Trie root of the block’s deposits
`withdrawals_root`	Trie root of the block’s withdrawals
`start_time`, `end_time`	The block’s event interval
`prev_header_hash`	Hash of the previous header. 28 zero bytes for the genesis block.
`operator_vkey`	Key hash of the operator that committed the header
`protocol_version`	The protocol version that applies to this block

The header hash is the Blake2b-224 hash of the header, 28 bytes.

The UTXO set

The UTXO set maps output references to outputs. An output has an address, a value, an optional inline datum and an optional script. An output reference is the ID of the event that created the output (a transaction or a deposit) and its index. Every L2 address carries the network ID of the Sundial instance, which separates the L2 ledger from the settlement L1 and from other Sundial instances.

Transactions

There are two ways a transaction reaches a block:

A transaction request is submitted to an operator’s API. This is the normal path.
A transaction order is posted on L1. Operators must include it. See Deposits, withdrawals and transaction orders.

Both land in the same transactions set.

How the transaction type differs from Cardano’s

The L2 transaction type is based on Cardano’s Conway-era transaction, restricted to what a contract-secured L2 can validate.

Rule	Why
UTXO transactions only. No certificates, stake withdrawals, voting or treasury fields.	The L2’s consensus is not proof of stake, and its L1 scripts can’t authorize staking or governance actions for users.
Conway-era features only. No bootstrap addresses. Plutus scripts are Plutus V3.	There is no obligation to support earlier eras.
No transaction metadata.	Scripts can’t read metadata, and it adds bytes to every block. Put content you need in an output datum.
Inline datums only.	The ledger never has to index datum hashes to datums.
Observers and ordered inputs. The type adopts CIP-112 and CIP-128.	CIP-112 replaces the “withdraw zero” pattern with an Observe script purpose. CIP-128 keeps inputs in submitted order, which makes scripts cheaper.
POSIX time. Validity intervals are timestamps, not slots.	The L2’s consensus doesn’t use slots.
Declared signers. `required_signer_hashes` lists the key hash of every spent key-hash input.	A missing signature can then be proven without resolving every input.
The validity flag is always true.	Invalidity is expressed through validity tags and fraud proofs.

Violating any of these is fraud under the ledger rules.

Hashed fields

In the form that L1 scripts work with, every variable-length field of a transaction is replaced by its hash. This lets a fraud proof step through a transaction at bounded cost. The data availability layer holds the preimages, and a mismatch between a hash and its preimage is itself provable.

Confirmed state

A block is confirmed once all its predecessors are confirmed and its maturity period has passed without a verified fraud proof. Confirmation is irreversible, which lets the L1 representation be condensed:

ConfirmedState keeps only the last confirmed header’s hash, its UTXO root, its time bounds and its protocol version. Each merge overwrites it. Earlier headers are pinned by the chain of header hashes.
Settlement takes the block’s deposit, withdrawal and transaction roots into a separate settlement UTXO. Users reference it to absorb deposits and pay out withdrawals. See Consensus.

​Blocks

​Order of application

​The block header

​The UTXO set

​Transactions

​How the transaction type differs from Cardano’s

​Hashed fields

​Confirmed state