Rollup Security Stages & Escape Hatches

Who Really Controls Your Funds on a Rollup?

A rollup is a separate chain that runs transactions away from Ethereum and posts the transaction data back to it, while the money users deposit sits in smart contracts on Ethereum. One operator, the sequencer, receives transactions, orders them and publishes them. That is fast and cheap, but 'built on Ethereum' does not say what happens if the operator misbehaves, goes offline or is pressed to censor you. Three questions cover most of it. Can the operator block your withdrawal? Can a small group change the rules of the contracts holding the funds? Can you push a transaction in through Ethereum if the operator ignores it?

The Stage 0, 1 and 2 Ladder

In November 2022 Vitalik Buterin proposed sorting rollups into three stages by how heavily they lean on 'training wheels', meaning a group of people who can override the code if it turns out to be buggy. The rating site L2BEAT later turned the idea into a published framework. Stage 0 means the people running the project remain in full control, Stage 2 means the code is in charge and humans may step in only for provable bugs, and Stage 1 sits between the two. As of October 2026, the rollups tab of L2BEAT's summary page listed 22 projects: 4 at Stage 2, 6 at Stage 1 and 12 at Stage 0.

A Stage Is Not a Safety Grade

A stage describes who holds power, not whether the code is free of bugs. L2BEAT's own explainer warns that a team can easily deploy an unsafe project that still reaches Stage 2, for example because the proof system is experimental or the contracts are unaudited. A higher stage means fewer people can overrule the code, which is useful, but it is one input rather than a verdict.

• Stage 0: the operators can still overrule or freeze the system, so users rely on their good conduct.
• Stage 1: proofs decide which state is valid and a security council can step in, so the question is how hard that council is to corrupt.
• Stage 2: proofs are open to anyone, upgrades give users long warning, and the council acts only on provable on-chain bugs.
• Escape hatch: a route through Ethereum that lets you force a transaction in without the operator.

Forced Inclusion: Getting a Transaction In Without the Sequencer

The common escape hatch works like this: a user sends a message to a contract on Ethereum, and if the sequencer has not included it within a time limit, the rollup's rules treat it as part of the chain anyway. ethereum.org describes the same idea for optimistic rollups, where users may submit a transaction directly to the on-chain rollup contract once it has been delayed past the maximum time allowed. In Arbitrum, deposits and retryable tickets enter through the parent chain's delayed inbox, and the Sequencer Inbox has a forceInclusion method. As of October 2026, Arbitrum's documentation gives the force-inclusion window as the lesser of a delay buffer and a constant of 7200 blocks, which it equates to 24 hours.

The Optimism Version

OP Stack chains use a different door. Optimism's documentation says users can always bypass the sequencer by calling the depositTransaction function on the OptimismPortal contract on Ethereum. As of October 2026, it states that such transactions are processed in the order received and within the sequencer window, set to 12 hours by default but able to differ from chain to chain. If the sequencer is down or fails to publish in time, the chain automatically reorganises to include them. The same page separates a downtime outage, where the sequencer cannot process anything, from a submission outage, where it processes transactions but cannot publish them to Ethereum. It also admits that once a sequencer returns, putting portal transactions first is typical but not a rule.

Reading the Council and the Exit Window

Escape hatches protect against a censoring operator; the council and exit window protect against changed rules. The Security Council is a multisig able to act in emergencies. As of October 2026, L2BEAT's specification, whose latest changelog entry is dated 30 April 2026, asks for at least 8 participants and a 75% threshold, counts addresses controlled by one entity as a single signer, and wants identities disclosed. Upgrades started by anyone outside the council are allowed at Stage 1 if they give an exit window of at least 5 days, meaning the time users get to leave before an unwanted upgrade takes effect. Whereas those outside actors must give notice, L2BEAT's summary page states that the council may upgrade a Stage 1 rollup instantly.

The Exact Requirements and Where They Came From

The 2022 proposal on Ethereum Magicians required, at Stage 0, a rollup full node that anyone could run and machinery letting users withdraw without the operator's cooperation, so that a false state root was the operator's only tool. As of October 2026, L2BEAT's source-of-truth post on its forum lists six Stage 0 questions: the project calls itself a rollup, state roots are posted on Ethereum, data availability is on Ethereum, software able to rebuild the state is source-available, a proper proof system exists, and at least 5 external actors can submit a fraud proof. The post's changelog records that the 5-challenger rule moved from Stage 1 to Stage 0 on 20 June 2025.

Stage 1 and Stage 2 in Detail

As of October 2026, the Stage 1 test centres on one property: other than through bugs, the only way to block an L2 to L1 message indefinitely, or to push an invalid one through, is to compromise at least 75% of the Security Council. If anyone with enough resources can propose, L2BEAT assumes at least one live proposer and does not assume it is non-censoring. Stage 2 adds permissionless fraud proofs, a 30-day exit window for unwanted upgrades including DAO upgrades, and a council confined to errors detectable on chain, such as two valid but contradictory proofs for the same batches. The 2022 proposal asked for 6-of-8 and a seven-day upgrade delay at Stage 1; the present text keeps the 8-member, 75% floor but adds rules such as counting one entity's addresses once.

Challenge Periods and Proof Types

An optimistic rollup is safe only if someone can post a fraud proof on Ethereum, and a censored proof could let a bad withdrawal through. That is why challenge periods exist. L2BEAT's forum post of 30 April 2026 cut the Stage 1 minimum challenge period from 7 days to 5, reasoning that, with strong 51% censorship attacks set aside, one day covers economic censorship games and four days cover network delays, while the 7-day bound for Stage 2 stays. For a validity-proof (zk) rollup, L2BEAT's Stage 0 text says the proof system is required to accept a state root, so the exposure shifts from a challenge window to the correctness of the proof system.

What the Ladder Leaves Out

L2BEAT states that a Stage 2 project can still be unsafe, and cites Vitalik Buterin's 2025 analysis of when Stage 1 and Stage 2 make sense, which weighs the chance of a bug against the chance that permissioned actors are compromised. The framework also asks whether data availability is on Ethereum, so a project whose data sits with a committee or another network fails that Stage 0 question. L2BEAT's own pages also differ on one figure. On 27 October 2026 its explainer page, last updated on 23 July 2025, and the glossary in its summary page still gave 7 days for the Stage 1 exit window, while the forum specification, which calls itself the source of truth, gave 5, and this page follows the specification.