Beyond Stage 2: The Case for Unstoppable Ethereum Rollups

By Tom Lehman, co-founder of Facet

Introduction

Ethereum rollups secure tens of billions in user assets, yet almost all can be halted or censored by a handful of privileged keys. At the same time, these systems advertise that they will eventually “inherit L1 security”—a promise that, as Vitalik Buterin put it, “assets on the L2 are safe and can be withdrawn as long as the L1 is secure.”

Because users cannot withdraw from a stopped rollup, Unstoppability is a prerequisite for inheriting Ethereum’s security. Yet the community’s rollup Stages Framework never targets Unstoppability: even its end-state (Stage 2) lets administrators halt a rollup so long as they give users a 30-day exit window.

We define an Unstoppable Rollup as a rollup that takes the alternate approach: a rollup that cannot be interrupted without compromising the L1. No exit windows, no security councils.

This paper has three parts:

• Stage 1 Case Study: Base. Exactly how the largest OP Stack chain can be halted today, and the changes required to make it unstoppable.
• Stage 2 Exit-Window Analysis. Why a 30-day exit window still leaves users exposed to asset loss.
• Path Forward. Proposals for achieving rollup unstoppability.

This research was funded by an Ethereum Foundation grant. Join the movement:

• Unstoppable Rollups on Telegram
• Unstoppable Rollups on Twitter

How to Stop a Rollup

Definitions

A rollup is considered stopped when any of the following conditions holds:

• Block production ceases entirely
• An account or class of transactions is censored for a prolonged period
• The gas token is manipulated so that normal users cannot purchase block space

Our focus is rollup protocols with built-in administrative controls that enable chain halts—not stoppage achieved through exploits or denial-of-service attacks. We are specifically concerned with forced stoppage (changes imposed without user consent) rather than voluntary migrations where users choose to follow a fork with different rules.

Unlike Ethereum L1, which defines its protocol rules entirely in node software (“off-chain governance”), rollups implement key protocol rules in L1 smart contracts. This “on-chain governance” enables administrators to modify the protocol without requiring users to voluntarily update their software.

In certain cases this is uncontroversial. For example, some rollups manage their sequencer's address with an L1 contract. Here's how it works: rollup nodes read from this “system configuration contract” every block to determine the current authorized sequencer address and when processing batches only accept transactions from that source.

This is useful because if the sequencer's address needs to be changed, admins can simply update the address in the contract. Nodes automatically pick up the new value without requiring a coordinated fork—an elegant solution for this specific case.

In addition to predefined configuration options, however, many rollups rely on L1 smart contracts that are arbitrarily upgradeable. While users can plan around certain predefined capabilities (like updating the sequencer’s address), upgradeable contracts can be modified to add entirely new capabilities that weren't initially contemplated.

This architecture creates specific vectors for forced stoppage, as we'll see in our case study of Base.

Stopping Base (The Largest OP Stack Rollup)

Base is the largest Optimism rollup and therefore a useful yard‑stick for “Stage 1 security.” Everything below is generic to any OP‑Stack chain.

We first examine stopping Base by disabling its sequencer through a configuration change:

• Contract: SystemConfigProxy
• Keys required: 3 of 14 (Base Multisig 1)
• Action: call setBatcherHash(bytes32(0))

A single L1 transaction signed by any 3 of the 14 keys is enough to swap the sequencer to an address with no known private key. Rollup nodes will enforce the change from the next L2 block.

Even without multisig intervention, the current sequencer can unilaterally censor or halt the chain. This vulnerability has already manifested in the broader rollup ecosystem:

• In June 2024 Linea responded to a DEX hack by halting block production and censoring attacker accounts.
• In January 2025 Sonieum blocked trading of the potentially trademark-infringing memecoin $AIBO.

Forced Inclusion: A Partial Solution

While disabling the sequencer halts ordinary transactions, OP Stack rollups implement a backup mechanism called Deposit Transactions (referred to informally as “forced inclusion”). This allows users to submit transactions directly through an L1 contract, bypassing sequencer censorship.

Forced inclusion is implemented via the depositTransaction function on the OptimismPortal2 contract. When called, this function emits a TransactionDeposited event instructing rollup nodes to include the transaction within the 12 hour sequencing window.

Limitations and Vulnerabilities

In the OP Stack forced inclusion has a few major weaknesses:

1. Constrained Gas. Base, and all OP Stack rollups, limit the amount of L2 gas available to forced transactions. Base limits deposit transactions to buying 20M L2 gas units every L1 block. Base’s current total gas limit is 140M or 840M gas per L1 block (Base’s block time is 2 seconds). In a forced transaction-only scenario, per-L1 block throughput drops from 840M gas to 20M gas, or almost 98%. This is not a complete stoppage but it could be a functional stoppage if many Base users race to exit at the same time.
2. The Handoff Problem. The sequencer retains significant control by determining when forced transactions are included and which transactions appear before and after them. This gives the sequencer great power to interfere with user goals when they involve contentious state, even when user transactions cannot be literally censored.
3. Contract Upgrade Risk. Most critically, forced inclusion itself can be disabled through contract upgrades. While it protects against a hostile sequencer, forced inclusion offers no protection against hostile admins who can upgrade the OptimismPortal2 contract.

On Base, such upgrades require approval of the following multisig wallets which can be accomplished with as few as 15 signatures:

• Base Security Council (threshold: 7 / 10)
• Base Multisig 2 (3 / 6)
• OpFoundationOperationsSafe (5 / 7)

Total distinct keys: 7 + 3 + 5 = 15.

This vulnerability isn’t purely theoretical. In March 2024, Blast used a contract upgrade to block three addresses from force-including transactions, preventing them from withdrawing allegedly stolen funds.

Making Base and the OP Stack unstoppable would be technically straightforward: simply remove the ability to disable forced inclusion or change its resource metering parameters (such as the 20M per-L1 block gas purchase limit) via contract upgrade.

However, this isn't the path Base and the rest of the Ethereum rollup community have chosen. Instead, they've opted to mitigate shutdown risk via exit window rather than eliminate it entirely.

Stage 2 and Exit Windows

The Ethereum community's answer to rollup upgrade risks is the Stages Framework which mandates that rollups eventually implement 30-day exit windows before significant protocol changes in lieu of forbidding forced shutdown and censorship entirely.

This approach fundamentally differs from Ethereum L1's security model: while Ethereum cannot be stopped by any group, Stage 2 rollups merely promise users time to exit before forced changes. We argue that this gap is not purely theoretical and its practical ramifications manifest in three weaknesses:

1. Prohibitive Exit Costs. Mass exits during a 30-day window could impose enormous costs on users, creating an asymmetric advantage for attackers who can trigger such exits with minimal expense.
2. Application-Level Constraints. Many assets are locked in smart contracts with their own withdrawal schedules and restrictions, which may not align with the exit window. A user with tokens in a 90-day vesting contract, for instance, could find their exit window entirely blocked.
3. L2-Native Asset Complexity. While bridged assets have clear L1 equivalents, L2-native assets face fundamental challenges during forced exits. Converting complex L2 financial positions to L1 representations involves technical and social coordination problems that may be impossible to solve within a fixed timeframe.

These limitations suggest that exit windows, while better than nothing, fall far short of providing L1-equivalent security.

The Problem With Exit Windows

Withdrawing Bridged Assets

Consider first the cost of withdrawing bridged assets in a mass exit scenario. In a recent post, Vitalik Buterin modeled such a scenario. Applying his assumptions, we arrive at the following cost model for exiting:

• Cost per asset withdrawal per user: $30 (assuming 120k L1 gas per withdrawal, 100 gwei L1 gas price, 36M L1 gas limit, and a $2,500 ETH price)
• Potential total cost to the community: $900 million (assuming 3M users, each holding 10 assets)

Even under ideal conditions, users collectively spend nearly a billion dollars to secure their assets. Meanwhile, an attacker pays only a small Ethereum transaction fee to initiate the hostile upgrade. This asymmetry enables two attack vectors:

• Pure Disruption: Force a shutdown with minimal cost.
• Governance “Tax”: Demand a fee lower than the user’s exit cost, effectively extorting them.

Increasing Ethereum’s gas limit could lower individual withdrawal costs, but does not solve the fundamental cost imbalance—especially given ongoing demand for L1 blockspace.

Contract Lockups: Timing Misalignments

A more fundamental problem facing the 30-day exit window’s effectiveness is that most assets aren't sitting idle in user wallets but are actively deployed in smart contracts, some of which have their own withdrawal constraints. These contract-level restrictions create additional “withdrawal windows” that must align with the protocol's exit window.

Consider a vesting contract that releases tokens weekly. In a hostile governance upgrade, users must exit during the overlap of the 30-day exit window and their contract’s withdrawal schedule. With weekly vesting, the effective window might shrink to about 23 days; quarterly vesting could eliminate it entirely.

Perpetual futures illustrate a more challenging case. These derivatives have no expiration and rely on continuous margin checks and funding payments tied to real-time market conditions. Unlike halted vesting contracts perpetual markets cannot be fairly “paused and resumed,” because ownership of assets depends on real-time user actions and market fluctuations, neither of which can be accurately reconstructed retroactively.

Users must either avoid dynamic DeFi protocols—negating a core benefit of rollups—or attempt to migrate entire DeFi states back to Ethereum L1 under time pressure. That migration is both costly and complex, involving addresses, contract state, and execution context changes.

“Withdrawing” Native Assets

When you withdraw an L1-bridged asset from an L2, the L1 contract already holds that asset in escrow. The rollup provides trust-minimized proof of ownership, and the L1 contract can transfer the asset back to its rightful owner. This is an unambiguous “withdrawal.”

However, L2-native assets (assets minted on the L2) have no L1 equivalent escrowed. Even if the L2 supplies trust-minimized state data showing “Alice owns 100 tokens,” there’s no single “correct” way to represent those tokens on the L1.

One natural approach is an “automatic ERC20 factory” like the OptimismMintableERC20Factory that creates or mints a generic new L1 token whenever an L2 user tries to withdraw. This would preserve L2 token ownership information, provided there is social consensus on which of the possible L1 tokens is the “correct” L1 representation.

However, a token’s value hinges on its behavior and internal logic, not merely the mapping of who owns how many tokens. Therefore, for a true L2-issued asset “withdrawal,” we need an L1 representation of its behavior in addition to its internal state.

Challenges Representing L2-Issued Assets on the L1

L2s have fundamentally different execution environments with unique chain IDs, block times, gas limits, and opcode behavior. These contextual differences, accessible to L2 contracts via EVM opcodes, make direct L1 replication impossible.

Another source of indeterminacy arises when an L2-issued asset’s internal state references specific L2 contract addresses. The same address on L1 might point to a blank account or an unrelated contract with different logic. If an L2 token internally references (for example) an L2 liquidity pool contract at address X, a naive attempt to “port” that balance to L1 could render those tokens unusable if X is a different contract (or a blank account) on the L1¹.

Finally, there’s the practical issue of cost. Earlier, we estimated withdrawal costs per user, per asset. But lower L2 transaction fees encourage richer interactions and far more state than just asset balances. Migrating this larger state back to L1’s limited and expensive storage quickly becomes prohibitively costly, especially in a fixed time window.

Social Consensus & L2 Asset Dependencies

L2‐native tokens are often integrated into DeFi via:

• Collateral in Lending Protocols
• Wrapped Derivatives
• Liquidity Pairs with L1 Assets

Each integration adds another stakeholder whose agreement is required for any L1 token representation to be accepted. For example, a lending protocol cannot accept a new version of collateral without agreement from its borrowers and lenders.

The complexity introduced by these dependencies creates systemic risk. If stakeholders fail to reach consensus on a new L1 representation:

• The L2 asset may become effectively worthless due to uncertainty about its canonical representation
• This can trigger liquidations in protocols using it as collateral
• Liquidations may impact other assets paired with or dependent on the L2 token
• The effects can cascade through the broader DeFi ecosystem, potentially affecting even protocols with no direct exposure

A hostile governance upgrade provides an ideal trigger for such a cascade. As Vitalik Buterin notes:

If an L2 goes through a hostile governance upgrade, then an ERC20 launched on that L2 could start issuing an unlimited number of new tokens, and there would be no way to stop those tokens from leaking into the rest of the ecosystem.

Issuing Assets on L1: A Workaround?

Vitalik proposes issuing assets on L1² and bridging them to L2 to preserve a canonical withdrawal path, but this faces significant limitations. Many tokens have already been issued on L2s, and migrating them would require complex redeployment and user coordination. More fundamentally, even L1-issued assets become exposed to L2 governance risk the moment they interact with any L2-native component in DeFi protocols.

L2-Native Asset Adoption

Hayden Adams, creator of the Uniswap protocol and Unichain rollup, said this in response to Vitalik’s suggestion:

You can issue an asset on L2, and the L2 is still using L1 for [data availability] + execution proofs, and the asset can still be withdrawn to L1 if the L2 fails

Many / most assets should and will be issued on L2 bc it's expensive to do on L1 and there are going to be many assets

Let's not create the incorrect narrative that L2 native assets are bad for ethereum when they're actually critical for ethereum to succeed on its current roadmap

While we've shown that his claim about L2 assets being withdrawable to L1 holds only in limited cases, his broader point stands: economic forces will drive most new assets to launch directly on L2s, where deployment and transaction costs are dramatically lower.

Achieving Unstoppability

Exit windows impose substantial burdens on users. To protect themselves from hostile upgrades, users must:

• Monitor governance actions and be prepared to withdraw on short notice
• Accept losing assets whose withdrawal costs exceed their value
• Avoid contracts with time-locked assets that might restrict withdrawals
• Issue assets on L1, or accept heightened risks with L2-native assets

Enter Unstoppable Rollups. But how to build them?

Recall the various “stoppability” vectors trace back to rollups’ reliance on L1 smart contracts that can be upgraded (or reconfigured) at any time. To make a rollup unstoppable, we must eliminate or drastically reduce the ability for privileged L1 contracts to alter sequencing or gas issuance.

There are three primary architectural approaches to eliminate these administrative control vectors:

1. Immutable L1 Contracts: Use L1 contracts for bridging/sequencing but make them non‐upgradeable. When protocol upgrades are needed, deploy a new rollup with new immutable contracts. Users who want the upgraded logic must withdraw from the old rollup and redeposit into the new one. While inconvenient, the old rollup never forcibly shuts down.
2. Sovereign Rollups (No L1 Contracts for Core Logic): Eliminate reliance on L1 contracts entirely and define the rollup’s state transition function entirely off-chain. Sovereign rollups rely on social consensus for upgrades and handle bridging as an application-layer function without any privileged canonical bridge. Unstoppable sovereign rollups often adopt a native gas token to remove dependence on an L1 bridge contract.
3. Native Rollups (Validation Integrated with Ethereum Protocol): Embed rollup validation logic directly into Ethereum’s protocol. Here, Ethereum’s social consensus governs upgrades via L1 hard forks—no single rollup admin has the power to force changes. This enables native rollups to use immutable L1 contracts without requiring users to withdraw and redeposit on protocol upgrades. Native rollups promise the most UX-friendly path to unstoppability, but require major Ethereum protocol modifications.

Each of these approaches removes the possibility of forced halts or censorship. We will explore these architectures in detail in a future paper.

The Limits of Unstoppability

Unstoppable rollups provide certain guarantees regarding liveness and censorship resistance at the protocol level. However, this doesn't necessarily translate into better outcomes for users, since they interact with applications built on the protocol, not the protocol alone. If a user’s assets are compromised due to application-level stoppability, they won't find much comfort in knowing the underlying protocol was unstoppable.

For example, with L1-bridged assets or centralized L2-issued assets like USDC, no rollup protocol can protect users from censorship. Moreover, due to the contagion effect, such censorship can affect even unstoppable assets.

This weakness applies to L1 as well. If USDC on L1 were compromised, it could potentially bring down the entire network on a practical level. Therefore, being unstoppable should be viewed as a prerequisite for a secure user experience, not a sufficient condition on its own.

Conclusion

There is a fundamental difference between the protections afforded by a 30-day exit window and those afforded by an Unstoppable Rollup. At the same time, achieving unstoppability requires trade-offs whose costs might outweigh the benefits of these higher protections. For this reason, Unstoppable Rollups are not necessarily “better” for all users or use cases.

However, for scenarios in which the unconditional inheritance of L1 security is paramount—such as high-value DeFi applications or politically sensitive transactions—Unstoppable Rollups offer the strongest possible guarantees.

In upcoming work, we will delve deeper into immutable contract rollups, sovereign rollups, and native rollups, comparing their complexities, performance, and governance implications. Ultimately, our goal is to give the Ethereum community a practical roadmap toward truly unstoppable L2 systems, empowering users to choose the security model that fits their needs.

Special thanks to Norswap, donnoh.eth, Kev, jesus.eth, Ilia Shirobokov, Max Gillett, mteam.eth for feedback.

About the Author

Tom Lehman is the co-founder of Facet, an Unstoppable Rollup. He previously co-founded Genius.com where he served as CEO from 2009–2021.