Rollup Security Assumptions Teams Ignore

Teams treat the sequencer as a trusted component, ignoring its centralized control over transaction ordering and censorship. This creates a silent reorg risk and MEV extraction vector that invalidates L2's decentralized promise.

• Risk: A malicious or compromised sequencer can censor, front-run, or reorder transactions for >51% of blocks.
• Blind Spot: Most users and dApps have zero recourse during sequencer downtime, forcing reliance on slow, expensive forced inclusion.

Security is outsourced to a handful of prover nodes, creating a bottleneck. If the primary prover fails or acts maliciously, the entire chain halts. Coupled with reliance on a centralized data availability (DA) layer like a single cloud provider, this reintroduces the very trust assumptions rollups were meant to eliminate.

• Bottleneck: ~3-5 entities often control the proving infrastructure for major chains.
• DA Risk: If the chosen DA layer (e.g., Celestia, EigenDA, a centralized RPC) censors or goes offline, the rollup's state cannot be verified.

Multi-sig upgrade mechanisms controlled by the founding team are treated as temporary but become permanent fixtures. This creates a governance fault line where a small group can unilaterally change protocol rules, steal funds, or alter security parameters, making a mockery of "decentralized" L2s.

• Reality: Most rollups have <10-of-N multisigs with known entities, not decentralized on-chain governance.
• Consequence: A single bug in the upgrade logic or a malicious signer coalition can compromise $10B+ in TVL in minutes.

The upgrade delay is your only defense. A 7/10 multi-sig with a 0-day delay is effectively centralized. Teams treat the delay as a governance feature, not a security parameter.

• Key Risk: Signer collusion or compromise leads to instant chain takeover.
• Key Mitigation: Enforce a minimum 7-day delay for all upgrades, even for "emergency" fixes.

Relying on Ethereum calldata or an external DA layer like Celestia or EigenDA introduces a new liveness assumption. If DA fails, your chain halts. If you fall back to an off-chain data committee, you've reintroduced a trusted setup.

• Key Risk: Chain halts if the chosen DA layer goes down.
• Key Mitigation: Model DA failure scenarios and have a clear, decentralized recovery path documented.

Your rollup's security depends on L1 block inclusion. MEV-Boost and proposer-builder separation on Ethereum mean your critical fraud or validity proofs are at the mercy of a handful of builder entities like Flashbots. Censorship is a real threat.

• Key Risk: A malicious builder can delay or censor your rollup's state updates.
• Key Mitigation: Implement multiple proof submission channels and consider inclusion lists to bypass builder markets.

Your native bridge is the most attacked component. Most teams treat it as a simple messaging layer, ignoring its role as the sole custodian of all bridged assets. A bug here is equivalent to a chain compromise.

• Key Risk: Single bug can drain the entire bridge's TVL.
• Key Mitigation: Formal verification of bridge contracts, time-locked upgrades, and multi-chain state proofs.

Everyone plans for a malicious sequencer. Few plan for a catastrophic offline event. If your sole sequencer goes dark, your chain is frozen. The "decentralize later" roadmap is a pledge to execute a complex, untested governance hard fork under maximum stress.

• Key Risk: Chain death due to operational failure, not cryptography.
• Key Mitigation: Run a decentralized sequencer set from day one, even if permissioned, with clear failover procedures.

Assuming users or altruists will run full nodes or watchtowers to challenge invalid state is naive. The economic incentive to challenge is often negative (cost > reward) or too slow. Projects like Arbitrum learned this, prompting their BOLD research.

• Key Risk: A fraudulent state can go unchallenged, making safety guarantees theoretical.
• Key Mitigation: Design staked, incentivized challenger roles with slashing, or move to validity proofs (ZK).