What "inherits Ethereum security" actually means
A Layer 2 system inherits Ethereum's security only for the operations whose validity Ethereum verifies. Some L2s verify state transitions on Ethereum via fraud proofs. Some verify via validity proofs. Some verify nothing and rely on their own validator set. Calling all of these "Ethereum-secured" is a marketing claim, not a technical one.
The four architectures below differ in what they post to L1, how they prove correctness, and what they trust off-chain. The differences are where the security lives.
Optimistic Rollups
Optimistic Rollups post state roots to L1 and assume them valid unless someone proves otherwise during a fraud-proof window. The security model rests on three properties.
Fraud-proof window. Typically seven days. Until the window expires, any honest party can submit a proof that the posted state is wrong, and L1 will roll back the bad state.
At least one honest watcher. If no one is watching during the window, a malicious sequencer can post a wrong state and walk away with the funds after the window closes. The L1 contract has no way to know the state was wrong.
L1 censorship resistance for fraud proofs. A malicious sequencer that can also censor L1 inclusion of fraud proofs (via paying out of band, attacking the prover network, or colluding with block builders) can defeat the proof window.
Production Optimistic Rollups still run on permissioned sequencers. The "one honest watcher" assumption today is largely the multisig that operates the system. The fraud-proof game is live in theory; it has not been exercised under adversarial conditions for the largest L2s. L2BEAT classifies rollup maturity in three stages; almost no production L2 has reached Stage 2 (where the multisig has no power to override fraud proofs).
The security boundary: as good as the multisig that runs the sequencer and the prover network combined. Calling this "as secure as Ethereum" is overstating.
ZK-Rollups
ZK-Rollups post state roots to L1 alongside a validity proof. L1 verifies the proof on-chain. If the proof is valid, the state transition is correct by construction.
The security model rests on:
The proof system. SNARKs, STARKs, or hybrid. Bugs in the prover or the verifier circuit produce a state transition that L1 accepts as valid but is in fact wrong. Circuit auditing is its own discipline; circuit-implementation bugs have been found and patched on production ZK-Rollups.
Trusted setup, for some systems. Some SNARK systems require a trusted setup ceremony. If the ceremony was compromised (one participant retained the toxic waste), the prover can forge proofs. Modern ceremonies are multi-party and assumed secure under at-least-one-honest-participant.
Prover availability. A ZK-Rollup cannot advance without a prover. If the prover network is centralized and goes down, withdrawals stop. Most production ZK-Rollups run a single prover or a permissioned set.
Data availability. State roots without underlying data are not useful. When data availability is off-chain (Celestia, EigenDA, Avail, or proprietary committees), the security boundary shifts to that DA layer's honesty assumption. If the DA layer fails, users cannot prove ownership.
The security boundary: as good as the proof system and the data-availability layer. Mathematically stronger than fraud proofs; operationally still depends on the prover network.
Validium and Volition are ZK-Rollup variants where DA is off-chain (Validium) or user-selectable per transaction (Volition). Cost-efficient at the price of moving the security boundary off-chain. Common in payment and gaming deployments where the cost trade-off makes sense.
Sidechains
Sidechains have their own consensus, their own validators, and their own security model. They are not Layer 2 by the strict definition; they are independent chains with a bridge.
Polygon PoS, BNB Smart Chain, and Avalanche subnets are sidechains, regardless of how they are marketed.
The security model is the consensus of the sidechain plus the bridge model that connects it to Ethereum. Sidechains share the bridge problem with cross-chain bridges; the sidechain's value is bounded by the security of its bridge. Our cross-chain bridge paper covers that surface.
State channels
State channels lock funds on L1 between two or more parties, exchange signed off-chain updates, and settle to L1 either cooperatively or via a dispute.
The security model rests on:
Watchtower availability. A user must publish to L1 if a counterparty submits an outdated state. If the user is offline and no one watches for them, the counterparty wins.
Dispute resolution timing. Dispute windows must be longer than expected disruption (network outages, exchange downtime, planned maintenance). Too short, and honest users lose. Too long, and capital is locked.
Channel state finality. Signed states must be cryptographically robust against signature replay across channels.
Channels are tight, useful, and rarely deployed at scale. The lockup-and-availability trade-off has kept them niche.
Where L2s leak in practice
Sequencer centralization. Almost all production L2s run on a single permissioned sequencer. The sequencer cannot steal funds (L1 finality of withdrawals defends against that), but it can censor transactions, reorder transactions for its own benefit, and freeze the chain. Decentralized sequencer work has shipped components in 2025–2026 (Espresso, Astria, shared sequencing layers, based-rollup designs that drive sequencing from L1 itself); full decentralization on the largest L2s remains a roadmap item, not a deployed reality.
Escape hatches. When the sequencer stops, users need a way to withdraw directly through L1. Some L2s have a force-inclusion path; some do not. Some have it in theory but the verifier contract is paused. We check this on every L2 audit.
L1↔L2 bridge compromise. The contract on L1 that holds the L2's TVL is, by design, the most concentrated single point of failure on Ethereum mainnet. If that contract has a bug, the L2 has lost everything.
Withdrawal-window race conditions. Some L2s allow third-party "fast bridges" that pay out earlier than the L2's native withdrawal at a fee. These bridges have their own security model.
What we audit on an L2
We audit the L1 verifier contract first. We model what happens when the sequencer goes offline, when the prover network goes offline, when the data-availability layer fails, and when L1 reorgs. We trace the force-inclusion path end to end. We pressure-test the dispute logic for Optimistic Rollups.
We do not claim that "L2 inherits Ethereum security" without specifying which operations actually do.
The deliverable is the audit report described in our methodology.
What clean means
A clean L2 audit means the protocol's security claims hold under the assumptions stated. Many of those assumptions involve off-chain operators. We name them explicitly. We do not let the marketing claim do the work.