← Quickstarts
Commit-First, Repair-If-Needed
PRE-MAINNET
STEP 1 OF 3
NEXT: How the composer attests a batch →
SYNC BLOCK COMMITTED · SYNC_HEIGHT 8,241
committer commits the Sync block
→
optimistic.begin(…)
→
optimistic.rs:117 · returns ()
OptimisticallyIncluded
BTreeMap<u64, InFlight> — one ledger per cross-chain rollup
8,239
→
InFlight
Settled
8,240
→
InFlight
Pending
8,241
→
InFlight
Pending
← just recorded
The container is the ledger; the state machine is the per-entry Resolution — Pending, Settled, Failed (optimistic.rs:67).
PROTOCOL RESEARCHERS

How L1 stays the source of truth

An L2 commits first: the Sync block is committed, and begin() records it in a ledger as Pending — before L1 has confirmed anything.

L1 then settles that entry, or repairs it — and until finality it can still take it back.

WHAT YOU'LL LEARN
  • 01 · THE LEDGERbegin() records the committed Sync block at its sync_height as Pending. One ledger per cross-chain rollup.
  • 02 · TWO ORACLES, THREE STATESThe observer’s log scan marks Settled or Failed. The Deriver’s cursor overrides a Failed verdict — it is the stronger proof.
  • 03 · SETTLED IS NOT PERMANENTAn L1 reorg removes rolled-out Settled entries. Entries leave clean only at finality, after their postBatch receipt is re-checked.

Verified against eez-rollup0 @ a4b9b2f — pre-mainnet; interfaces may move.