Why Rollup Security Is Not Automatic

A single sequencer creates a centralized point of censorship and failure. Users have no direct recourse if their transactions are censored or reordered.

• Censorship Risk: A malicious or malfunctioning sequencer can block transactions.
• Liveness Dependency: Downtime halts the entire rollup.
• MEV Extraction: Centralized sequencers can front-run user trades with impunity.

Optimistic rollups have a 7-day challenge window where funds are locked. This creates capital inefficiency and assumes a vigilant, well-funded watchdog exists.

• Capital Lockup: $10B+ in TVL can be frozen during disputes.
• Watchdog Assumption: Security depends on altruistic or incentivized parties to submit proofs.
• Data Availability: Fraud proofs are useless if the underlying data isn't available, a risk mitigated by solutions like EigenDA or Celestia.

Most rollups use multi-sig upgrade keys controlled by a small team, creating a centralized escape hatch that can override all other security mechanisms.

• Admin Key Control: A small group can change the rollup's code arbitrarily.
• Timelock Reliance: Security often depends on a timelock delay, not cryptographic guarantees.
• Governance Delay: Truly decentralized governance (like Arbitrum DAO) is rare and slow to implement.

The canonical bridge holding user funds is a high-value target. Its security is only as strong as the rollup's weakest component (sequencer, DA, proofs).

• Centralized Withdrawals: Bridges often rely on the same centralized sequencer for proving withdrawals.
• Proof System Integrity: A bug in the ZK prover (zkSync, Starknet) or fraud proof system can drain the bridge.
• Escrow Risk: Billions are held in escrow contracts, a prime target for exploits.

If transaction data isn't posted to the parent chain (Ethereum), a rollup cannot be reconstructed or verified. Relying on a separate DA layer (Celestia, EigenDA) introduces new trust assumptions.

• Ethereum DA Cost: High cost pushes rollups to alternative DA layers.
• Security Trade-off: Using a less secure DA layer reduces the rollup's overall security to that layer's level.
• Bridging Complexity: Cross-rollup communication (LayerZero, Axelar) depends on the security of each rollup's DA solution.

Validity proofs (ZK) remove the need for fraud proofs but introduce new risks: prover centralization, complex trusted setups, and verifier contract bugs.

• Prover Centralization: Most ZK rollups rely on a single, centralized prover service.
• Trusted Setup: Some systems require periodic ceremonies, a potential point of failure.
• Verifier Bug: A bug in the on-chain verifier contract, as seen in early Polygon zkEVM audits, could validate incorrect state transitions.

Most rollups use a single, centralized sequencer for transaction ordering and execution. This creates a critical vulnerability.\n- Censorship Risk: The sequencer can exclude or reorder user transactions.\n- Liveness Risk: If the sequencer goes offline, the entire chain halts.\n- Centralized Profit Extraction: MEV is captured by a single entity, creating misaligned incentives.

Optimistic rollups rely on a fraud-proof window (typically 7 days) where anyone can challenge invalid state transitions. In practice, this fails.\n- No Live Fault Probes: Major networks like Arbitrum and Optimism run without permissionless, live fault proofs.\n- High Capital Requirements: Challengers must bond significant capital, disincentivizing participation.\n- Complexity Attack Surface: The fraud-proof logic itself is a massive, untested attack vector.

Rollup security collapses if transaction data isn't reliably posted to the parent chain (Ethereum). This is the Data Availability (DA) problem.\n- High Cost: Paying for calldata on Ethereum is the primary expense, forcing compromises.\n- Off-Chain DA Risks: Using external DA layers like Celestia or EigenDA trades Ethereum's security for a weaker, untested cryptoeconomic guarantee.\n- Withholding Attacks: A malicious sequencer can withhold data, making fraud proofs impossible.

Rollup smart contracts on Ethereum have admin keys that can arbitrarily change the protocol's rules. This is a backdoor.\n- Code is Not Law: A multisig can upgrade contracts to steal funds or censor users, breaking the "trustless" promise.\n- Governance Theater: Decentralized governance often controls the multisig, but voter apathy leads to effective centralization.\n- Timelocks Are Not Enough: A delay (e.g., 10 days) is insufficient if the attacker is the sanctioned entity itself.

Users interact with rollups via bridges, which are often the most exploited component in the stack (see Wormhole, Nomad, PolyNetwork).\n- Complex Trust Assumptions: Bridges rely on oracles and multisigs for cross-chain messaging.\n- Liquidity Fragmentation: Canonical bridges hold billions in TVL, creating a massive honeypot.\n- Asymmetric Risk: A bridge hack can drain the rollup even if its execution layer is perfectly secure.

ZK-Rollups replace fraud proofs with validity proofs, but the proving process is highly centralized.\n- Hardware Oligopoly: Generating ZK proofs requires specialized, expensive hardware (GPUs, FPGAs), leading to a few dominant prover services.\n- Cost Barriers: The capital cost to become a competitive prover is prohibitive, stifling decentralization.\n- Prover Censorship: A centralized prover cartel could refuse to prove certain transactions.