Quick Answer
Optimism's OP Stack has become the dominant optimistic rollup framework — with Base alone holding $3B+ in TVL. Security vulnerabilities in shared OP Stack components affect every chain in the Superchain simultaneously.
OP Stack chains (Optimism, Base, Mode, Zora) share the CrossDomainMessenger and OptimismPortal bridge contracts. A vulnerability in shared infrastructure affects all Superchain chains simultaneously — making the bridge contracts the highest-priority audit target in the OP ecosystem.
Each OP Stack chain has its own centralized sequencer. Optimism's sequencer is operated by OP Labs; Base's by Coinbase. Sequencer failures cause L2 downtime. DeFi protocols depending on time-sensitive operations (liquidations, TWAP updates) face sequencer availability risk.
Optimism blocks are produced approximately every 2 seconds — 6x faster than Ethereum. Contracts using block.number for time-based logic will behave differently than on Ethereum. Governance windows, vesting periods, and TWAP windows all need adjustment for OP Stack chains.
L2-to-L1 withdrawals require 7 days to finalize on Ethereum. Fast bridges (Hop, Across, Stargate) solve UX but introduce bridge security risk. Protocols needing immediate Ethereum-side asset availability after an Optimism withdrawal must use third-party bridges.
| Vulnerability | Severity | Description | Example |
|---|---|---|---|
| Sequencer Centralization and Censorship | High | Optimism Mainnet's sequencer is operated by OP Labs — a single centralized entity. A sequencer can frontrun user transactions, censor specific addresses, or go offline and halt L2 operations. The Superchain vision includes multiple OP Stack chains (Base, Mode, Zora, etc.) each with their own sequencer, adding coordination risk across chains sharing bridge infrastructure. | A DeFi protocol on Optimism that depends on liquidations firing within a specific block window — a sequencer outage prevents liquidators from acting, creating bad debt that isn't collateralized at the expected price. |
| 7-Day Withdrawal Finality Attack | High | Like Arbitrum, Optimism uses a 7-day optimistic challenge period for L2-to-L1 withdrawals. During this window, L1 assets are not finalized. Protocols that need immediate Ethereum-side asset availability after an Optimism withdrawal must use fast bridge protocols — which introduce their own bridge security risks. The challenge window is designed for fraud proof submission, not as a delay for its own sake. | A cross-chain treasury contract that moves funds from Optimism to Ethereum expecting same-day availability — the 7-day challenge window means the treasury function fails or must use a third-party bridge, adding counterparty risk. |
| OP Stack Cross-Chain Bridge Risk | High | The OP Stack's canonical bridge moves assets between Ethereum L1 and Optimism L2. The bridge contract on Ethereum holds all L1 assets deposited to Optimism — a critical attack surface. Additionally, the Superchain's shared bridge contracts coordinate across multiple OP Stack chains (Base, Mode, Zora). A vulnerability in the shared bridge affects all connected chains simultaneously. | A vulnerability in the OP Stack's CrossDomainMessenger contract — used by the canonical bridge — would allow an attacker to forge L1-to-L2 messages, minting unbacked tokens on Optimism from nothing. |
| block.number and block.timestamp Semantics | Medium | On Optimism Mainnet, block.number returns the Optimism block number (not Ethereum's), and blocks are produced much faster than Ethereum. Contracts that use block.number for time-based logic will produce different results on Optimism than on Ethereum mainnet. The same issue applies to all OP Stack chains including Base. | A governance contract with a 100-block voting period deployed on both Ethereum and Optimism — on Ethereum, 100 blocks ≈ 20 minutes; on Optimism, 100 blocks ≈ 2 minutes, making the governance window impractically short. |
| Fault Proof System Race Condition | Medium | Optimism's fault proof system (Cannon/MIPS) allows challengers to dispute invalid state roots submitted by the sequencer. A vulnerability in the fault proof game mechanics could allow a malicious actor to invalidate correct state roots or prevent valid challenges from succeeding, potentially allowing invalid withdrawals to be finalized after the challenge window. | A bug in the dispute game's bisection protocol that allows a malicious challenger to stall the bisection indefinitely — preventing a legitimate dispute from resolving within the challenge window and allowing an invalid state root to become final. |