Sequencing

This chapter is the normative specification of Kailua's sequencing protocol: how the canonical state of a rollup is advanced through proposals, how contradictory proposals compete, and how a proposal becomes finalized. The key words must, must not, should, and may are to be interpreted as requirements on any conforming implementation.

The rules below define the protocol in the abstract. The KailuaTreasury, KailuaGame, and KailuaTournament contracts constitute the current implementation instance of these rules on Ethereum, and the proposer agent is the reference implementation of the proposer role. Implementation notes throughout this chapter map each abstract rule to its current enforcement point, but the abstract rules — not the contracts — are the source of intended behavior.

Protocol Parameters

A sequencing deployment is parameterized by the following values, fixed at deployment time:

Each proposal advances the chain by exactly N × S blocks.

Proposals

The protocol maintains a tree of proposals rooted at a trusted anchor: a starting state assumed valid by all participants.

---
title: Example Proposal Tree (N × S = 64 blocks per proposal)
---
graph LR;
  A[Anchor: 0] --> B[B: 64];
  A --> B'[B': 64];
  B --> C[C: 128];
  B --> C'[C': 128];
  C --> D[D: 192];

Siblings with different identities — such as B and B' above — implicitly dispute one another, with no separate challenge step. The tournament rules below determine which child of each parent, here along the path Anchor → B → C → D, may carry finality forward.

A proposal extends exactly one parent (the anchor or an earlier proposal) and consists of:

• A claim: an output commitment to the rollup state at height h = h_parent + N × S.
• Intermediate commitments: output commitments at each of the N − 1 heights h_parent + S, h_parent + 2S, …, published to a data availability layer such that each individual commitment can later be provably read back on the settlement layer. The claim itself serves as the N-th commitment.
• A derivation anchor: a reference to the settlement-layer (L1) state from which the proposal's rollup data is derivable.
• A duplication counter: an ordinal distinguishing repeated publications of otherwise identical proposal data.

Publication space not occupied by intermediate commitments (trailing data) must be zero-valued.

Every proposal has an identity: a binding commitment to its claim together with the entirety of its published data — intermediate commitments and trailing data alike. Two proposals with equal identities are duplicates: they assert exactly the same state transitions and the protocol treats them as sharing one fate.

Proposal Creation Rules

A conforming implementation must reject any proposal that violates one of the following rules.

Proposer eligibility:

1. The proposer must not have been eliminated at any prior point.
2. The proposer must have at least B collateral locked with the protocol at creation time.
3. Successive proposals by the same proposer must strictly increase in height.

Structural integrity:

4. Proposals must enter the protocol only through its sanctioned creation path, and be initialized exactly once.
5. A proposal's encoding must be canonical: two encodings of the same proposal data must not be able to coexist as distinct proposals.
6. Duplication counters must be assigned sequentially: a proposal with counter d > 0 is valid only if a proposal with identical claim data and counter d − 1 exists.
7. The proposal's height must equal its parent's height plus exactly N × S.
8. All published data the proposal commits to must be available at creation time.

Tree consistency:

9. The parent must itself be a proposal known to the protocol (or the anchor).
10. The proposal's identity must still be viable in the parent's tournament: an identity proven faulty, or one that contradicts an identity proven valid, must not be (re-)introduced.
11. The parent's tournament must not already have produced a finalized successor.

Timing:

12. A proposal must not be created before the earliest time its claimed height can exist according to the rollup's block schedule: G + h × t.
13. If a vanguard V is assigned, only V may create the first child of any parent until the advantage duration A has elapsed beyond the time given by rule 12. Other proposers may always create counter-proposals to an existing first child.

The duplication counter (rules 5–6) exists so that a correct claim can be re-proposed when all prior proposals carrying it are disqualified — for example, when the original was published by a since-eliminated proposer, or alongside faulty intermediate commitments (which alter the identity but not the claim).

Tournaments

The children of a proposal compete in a tournament to become its unique finalized successor. The tournament is decided by the following match rules, evaluated over children in order of creation:

1. The earliest child whose identity is still viable (creation rule 10) and whose proposer is not eliminated is the current contender.
2. Each later child (opponent) is compared against the contender:
   • An opponent created after the contender's challenge window (T from the contender's creation) had already closed is disregarded, and the contender wins the tournament outright. Late counter-proposals cannot re-open a settled claim.
   • An opponent from an eliminated proposer is skipped.
   • An opponent with the same identity is a duplicate of the contender and shares its fate.
   • An opponent whose identity was proven faulty is disqualified, and its proposer eliminated.
   • An opponent with a different but still-viable identity blocks the tournament: a match between two contradictory, unproven identities must not be decided by anything other than a proof.
3. If the contender's own identity becomes unviable, the contender and all of its recorded duplicates are disqualified — their proposers eliminated — and the contender search resumes from the next child.

---
title: Match Evaluation Against the Contender
---
graph TD;
  O[next opponent] --> L{created after the contender's challenge window?};
  L -- yes --> W[contender wins the tournament];
  L -- no --> E{proposer eliminated?};
  E -- yes --> S[opponent skipped];
  E -- no --> I{same identity as contender?};
  I -- yes --> D[recorded as duplicate];
  I -- no --> F{proven faulty?};
  F -- yes --> X[opponent disqualified];
  F -- no --> P[tournament blocked until a proof decides];

A tournament may be played out incrementally, but its outcome must be a deterministic function of the recorded proof outcomes, independent of who evaluates it.

Resolution

A proposal becomes finalized — its claim accepted as the canonical rollup state — only when all of the following hold:

1. Its parent is finalized. Finality proceeds strictly from the anchor outward.
2. Either its full challenge timeout T has elapsed since creation, or its identity has been proven valid (finality fast-forward).
3. It has won its parent's tournament as the surviving contender.

The anchor itself is finalized directly by deployment governance, which is how a new deployment is activated.

---
title: Proposal Lifecycle
---
graph LR;
  C[Created] -- challenge window T elapses --> R[Resolvable];
  C -- identity proven valid --> R;
  R -- parent finalized, tournament won --> F[Finalized];
  C -- proven faulty, or contradicts a valid identity --> X[Disqualified];

Condition 1 exists because a proposal's correctness is only ever conditional on its parent: proofs judge the transition starting from the parent's claim. Finalizing strictly outward from the anchor turns this chain of conditional statements into an unconditional one — and gives faults a free cascade: once a proposal is eliminated, its entire descendant subtree simply never finalizes, without a single proof against any descendant.

Elimination and Collateral

Elimination permanently disqualifies a proposer:

1. A proposer is eliminated when one of their proposals is disqualified in a tournament match — its identity proven faulty, or contradicting a proven-valid identity.
2. Elimination happens at most once per proposer, and only through a tournament of a finalized parent.
3. The eliminated proposer's locked collateral is slashed and split three ways: one share to a prover beneficiary — resolved by the payout precedence — one share to the proposer of the tournament's eventual winner, and one share burned.
4. From the offending proposal onward, all of the proposer's proposals are skipped in every tournament, and the proposer may never propose again. Proposals made before the offending one remain in play.

---
title: Slashed Bond Distribution
---
graph LR;
  B[slashed bond B] --> P[⅓ prover reward];
  B --> W[⅓ tournament winner];
  B --> X[⅓ burned];

Each share of the split serves a distinct purpose: the prover share is the bounty that funds permissionless proving, so that every fault pays for its own conviction; the winner share compensates the proposer whose correct counter-proposal kept the chain live while its collateral was locked in the dispute; and the burned share guarantees that every proven fault carries a strictly positive cost — even a proposer who convicts themselves through colluding prover and winner identities recovers at most two thirds of their bond.

Honest proposers recover their collateral in full: a proposer who was never eliminated may withdraw their bond once every tournament containing one of their proposals has produced a finalized successor.

The Proposer Role

Any party may act as a proposer. For the rollup to remain both safe (no incorrect state finalizes) and live (correct state keeps finalizing), at least one honest, well-collateralized proposer must exist, and it must behave as follows:

• Verify before extending. An honest proposer must validate every observed proposal — claim, each intermediate commitment, and the zeroness of trailing data — against its own trusted view of the rollup, and extend only the canonical tip: the highest correct proposal made by a non-eliminated proposer.
• Propose only settled data. Proposals must be assembled exclusively from L2 data the proposer's view considers final, so published commitments can never be invalidated by an L2 reorg.
• Respect timing. The proposer must wait out rule 12's minimum creation time, and — when it is not the vanguard — rule 13's advantage window, rather than submit proposals that will be rejected.
• Handle duplicates deliberately. When its intended claim has already been proposed, the proposer must locate the lowest unused duplication counter, skipping duplicates that are faulty or authored by eliminated proposers — and must not re-propose at all if a correct duplicate by a non-eliminated proposer is already live, since doing so locks additional collateral without changing any outcome.
• Maintain collateral. The proposer must ensure its locked collateral meets B (topping up exactly the shortfall) before proposing, and must keep its wallet funded — an unfunded honest proposer is a liveness failure.
• Drive resolution. The proposer should finalize resolvable proposals along the canonical chain: waiting out timeouts (or acting on recorded validity proofs), advancing tournament evaluation, and resolving the surviving successor. Where evaluation is blocked by an undecided match, resolution must wait for a proof.
• Monitor its own standing. A proposer observing its own elimination must alert its operator: its key is compromised or its data sources fed it incorrect outputs. It must also verify it is targeting the deployment's current implementation instance before proposing.