Who Can Actually Halt a Rollup?

The entity that orders transactions is the most common single point of failure. A malicious or compromised sequencer can censor users or halt the chain, making its decentralization the primary scaling bottleneck.

• Current Reality: Most major rollups (Arbitrum, Optimism, zkSync) use a single, permissioned sequencer.
• Mitigation Path: Progress towards decentralized sequencer sets (e.g., Espresso, Astria) or based sequencing via Ethereum proposers.

This is the entity with permission to submit state roots or transaction batches to the L1 settlement layer (e.g., Ethereum). Controlling this key is a literal kill switch.

• Security Model: In optimistic rollups, a malicious proposer can force a 7-day challenge window. In ZK rollups, a malicious prover can submit a fraudulent proof, but validity is cryptographically enforced.
• Upgrade Risk: Most implementations use a multi-sig for this role, creating a governance attack vector.

The ability to upgrade the rollup's smart contracts on L1 is the ultimate kill switch. It can change all other rules, including sequencer and proposer logic.

• Sovereignty vs. Security: App-chains (dYdX, Aevo) often retain this key, trading off trust minimization for agility. Shared settlement layers (Arbitrum Nitro, OP Stack) decentralize this over time via token governance.
• Exit Strategy: Users must trust that the key holders will honor the social contract and not abuse their power, or that a fork is possible.

Arbitrum's Security Council holds the keys to a 12-of-20 multi-sig that can upgrade core contracts and halt the chain. This is the canonical 'emergency brake' for a permissioned rollup.

• Governance-Driven: Council members are elected by ARB token holders.
• Time-Locked Actions: Emergency actions have a ~48-hour delay, preventing unilateral halts.
• Centralization Trade-off: Represents a deliberate, auditable point of control versus pure decentralization.

Optimism's upgradeable L1 Proxy Contracts allow the Foundation to unilaterally push new logic, including code that could halt state transitions. This is a 'soft halt' via governance override.

• Proxy Admin Key: Held by a 6-of-11 multi-sig managed by the Optimism Foundation.
• Fault Proof Transition: The shift to a multi-proof system (Cannon, MIPS) increases complexity and potential fault surfaces.
• Layer Zero Parallel: Similar to LayerZero's upgradeable endpoint model, where the DAO can pause message passing.

In November 2023, StarkNet experienced a ~3-hour sequencer outage. The halt was not initiated by an emergency multi-sig, but by a technical failure in the centralized sequencer node.

• No User TX Finality: Transactions were queued but not processed or proven to Ethereum.
• No L1 Force-Inclusion: The system lacked (at the time) a robust mechanism for users to bypass the halted sequencer.
• Practice vs. Theory: Highlights the gap between theoretical permissionless censorship resistance and practical reliance on a single operator.

As a zkRollup with upgradeable contracts via governance, a hostile takeover of the POL token voting mechanism could allow an attacker to push a malicious upgrade that halts the chain.

• Attack Vector: Acquire >50% voting power or exploit delegation mechanisms.
• Time Buffer: Relies on a 10-day timelock for upgrades, providing a reaction window.
• Contrast with Immutable: Unlike Immutable zkEVM (which uses a frozen, non-upgradeable model), this model trades finality for adaptability.

The entity that orders transactions is the primary liveness risk. A centralized sequencer (e.g., most current L2s) can halt the chain by simply stopping.\n- Key Risk: Censorship and chain halt are immediate.\n- Current State: Most rollups rely on a single, permissioned sequencer run by the core team.\n- Mitigation Path: Move towards decentralized sequencer sets (e.g., Espresso, Astria) or permissionless inclusion via mempools.

A multi-sig controlling the rollup's upgrade keys can unilaterally change logic, censor, or rug. This is the ultimate sovereignty point.\n- Key Risk: Malicious or coerced upgrade can rewrite history.\n- Arbitrum Example: Controlled by a 12-of-20 multi-sig, with plans to decentralize.\n- Best Practice: Timelocks, broad governance (e.g., token vote), and eventual elimination ("suicide switch").

If only one entity (e.g., the core team) runs the prover, they can stop generating validity proofs, freezing fund withdrawals.\n- Key Risk: Chain enters a "frozen" state; assets are safe but stuck.\n- ZK-Rollup Reality: Many rely on a single, permissioned prover.\n- Solution Frontier: Proof markets (e.g., RiscZero, Succinct) and decentralized prover networks.

If transaction data is posted to a secure DA layer (e.g., Ethereum, Celestia, EigenDA), users can force-exit even if all other parties fail.\n- Key Benefit: Censorship resistance and self-custody are preserved.\n- Mechanism: Users submit fraud proofs or directly reconstruct state from on-chain data.\n- Trade-off: Higher-cost DA (Ethereum) vs. newer, modular layers with lighter trust assumptions.

The canonical bridge on L1 (e.g., OptimismPortal, ArbitrumL1Inbox) validates all incoming state roots. Its upgradeability and pause functions are critical.\n- Key Risk: A pausable bridge can freeze all withdrawals, even with valid DA.\n- Audit Focus: Check for unlimited pause authority and upgrade delay.\n- Ideal State: Immutable bridge contract with only a long-timelocked security council for emergency fixes.

True liveness resilience requires progress across all vectors: sequencers, provers, governance, and DA. Prioritize based on your threat model.\n- Builder Priority 1: Decouple sequencer from core team.\n- Builder Priority 2: Secure Data Availability with a credible layer.\n- Framework: Assess each component's failure mode—halt, freeze, or theft—and its recovery path.