Inside the protocol

Aggregates incoming transactions, executes them against current L2 state, and produces rollup blocks. Each block header binds to its parent so the chain of state cannot silently fork or skip.

• Ordering follows a published policy rather than operator discretion.
• Blocks reference the L1 block they were built against, which anchors them in Solana's history.
• A proposer posts state roots under bond; an invalid root costs the proposer that bond.
• Implemented as solieum-node: it signs an ordering receipt per transaction, produces a block every two seconds when there is work, and on devnet publishes each batch and commits each root itself. Restarts replay published data and refuse to serve state that does not reproduce its committed root.

// Rollup block header
pub struct RollupBlockHeader {
    pub block_id:            [u8; 32],
    pub previous_block_hash: [u8; 32],
    // Binds to the parent's post-state, so the root chain
    // cannot fork or skip a block.
    pub pre_state_root:      [u8; 32],
    pub transactions_root:   [u8; 32],
    pub post_state_root:     [u8; 32],
    pub l1_reference_block:  u64,
    pub proposer:            [u8; 32],
}

A Solana program holding the sequence of L2 state roots. This is the anchor: once a root is final here, the L2 state it represents is what withdrawals are settled against.

• Roots advance strictly one block at a time, with no gaps and no rewrites.
• Time comes from the on-chain clock, never from the submitter — a challenge window measured by a value the operator controls is not a window.
• Each root moves through an explicit lifecycle: proposed, challengeable, then final.
• Deployed on Solana devnet. The first root landed within five seconds of its transaction, and challenge verdicts enter only by cross-program call from the dispute program — a direct key cannot inject one.

// State root lifecycle
Proposed ──► Challengeable ──► Final
     │              │
     │              └──► Challenged ──► Disproven (root removed, bond slashed)
     └──► rejected if the parent link or sequence does not match

Lets anyone challenge a state root they believe is wrong. Challenger and proposer narrow the disagreement down to a single execution step, which Solana can then check directly and cheaply.

• Re-running an entire batch on L1 does not fit inside a transaction's compute budget, so the dispute is narrowed by bisection instead.
• Each round halves the disputed range; the final round is one instruction, verified against proofs of exactly the state it touched.
• The full dispute must complete comfortably inside the challenge window, with margin for L1 congestion.
• The dispute game is a Solana program deployed on devnet. Its witnessed one-step verifier is measured at about 20,000 compute units for system and SPL-token transfers; wider instruction classes are the open work.

// Narrowing a disagreement to one step
round 1   [ 0 ............................. N ]   disagree
round 2   [ 0 ......... N/2 ]                     disagree
round 3            [ N/4 ... N/2 ]                disagree
   …
round k                    [ i, i+1 ]            one instruction
                              ▼
                    verified on Solana L1

Publishes the transaction data needed to reconstruct L2 state independently. Without it, nobody outside the operator can check the operator — and the fraud proof system has nothing to prove against.

• Data is published so any party can re-derive the chain and compare roots.
• Retention has to outlast the withdrawal path: a withdrawal that becomes unprovable once data expires is a loss, not an inconvenience.
• Where the data lives determines what the system actually is — on Solana it is a rollup; elsewhere it is a different security model with a different name.
• Implemented as a Solana program on devnet: a batch is opened, its compressed bytes posted in transactions, and sealed only if they fold to the commitment declared at open. The data lives on Solana.