A rollup's safety depends on who controls its sequencer and keys

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

Two different security claims live in one sentence

A rollup is often described as inheriting Ethereum's security. That is true of one part: once a rollup's state transitions are posted and, for an optimistic rollup, survive a challenge period, or are backed by a validity proof, Ethereum's consensus secures that record. Ethereum's own documentation, retrieved 16 September 2026, is explicit that this depends on an assumption: 'the validity of the chain relies on the existence of one honest node' willing to submit a fraud proof during the challenge window. Everything upstream of that record, including who decides what goes into a block and in what order, is a separate and narrower claim.

The sequencer is a single point today

Almost every production rollup runs one sequencer, an operator with, in Arbitrum's own description, 'priority access to the rollup chain' for ordering transactions. Arbitrum's documentation states plainly that this sequencer 'is currently centralized', with decentralization described as a future direction rather than a present fact. If a sequencer censors or goes offline, a user is not simply stuck: Arbitrum's delayed inbox lets a transaction be force-included directly on Ethereum after a wait, a 'censorship timeout' the documentation says can range from thirty minutes to forty-eight hours depending on recent behaviour. That escape hatch is the mechanism that keeps censorship from being permanent, and its existence and delay length are exactly what should be checked for any given rollup, since it is not standardised across projects.

Contracts and keys are the boundary a general description skips

L2Beat's risk framework, as retrieved 16 September 2026, tracks rollups individually against categories including sequencer failure and proposer failure, precisely because these vary project to project and are not settled by calling something 'a rollup'. A rollup's bridge and state-update contracts are typically upgradeable, controlled by a key or a multisig; who holds that key, whether a timelock delays its use, and what it can change are questions a fraud-proof system does not answer on its own. An upgrade key that can alter the verification logic is, in practice, a way to override the very guarantee the rollup advertises. This is an editorial framework, not a report on any single project's current configuration, and it can go stale as governance changes.

Questions to carry forward

• Who holds the contract upgrade keys for a given rollup, and is there a timelock on their use?
• What is the current force-inclusion delay if the sequencer stops accepting transactions?
• Has the fraud-proof or validity-proof system for this rollup been exercised in production, or only assumed?

Inheriting Ethereum's security is a real but partial claim. The sequencer, the upgrade keys and the exit path are the specific, checkable pieces that decide how much of that inheritance actually reaches a given user.