Settlement batches

Settlement is how ZUL borrows Solana's permanence. On a fixed cadence (every 120 slots — one minute — on the default config), the node's batcher posts a record of what the L2 did to the settlement program on L1.

The batch record

BatchRecord {
  batch_no:       u64          // monotonic
  l2_block_range: (u64, u64)   // slots covered
  state_root:     [u8; 32]     // SMT root after the range
  da_hash:        [u8; 32]     // hash of the zstd batch data
}

• state_root — the blake3 SMT root (see State commitment) as of the last block in the range. Withdrawal claims verify against these posted roots.
• da_hash — binds the record to the full transaction data published through the DA log; you can't settle a root while withholding the data behind it without the mismatch being visible.

Optimistic, stage 0

Posting a record asserts "this is the L2 state." In a mature optimistic rollup, a fraud proof would let anyone disprove an invalid assertion on-chain. ZUL v1 stops one step earlier: the challenge window is procedural — all data needed to recompute the root is public, anyone can check, but rejection is operational rather than enforced by the program. This is stated plainly in Trust model, and enforced fraud proofs are the roadmap item that graduates the system past stage 0.

What depends on settlement

Empty L2 slots produce no batch data, so an idle chain settles almost nothing — cadence and cost scale with actual activity.