Rollup architecture: sequencing, proofs and exits

What makes a rollup a rollup

A rollup is a chain that executes off Ethereum but cannot lie about what it executed. Three things live on L1: the ordered transaction data, or at least enough of it to rebuild the state; a commitment to the resulting state, usually called a state root or output root; and a contract that decides which of those commitments is final and therefore which withdrawals to pay. Execution, block building and the mempool all happen off L1.

The defining property is that the L2 state is a pure function of data that sits on L1:

Remove any one of the three and you have something else. The distinction that matters most is where the data lives, because data you cannot get is a state you cannot rebuild and a proof you cannot write.

The data availability guide covers the data half in depth. This guide is about the other moving parts: who orders transactions, how the L1 decides what is true, and how you get out when you disagree with the operator.

The sequencer and four meanings of confirmed

On Arbitrum One, Base and OP Mainnet, as on most rollups in September 2026, a single sequencer run by the operator receives transactions, orders them, executes them and posts compressed batches to Ethereum. Centralized sequencing gives fast, predictable blocks. What it costs shows up in how many different things "confirmed" can mean:

The gap between the third and fourth rows is the most misunderstood fact about optimistic rollups. Once the batch is finalized on Ethereum, the L2 state is already fixed: every honest node computes the same result. The challenge window exists only to convince the L1 bridge contract, which cannot run the L2 itself. That is why liquidity providers can pay out "fast withdrawals" in minutes. They run a node, know the outcome, and wait out the window on your behalf for a fee.

Forced inclusion: censorship resistance through L1

A sequencer that can refuse your transaction forever can freeze your funds forever. Serious rollups therefore give users a path around it: submit the transaction to an L1 contract, and if the sequencer does not include it within a fixed delay, the protocol includes it anyway.

Forced inclusion bounds censorship; it does not remove it. The sequencer still decides where your transaction lands relative to everyone else’s, so a forced transaction can be sandwiched or front run, and a forced withdrawal still has to wait out settlement. The worst case for getting assets out against a hostile operator is roughly:

Optimistic rollups: assume valid, prove fraud

An optimistic rollup lets a proposer post a state claim with a bond. If nobody disputes it during the challenge window, it becomes final. If someone does, the two sides play an interactive game that ends with the L1 contract executing a single machine instruction itself. The trick that makes this affordable is bisection. Two parties who agree on the state at step 0 and disagree at step N can locate the first step where they diverge in about log₂ N rounds, and only that one step ever runs on L1.

# Interactive bisection, simplified. Both parties agree on the machine
# state at step lo and disagree about the state at step hi.
# Each round halves the disputed range, so N steps take about log2(N) rounds.
def bisect(lo, hi, defender, challenger):
    while hi - lo > 1:
        mid = (lo + hi) // 2
        claim = defender.state_hash_at(mid)      # defender commits onchain
        if challenger.state_hash_at(mid) == claim:
            lo = mid                              # they agree up to mid
        else:
            hi = mid                              # they already disagree at mid
    # One step is left. The L1 contract executes it itself and
    # rules for whoever's claimed post state matches.
    return l1_execute_one_step(lo, defender.state_at(lo))

Security rests on a 1 of N assumption: one honest, funded and online challenger is enough. That is why "permissionless" matters so much. If only an allowlist can challenge, you are trusting the allowlist.

Arbitrum One: BoLD

Arbitrum switched to BoLD (Bounded Liquidity Delay) on February 12, 2025, making validation permissionless. Disputes narrow in levels: from blocks, to ranges of machine steps within a block, to one WebAssembly instruction that the L1 contract executes as a one step proof. The game is all against all: one honest party can defend the correct claim against any number of attackers, and the delay a dispute can add is bounded rather than growing with the number of attackers. Arbitrum’s documentation puts that bound at about two challenge periods plus a two day grace period for the Security Council. Bonds make attacks expensive: 3,600 ETH to post an assertion, 555 WETH for a big step sub challenge and 79 WETH for a small step one, with 1% of confiscated funds paid to honest defenders as a bounty.

OP Stack: Cannon and the fault dispute game

Permissionless fault proofs went live on OP Mainnet on June 10, 2024. The disputed computation is a fault proof program that derives and executes L2 blocks from L1 data (originally op-program, now also Kona, a Rust implementation), compiled to MIPS and run in Cannon, an emulator whose single step also exists as an L1 contract. The game tree bisects first over output roots and then, below a split depth, over the execution trace, to a maximum depth of 73. Each side has a chess clock that accumulates only its own response time, so stalling cannot stretch the game indefinitely.

Base: two proof systems at once

Base took a different route with its Azul upgrade in May 2026: multiproofs. A state proposal can be backed by a TEE proof, from L2 blocks re-executed inside AWS Nitro enclaves, or by a ZK proof generated with SP1, and a permissionless ZK proof can override a TEE proof. Either alone finalizes after the slow window, which L2BEAT reads from the deployed contracts as 5 days; when both agree, it drops to 1 day. An attacker now has to break two unrelated systems at once.

Validity rollups: prove every batch

A validity rollup attaches a succinct proof that the state transition function was applied correctly to the data committed on L1. The verifier contract checks the proof, and the new state root is final as soon as the proof is accepted. There is no challenge window and no need for anyone to be watching. The costs move elsewhere:

• Proving cost and latency. Generating a proof takes a large amount of computation. Rollups amortize it by proving large batches, trading time to settlement against cost per transaction.
• Prover centralization. On most validity rollups in September 2026 only a permissioned prover could advance the state. L2BEAT notes, for example, that on Starknet only a whitelisted proposer can update state roots on L1. If that prover stops, settlement stops with it.
• Soundness bugs. A proof is only as good as the circuit or zkVM behind it. An underconstrained circuit can accept an invalid state as valid, silently. That is why some teams run more than one proof system: Taiko combines SP1, RISC Zero and TEEs, and Base pairs TEEs with SP1.
• What gets posted. Some validity rollups post full transactions. Others post only state diffs, which are smaller but let you rebuild balances, not transaction history, from L1. Starknet posts state diffs.

The zero knowledge guide covers what the proofs establish and what they cost to make.

The canonical bridge is the rollup

From Ethereum’s point of view, a rollup is an escrow contract. Deposits lock assets in it. Withdrawals are messages from L2 that the contract honors once a state root containing them has been accepted, checked with a Merkle proof against that root. Everything described above, the sequencer, the dispute game, the prover, exists to decide which state roots that contract should accept.

That is why upgrade keys matter more than anything else. Whoever can upgrade the bridge, the proof verifier or the contract that selects state roots can, in principle, redirect every asset the rollup holds. Tokens that arrive through a third party bridge instead of the canonical one add that bridge’s own trust model on top; see cross chain security and the beginner view in bridges explained.

L2BEAT stages in detail

L2BEAT’s stages framework grades how far a rollup has removed its training wheels. It is a maturity scale, not a security score, and L2BEAT says so on every project page. The requirements as published (last updated July 23, 2025):

In December 2025 L2BEAT proposed adding a "walkaway test" to Stage 1: the 75% property must hold even if the Security Council disappears for good, so the council can act as an emergency brake but cannot be what keeps withdrawals working. By September 2026 each project page stated whether the rollup passes it.

Where things stood in September 2026, according to L2BEAT: Base, Arbitrum One and OP Mainnet, the three largest optimistic rollups by value secured, were Stage 1 and passed the walkaway test. Their councils were 8 of 11 (co-signing with a Coinbase multisig), 9 of 12 and 10 of 13 respectively. Starknet was Stage 1 but did not pass the walkaway test. Linea and ZKsync Era were Stage 0. Only a handful of small projects had reached Stage 2, among them the Aztec network in June 2026, after its governance renounced control of the rollup contract.

Upgrade keys and the exit window

The exit window is the time users have to leave between an upgrade being announced and it taking effect. L2BEAT derives it from the upgrade delay, minus the time it takes to force a withdrawal through and settle it:

Work it through for Stage 2. With a 1 day forced inclusion delay and a 6 day 8 hour challenge period, a 30 day exit window needs an upgrade delay of at least 37 days and 8 hours. A rollup with a 7 day timelock and a 7 day challenge period has an exit window of zero: by the time you could be out, the upgrade has already landed. Security Council emergency upgrades may skip the delay at Stage 1, which is exactly why the council’s size, threshold and independence are graded.

For validity rollups the counterpart of forced inclusion is an escape hatch. In the strongest designs, if forced transactions are ignored for a set period the contract freezes and users withdraw directly against the last proven state root with a Merkle proof, no operator required. Not every rollup has one. In September 2026 L2BEAT reported that Starknet had no user callable forced inclusion function at all. Its Stage 1 rating rests on its Security Council rather than a user escape path. Checking for this is one of the fastest ways to see how much a rollup still depends on its operator.

Open designs: based rollups, shared sequencing, preconfirmations

Centralized sequencing is where rollups still depend on their operator day to day, and the alternatives are active research.

Further out, native rollups would let Ethereum verify a rollup’s execution directly through a precompile, replacing custom proof systems for EVM chains. As of September 2026 that remains at the research stage.

Evaluating a rollup in five questions

1. Where is the data?

   Ethereum blobs or calldata makes it a rollup. A committee or an external layer makes it an optimium or a validium, with a different failure mode.

2. Who can prove, and who can challenge?

   Permissionless, or an allowlist? For optimistic designs, how large are the bonds and how long is the window? For validity designs, what happens if the only prover stops?

3. How do I leave if the operator turns hostile?

   Find the forced inclusion delay and the settlement delay and add them. That is your worst case.

4. Who can upgrade, and how fast?

   Name the multisigs, their thresholds and the timelocks, then compute the exit window. The admin keys guide shows how to read them onchain.

5. What does L2BEAT say, and when did it last change?

   Read the whole project page, not just the badge. The risk summary, the permissions list and the update log carry the detail, and they change more often than the stage does.

For the chains themselves, the layer 2 directory and comparisons such as Arbitrum vs Optimism are a good starting point before you open the contracts.

Common questions

Where to go next