Layer 2 Scaling: Rollups, Fraud Proofs, ZK Proofs and the Sequencer Problem

The headline metrics look solved. Ethereum Layer 2s process transactions at ~$0.001–$0.01 each, aggregate throughput exceeds the L1 by 50–100x, and total value locked across rollups has grown substantially — check L2BEAT for the current figure at the time you read this, as TVL fluctuates with market conditions and token prices. By any throughput-per-dollar measure, rollups have delivered on the computation scaling promise articulated in Vitalik Buterin's 2020 rollup-centric roadmap.

But computation was always the easier half. The harder half — trust minimisation — remains largely unfinished. Most rollups still rely on centralised sequencers that enjoy god-mode over transaction ordering. As of mid-2025, essentially all ZK-rollups operate at Stage 0 or Stage 1 maturity — no ZK-rollup has yet reached Stage 2 — meaning a small multisig can rewrite the verifier contract and, by extension, redirect every deposited asset. And the forced inclusion mechanisms that serve as the last line of censorship resistance remain undertested in adversarial conditions.

This guide examines the actual machinery: how fraud proofs and validity proofs work at the instruction level, why sequencer architecture matters more than most participants realise, where each major rollup sits on the decentralisation spectrum, and the specific failure modes that advanced users must monitor. Every claim here is verifiable against on-chain data or primary documentation referenced at the end.

Every rollup — optimistic or zero-knowledge — shares the same structural logic. Transactions execute off-chain in a separate execution environment, are batched together, and the resulting state root (a cryptographic commitment to the entire L2 state after execution) is posted to Ethereum L1. The primary divergence between rollup types lies in how the L1 verifies that the posted state root is correct, though they also differ meaningfully in finality times, cost structures, EVM compatibility approaches, and prover/verifier infrastructure requirements.

Four components define any rollup. The sequencer orders incoming transactions and produces L2 blocks. The executor processes those transactions against the current state to produce the new state root. The prover (or challenger, in optimistic systems) generates the cryptographic evidence that the state transition is correct. And the bridge contract on L1 holds deposited assets and enforces the rules about when withdrawals can be finalised.

The cost structure reveals a critical dependency. An L2 transaction fee comprises two components: a local execution fee and an L1 data availability (DA) fee — the cost of posting transaction data to Ethereum so that anyone can independently reconstruct the L2 state. Before EIP-4844 (pre-March 2024), the DA fee accounted for ~70–90% of total rollup operational costs, making L1 data posting the dominant expense. After EIP-4844 introduced blob transactions, DA costs dropped dramatically — often to below 50% of total costs, and during periods of low blob demand, as low as 1–10%. Post-4844, the local execution fee became the dominant cost component for most rollups. This inversion is the single most important economic shift in L2 history and fundamentally changed rollup operator economics.

The DA distinction also draws the sharpest line in rollup security taxonomy. A true rollup posts full transaction data to Ethereum L1 (as blob transactions since EIP-4844). A validium posts only state roots to L1 and stores data elsewhere — Celestia, EigenDA, a data availability committee, or even a proprietary server. Validiums are dramatically cheaper but make a different security trade-off: if the off-chain DA layer fails, users cannot independently prove their balances, and the "inherits Ethereum security" claim weakens. It's worth noting, however, that this is not a binary: validiums using Celestia with Data Availability Sampling (DAS) still provide meaningful DA guarantees — weaker than Ethereum but far stronger than a simple committee. The security spectrum runs from Ethereum DA (strongest) through DAS-based DA layers (strong) to committee-based DA (weakest), not a clean "secure vs. insecure" binary.

EIP-4844 (Proto-Danksharding), live since March 2024's Dencun upgrade, introduced blob transactions — a new transaction type that carries ~128 KB data "blobs" which are available for ~18 days and then pruned from consensus nodes. The target is 3 blobs per block (~384 KB), with a maximum of 6 (~768 KB). Crucially, blobs have their own independent fee market with a base fee that adjusts based on utilisation, completely separate from the regular gas market.

Blob data is committed using KZG commitments (Kate-Zaverucha-Goldberg polynomial commitments) — a cryptographic scheme that allows anyone to verify that a piece of data corresponds to a specific commitment without downloading the entire blob. This is the mathematical foundation that enables future data availability sampling: verifiers can check that data was made available by sampling random portions of the blob and verifying them against the KZG commitment, rather than downloading every byte.

The initial impact was dramatic: L2 data posting costs dropped ~90–99%. Arbitrum transaction fees fell from ~$0.20–$0.50 to ~$0.01–$0.02 overnight. Before EIP-4844, a typical Arbitrum transaction cost ~$0.20–$0.50, with ~$0.15–$0.45 of that being the L1 data component. After 4844, the same transaction costs ~$0.01–$0.02, with the DA portion often below $0.001 during uncongested periods. The execution fee is now the larger component.

But the blob fee market has revealed its own dynamics. During activity spikes through 2025, blob space became congested, and blob base fees surged from near-zero to several gwei — meaning L2 costs are not fixed but fluctuate based on aggregate demand from all rollups competing for Ethereum DA. Some rollups temporarily fell back to posting data as calldata (more expensive per byte but always available in the regular gas market) during blob fee spikes.

The long-term roadmap targets full Danksharding with 32+ blobs per block (~4 MB), representing a ~10x increase over current capacity. The next step is PeerDAS (Distributed Availability Sampling), targeted for Ethereum's Fusaka upgrade. PeerDAS allows individual nodes to verify data availability by sampling only a small fraction of each blob rather than downloading the full data, enabling higher blob counts without proportionally increasing node bandwidth requirements. PeerDAS is the critical enabler: without it, increasing blob counts would push node hardware requirements beyond what decentralised operation permits.

For rollup operators, blob fee dynamics create non-trivial operational decisions. They must balance batch size (larger batches amortise the fixed blob transaction cost across more L2 transactions) against latency (users want confirmations quickly, not after waiting for a full batch to accumulate). During blob fee spikes, operators face a choice: absorb the cost, pass it to users, or switch DA strategies. This is why some rollups offer a volition model (Starknet's approach) where users can choose per-transaction whether to use Ethereum DA (higher security, higher cost) or off-chain DA (lower security, lower cost).

Optimistic rollups operate on a principle borrowed from legal systems: assume everyone is honest, but maintain a mechanism to punish fraud. The sequencer posts a state root to L1, and for a challenge window of seven days, anyone can dispute it by submitting a fraud proof. If no challenge arrives, the state root is accepted as final, and withdrawals against it can be processed.

The two dominant implementations — Arbitrum One (Nitro architecture) and Optimism Mainnet (OP Stack) — share this core logic but diverge substantially in their fraud proof mechanics and ecosystem strategies. Check L2BEAT for current TVL figures pinned to a specific date, as these fluctuate significantly with market conditions.

Arbitrum's execution environment compiles EVM bytecode to WAVM (a custom WebAssembly variant specific to Arbitrum that includes custom host I/O operations and Arbitrum-specific modifications) for its dispute resolution, while Optimism's Cannon system compiles to MIPS — a reduced instruction set architecture chosen because its simplicity makes on-chain single-step verification tractable. The instruction set simplicity matters directly for security: the MIPS emulator contract is ~4,000 lines of Solidity, creating a relatively small code surface for bugs. WAVM's verification system is more complex, reflecting the trade-off between richer execution capabilities and smaller audit surface. Both use interactive bisection, but the instruction set difference means the two systems have entirely different attack surfaces and verification costs.

A frequently misunderstood aspect: in a well-functioning optimistic rollup, fraud proofs are never triggered in production. They function as a deterrent, not an active mechanism. However, the absence of fraud proofs in Arbitrum's history requires important context: until BOLD launched in April 2025, Arbitrum operated with a permissioned validator set, meaning only whitelisted parties could submit challenges. The absence of fraud proofs was therefore partly because most potential challengers were excluded by design, not solely because of economic deterrence. With BOLD enabling permissionless validation, the deterrence model is now being tested under more open conditions. Rational sequencers do not post invalid state roots because they would forfeit their economic bonds and gain nothing — the invalid state would be reverted regardless. The fraud proof system's value is measured by its existence, credibility, and accessibility, not by its usage frequency.

The seven-day withdrawal delay applies only to the canonical bridge, and it is a security parameter, not a bug. The seven-day window exists specifically to give challengers sufficient time to detect and prove invalid state roots. Shortening this window reduces the time available for fraud detection, directly weakening economic security. Systems with shorter challenge windows are making a deliberate trade-off, and users should understand what they are giving up.

In practice, third-party liquidity bridges like Across, Stargate, and Orbiter front the withdrawal amount immediately, charging ~0.05–0.2% for the service. Users bridging assets between L2s almost universally use these fast paths. The practical considerations of moving assets between L2s are covered in the interoperability section below.

The interactive bisection protocol is the core innovation that makes fraud proofs economically viable. Naively re-executing an entire L2 batch on L1 to verify correctness would cost more gas than the batch itself — defeating the purpose of a rollup. Bisection reduces on-chain verification cost to O(log n) where n is the number of instructions in the execution trace.

The process works as follows. A challenger claims the posted state root is wrong and deposits a bond. The defender (typically the sequencer) also has a bond at stake. The two parties iteratively narrow the dispute: the execution trace is split in half, each party identifies which half they disagree on, and the process repeats. After approximately log₂(n) rounds — typically 30–45 depending on batch size (30–33 rounds for typical batches with billions of WAVM instructions, up to 40–45 for very large batches with trillions) — the disagreement is narrowed to a single machine instruction. That one instruction is executed on-chain, and the L1 contract determines who was correct. The loser forfeits their bond.

Arbitrum's BOLD (Bounded Liquidity Delay) protocol, which launched on Arbitrum One mainnet in April 2025, addresses a critical vulnerability in earlier dispute designs: delay attacks. In the original Arbitrum system (which used a 1-versus-1 challenge model), a well-funded attacker could repeatedly initiate fraudulent challenges to delay withdrawal finality indefinitely — each new challenge restarting the seven-day clock.

BOLD's key innovation is the shift from a 1v1 challenge model to an all-vs-all model: any number of parties can participate in a dispute simultaneously, rather than the system processing challenges sequentially between two parties. This eliminates the delay attack vector more robustly because the honest party does not need to separately defeat each attacker.

BOLD bounds the maximum dispute resolution window to ~6.4 days (two challenge periods of ~3.2 days each in the worst case) regardless of how many challenges are initiated simultaneously. It is important to note that this 6.4-day figure is the bounded dispute resolution window, not the total withdrawal finality time — the overall withdrawal delay including the initial assertion posting period can still exceed 6.4 days. BOLD achieves this through a resource-ratio mechanism: the honest party's cost to defend scales linearly with the number of malicious challenges, but the attacker's cost scales at the same rate, and the honest party always wins in bounded time.

BOLD uses a multi-level staking structure with decreasing bond sizes at each sub-challenge level. The top-level assertion bond is approximately 3,600 ETH — a substantial economic commitment that reflects the enormous value being secured (billions of dollars in bridged assets). Sub-challenge bonds at lower levels of the bisection tree are progressively smaller, but the top-level bond creates a very high cost floor for initiating frivolous disputes. This is a deliberate design choice: the economic security of the system scales with the value at risk, and a 3,600 ETH bond means an attacker must commit tens of millions of dollars to even begin an attack.

Optimism's Cannon fault proof system was initially deployed to mainnet on June 10, 2024, implementing a similar bisection game but resolving the final step by executing a single MIPS instruction inside an on-chain interpreter. However, the deployment's history is instructive about the difficulty of production fault proofs: in August 2024, Optimism discovered bugs in the system and temporarily rolled back to permissioned fault proofs, with the Security Council retaining override authority. This rollback demonstrated that even well-audited fault proof systems face unexpected edge cases in production. As of mid-2025, Optimism operates with a Stage 1 fallback mechanism where the Security Council can override the proof system — a meaningful safety net, but one that means the system is not yet fully trust-minimised.

The dispute in Cannon unfolds as a game tree where participants make alternating "attack" and "defend" moves. The system's correctness depends on the fidelity of the on-chain MIPS emulator — a relatively small piece of code (~4,000 lines of Solidity), but one whose bugs could compromise the entire proof system. The Cannon rollback incident underscored this risk.

The economic security of both systems rests on bond sizes. For Arbitrum BOLD, the top-level assertion bond is ~3,600 ETH, making frivolous top-level challenges extraordinarily expensive. Optimism's Cannon system uses a different bond structure within its dispute game tree. In both systems, the bond mechanism creates a cost floor for griefing attacks: each spurious challenge costs the attacker real capital. But it also creates an accessibility concern — permissionless validation requires sufficient capital, and a 3,600 ETH bond means meaningful participation in Arbitrum's top-level dispute process requires tens of millions of pounds.

ZK-rollups (more precisely, validity-proof rollups — the proofs need not be "zero knowledge" in the privacy sense) take the opposite verification approach. Rather than assuming correctness and punishing fraud after the fact, every batch of transactions is accompanied by a cryptographic validity proof that the L1 verifier contract checks before accepting the new state root. If the proof is valid, the state transition is guaranteed correct by mathematics, not economics.

SNARKs vs STARKs: The Two Proof Families

Two proof system families dominate, each with distinct cryptographic foundations and practical trade-offs.

SNARKs (Succinct Non-interactive Arguments of Knowledge) produce compact proofs — ~200–300 bytes for Groth16, ~1–5 KB for PLONK-based variants — and verify cheaply on-chain (~200–300K gas). The trade-off: most SNARK constructions require a trusted setup ceremony — a one-time procedure to generate proving/verification keys, where compromise of the setup secrets would allow forged proofs. Universal reference strings (like PLONK's) reduce this risk by requiring the setup only once for all circuits, not per-application. SNARKs rely on elliptic curve cryptography, which means they are not quantum-resistant — a sufficiently powerful quantum computer could theoretically break the underlying assumptions.

STARKs (Scalable Transparent Arguments of Knowledge), pioneered by StarkWare and used by Starknet, require no trusted setup at all — their security relies only on hash functions (collision resistance), making them transparent and plausibly quantum-resistant. The cost: proof sizes are much larger (~40–200 KB), and on-chain verification is more expensive. Recursive proof composition (proving the correctness of a proof) mitigates this by allowing many proofs to be aggregated into a single verification, dramatically reducing the per-transaction L1 cost.

The Proving Pipeline

Generating a ZK proof is computationally intensive and involves several stages. First, the rollup's execution trace (every computational step from processing the batch of transactions) is encoded as a set of mathematical constraints — an arithmetic circuit describing valid state transitions. These circuits are extraordinarily complex, often comprising millions of constraints. Then, a prover (typically a cluster of specialised GPUs or FPGAs) runs the proof generation algorithm, which takes ~2–20 minutes per batch depending on batch size and proof system, at a cost of ~$0.01–$0.05 per proof when amortised across transactions.

The generated proof is then submitted to the L1 verifier contract, which checks the proof's validity. Verification is asymmetric by design: generating the proof is expensive (minutes, specialised hardware), but verifying it is cheap (~200–300K gas for SNARKs, more for STARKs). This asymmetry is the fundamental economic insight that makes ZK-rollups viable.

Major ZK-Rollup Architectures

zkSync Era uses PLONK-based SNARKs and targets high EVM compatibility through a custom compiler that translates Solidity/Vyper to zkSync's own instruction set. This compilation approach means that while most Solidity contracts work, there are edge cases where EVM behaviour differs — developers must test specifically for zkSync.

Starknet uses STARKs and takes the most divergent approach: rather than targeting EVM equivalence, it uses its own virtual machine (the Cairo VM) with its own programming language (Cairo). This allows the VM to be optimised specifically for proof generation, yielding better proving performance, but at the cost of requiring developers to learn a new language or use transpilation tools.

Scroll targets bytecode-level EVM equivalence — the goal is that any EVM bytecode runs identically on Scroll without recompilation. This is the hardest technical path (proving arbitrary EVM execution in a ZK circuit is extremely complex) but offers the best developer compatibility.

Linea (Consensys-backed) uses SNARK-based proofs and similarly targets high EVM compatibility, leveraging Consensys's deep Ethereum tooling expertise.

Polygon zkEVM uses a SNARK-based approach and is part of the broader Polygon ecosystem, integrating with the AggLayer for cross-chain proof aggregation.

All of these except Starknet use some variant of SNARK-based proving, meaning they share the trusted setup requirement (mitigated by universal reference strings) and the quantum vulnerability (a long-term, not immediate, concern).

The Prover Bottleneck and Centralisation Risk

The least-discussed bottleneck in ZK-rollups is proof generation cost, latency, and centralisation. zkSync Era typically posts proofs to L1 every ~1–3 hours; Starknet's cadence ranges from ~2–8 hours. This means ZK-rollup "finality" (the point at which a state root is cryptographically verified on L1) lags execution by hours, not seconds.

This latency creates a practical consequence that undermines the theoretical advantage of validity proofs: ZK-rollup users still depend on trust in the sequencer for real-time state. Your swap on zkSync Era executes in sub-second time, but the proof confirming it on Ethereum arrives hours later. During that window, you are trusting the centralised sequencer's representation of the state — an operationally similar trust assumption to an optimistic rollup during its challenge period, just shorter in duration.

Prover centralisation is a genuine fragility. Every major ZK-rollup currently runs a centralised prover operated by the founding team. If the prover cluster goes down, the rollup cannot finalise new state on L1. Users' funds are not at risk (they can still exit via the L1 bridge contract using the last verified state), but the chain effectively halts for new operations. Decentralised prover markets — projects like =nil; Foundation and Gevulot — are actively being developed to distribute proving across a competitive marketplace, but none have reached production maturity as of mid-2025. Until decentralised proving is live, ZK-rollups have a single point of failure that is structurally identical to the centralised sequencer problem — and in fact, it is an additional single point of failure on top of the sequencer.

Every major rollup — optimistic and ZK alike — currently runs a centralised sequencer. Arbitrum, Optimism, Base, zkSync Era, Starknet, Scroll, and Linea all rely on a single operator (typically the protocol's founding company) to order transactions, produce L2 blocks, and determine inclusion. This is the most significant gap between rollup theory and rollup practice.

Three Categories of Sequencer Risk

A centralised sequencer creates three categories of risk.

Liveness risk: if the sequencer goes offline, the chain halts. Users cannot execute new transactions, though their funds remain safe (withdrawable via L1 forced inclusion, using the last verified state). Arbitrum experienced a notable sequencer outage in December 2023 lasting several hours, during which all L2 activity ceased. zkSync Era has experienced outages as well. The duration of these outages has ranged from minutes to hours. Most users do not know how to interact directly with L1 contracts to force-include transactions during an outage, and wallet interfaces typically do not expose this functionality.

Censorship risk: the sequencer can selectively exclude transactions. A sequencer operator subject to a court order or regulatory directive could censor specific addresses indefinitely. While forced inclusion mechanisms (discussed below) provide an escape hatch, they impose delays — typically 24 hours on Arbitrum — during which the censored user cannot transact normally.

MEV extraction: the sequencer has exclusive authority over transaction ordering, meaning it can front-run, back-run, or sandwich any transaction at zero competition cost. The MEV dynamic is structurally different from Ethereum L1. On L1, proposer-builder separation (PBS) creates a competitive market for block construction, distributing some MEV value back to validators and, indirectly, to stakers. On L2, the sequencer is the proposer, builder, and sole arbiter of ordering simultaneously. There is no separation, and no competitive pressure. The sequencer's MEV revenue is limited only by reputational cost and the risk of user migration to competing L2s.

Sequencer revenue models compound this dynamic. The sequencer captures the spread between what users pay in L2 fees and what the rollup pays in L1 DA costs. Post-EIP-4844, this margin has been highly profitable for major rollup operators. Combined with MEV extraction, the centralised sequencer is a significant revenue centre — which creates misaligned incentives for decentralisation. Why would a rollup operator voluntarily give up a profitable monopoly?

Architectural Responses to Sequencer Centralisation

Three architectural responses have emerged, each with distinct trade-offs.

Shared sequencing networks — Espresso Systems, Astria, Radius — propose a decentralised sequencer set that multiple rollups can opt into. The primary value proposition is twofold: censorship resistance through a distributed operator set, and cross-rollup atomic composability (the sequencer can order transactions on multiple rollups simultaneously, enabling atomic arbitrage and multi-chain interactions). Espresso has been running a testnet since 2024 and has progressed toward mainnet integration with select rollups, but adoption remains limited. The latency cost is real: a shared sequencer set requires consensus among operators, adding ~100–500ms to transaction confirmation compared to a single-operator model.

Based rollups (or L1-sequenced rollups) take the most radical approach: eliminate the dedicated sequencer entirely and use Ethereum L1 validators to order L2 transactions. Taiko, which launched mainnet in May 2024, is the leading implementation. Anyone can propose a Taiko L2 block by posting it to L1 — no permission required. This inherits Ethereum's censorship resistance and liveness guarantees directly.

The trade-offs are substantial. Based rollups cannot offer soft confirmations faster than Ethereum's ~12-second block time (versus sub-second confirmations on sequencer-operated L2s). Sequencer revenue flows to Ethereum validators, not the rollup ecosystem — undermining the rollup's economic model. And MEV is not eliminated; it is shifted to the L1 proposer/builder pipeline, where sophisticated actors extract it through existing PBS infrastructure.

Forced inclusion mechanisms represent the pragmatic middle ground that most rollups actually rely on today. Rather than decentralising the sequencer, these mechanisms provide an escape hatch: if the sequencer censors a transaction, the user can submit it directly to the L1 rollup contract, and the protocol guarantees inclusion within a bounded time.

Decentralisation Roadmaps

Arbitrum has announced plans for sequencer decentralisation but has not committed to a specific timeline. Optimism's roadmap envisions shared sequencing across the Superchain but implementation remains in development. zkSync Era has described plans for a decentralised sequencer set governed by token holders. Starknet's decentralisation roadmap includes both prover and sequencer decentralisation. In every case, the timelines are aspirational rather than committed, and the economic incentives to maintain sequencer monopolies are strong.

Forced inclusion is the mechanism that separates a rollup (even one with a centralised sequencer) from a purely trusted system. It is the ultimate censorship-resistance guarantee: the ability for a user to bypass the sequencer entirely and submit a transaction directly to the L1 contract that the rollup protocol must process.

How Forced Inclusion Works

Arbitrum's delayed inbox: any user can submit a transaction to Arbitrum's L1 inbox contract. If the sequencer does not include this transaction within ~24 hours, any party can force it into the L2 chain by calling a function on the L1 contract. The sequencer cannot prevent this — the L1 contract enforces inclusion. This 24-hour delay exists to give the sequencer time to include the transaction normally (avoiding unnecessary L1 gas costs) while bounding the maximum censorship window.

Optimism's L1 deposit transactions: users can send transactions via the L1 OptimismPortal contract. These "deposit" transactions are automatically included in the L2 chain by the derivation pipeline — the sequencer processes them as part of the L2 block derivation rules. The sequencer cannot omit them without producing an invalid L2 state that would fail the fault proof.

Why This Matters More Than Sequencer Decentralisation

Forced inclusion is the true censorship-resistance backstop, and its robustness matters more than sequencer decentralisation for most threat models. A centralised sequencer with a well-implemented forced inclusion mechanism (bounded delay, no override possible, enforced by L1 contract logic) provides stronger censorship guarantees than a decentralised sequencer set that can collude — because colluding sequencers could agree to censor, whereas a properly-implemented forced inclusion mechanism is enforced by Ethereum L1 itself.

The critical evaluation question is not "is the sequencer decentralised?" but "what is the worst-case delay before my transaction is guaranteed to be included, regardless of what the sequencer does?"

Testing and Limitations

Forced inclusion mechanisms remain undertested in adversarial conditions. While the smart contract logic is audited, very few users have actually used forced inclusion in practice. The user experience is poor: it requires interacting directly with L1 contracts (most wallets do not expose this functionality), paying L1 gas fees, and waiting for the forced inclusion delay. During a genuine censorship event — for example, if a sequencer operator were compelled by a government to censor specific addresses — the practical ability of affected users to navigate forced inclusion under pressure is unproven.

Vitalik Buterin's Stage framework, as implemented by L2BEAT, provides the most useful taxonomy for evaluating rollup security in practice. The stages measure how much of a rollup's security depends on social trust (in a multisig, a company, a security council) versus cryptographic and economic guarantees.

Stage 0 ("full training wheels") means the rollup is live on mainnet and transactions are posted to Ethereum, but there is no functioning proof system — or the proof system exists but can be overridden by a multisig with no meaningful constraints. The multisig can upgrade the bridge contract, change the state root, or redirect funds. From a trust perspective, a Stage 0 rollup is functionally equivalent to a multisig-operated sidechain that happens to post data to Ethereum.

Stage 1 ("limited training wheels") requires a functioning proof system in production, a Security Council of at least 6/8 multisig composition, the ability to override the proof system only in the case of demonstrated bugs (not arbitrary upgrades), and a minimum seven-day exit window for users. This is a meaningful threshold: the proof system is live, and the multisig's powers are constrained to emergency intervention.

Stage 2 ("no training wheels") demands that the proof system is the sole arbiter of state validity, upgrades require on-chain governance with at least a 30-day time-lock (or the contracts are immutable), and no entity can override the proof system for any reason. This is full trust minimisation.

As of mid-2025, the landscape is sobering. Arbitrum One has been operating at Stage 1, with BOLD enabling permissionless validation, and has been progressing toward Stage 2. Optimism Mainnet reached Stage 1 after deploying Cannon (though note the August 2024 rollback to permissioned proofs discussed above). But all ZK-rollups — including zkSync Era, Starknet, Scroll, and Linea — remain at Stage 0 or early Stage 1, because their bridge contracts are upgradeable by small multisigs with short or nonexistent time-locks. No ZK-rollup has achieved Stage 2.

This creates a counterintuitive but critical reality: a Stage 1 optimistic rollup with permissionless validation and a constrained security council is practically more secure than a Stage 0 ZK-rollup where a 3/5 multisig can swap the verifier contract. The proof type (ZK vs. fraud) matters less than the completeness of the security stack. Anyone evaluating L2 security should start at L2BEAT's risk assessment page, not at the rollup's marketing materials.

Advanced participants must internalise the specific ways rollups can fail, not just the ways they are designed to succeed.

Bridge contract compromise. The bridge contract is the rollup from Ethereum's perspective — it holds all deposited funds. If the contract is upgradeable and the upgrade keys are controlled by a small multisig with no time-lock, those keyholders can redirect every deposited asset. This is not a theoretical risk; it is the single largest attack surface in the L2 ecosystem. A 3/5 multisig controlling a bridge with $2B in deposits means three individuals (or three compromised keys) can execute the largest theft in DeFi history. Every user should verify the bridge contract's upgrade mechanism before depositing meaningful capital. Check L2BEAT's "Risk Analysis" tab for each rollup, which details the upgrade mechanism, time-lock duration, and multisig composition.

Sequencer liveness failure. When a centralised sequencer goes offline, the L2 chain halts. Users cannot execute new transactions, though their funds remain safe (withdrawable via L1 forced inclusion, using the last verified state). Arbitrum experienced a notable sequencer outage in December 2023. zkSync Era has experienced outages as well. The duration of these outages has ranged from minutes to hours. Forced inclusion mechanisms mitigate this — users can bypass the sequencer — but most users do not know how to interact directly with L1 contracts, and wallet interfaces typically do not expose this functionality.

The honest verifier assumption in optimistic rollups. During the seven-day challenge window, someone must be monitoring the posted state roots and willing to submit a fraud proof if one is invalid. If no honest party is watching — or if all watchers are censored — a malicious sequencer could post an invalid state root, wait seven days, and finalise it. This would allow theft of bridged funds. Permissionless validation (as enabled by BOLD) reduces this risk by ensuring anyone can challenge, but the economic incentive to run a verifier node is not automatic — it requires infrastructure, bond capital (potentially thousands of ETH for top-level Arbitrum challenges), and technical capability.

ZK circuit bugs. The correctness of a ZK-rollup depends on the correctness of its ZK circuit — the mathematical description of valid state transitions. If the circuit has a bug (accepting invalid transitions as valid), the proof system provides false assurance. ZK circuits are extraordinarily complex (millions of constraints), and formal verification is still in early stages. This is a key motivation for multi-proof approaches: combining ZK proofs with an optimistic fraud proof fallback, so that a bug in either system alone is not fatal. Taiko and Optimism's long-term roadmap both pursue this defence-in-depth strategy.

Governance capture of upgrade mechanisms. Even Stage 1 and Stage 2 rollups with time-locked upgrades face the risk that the governance mechanism itself can be captured. If a token-voted DAO controls upgrades, a sufficiently capitalised attacker could acquire governance tokens, push through a malicious upgrade, and steal bridged funds after the time-lock expires. The 30-day minimum time-lock for Stage 2 is designed to give users time to exit, but it assumes users are actively monitoring governance proposals — a strong assumption given that most depositors are passive.

DA layer failure for off-chain DA rollups. Rollups using Celestia, EigenDA, or other alternative DA layers introduce an additional failure mode: if the DA layer goes offline or is compromised, users cannot reconstruct the L2 state, and the bridge contract cannot verify withdrawals. The rollup's security is bounded by the weakest link between its proof system, its DA layer, and its bridge contract.

Prover liveness failure (ZK-rollups only). If the centralised prover goes offline, no new state roots can be verified on L1. The chain can continue executing transactions (with sequencer confirmations), but finality halts. Extended prover downtime could cascade into forced inclusion issues and user inability to withdraw.

Monitoring Checklist

• ›L2BEAT (l2beat.com): Check Stage classification, bridge contract details, and upgrade time-locks.
• ›Rollup status pages: Most major rollups maintain status pages; bookmark them for outage alerts.
• ›Governance forums: Monitor upgrade proposals for the rollups where you hold significant capital.
• ›Blob fee market: Track blob utilisation at blobscan.com to anticipate cost spikes.
• ›Sequencer uptime: Third-party monitoring tools track sequencer liveness; extended outages signal systemic risk.

The modular rollup thesis has produced an explosion of application-specific chains. L2BEAT tracks 100+ rollups and validiums, with 50+ built on the OP Stack alone (collectively branded the Superchain). Arbitrum Orbit chains, zkSync Hyperchains, and Polygon CDK (Chain Development Kit) each offer frameworks for launching custom rollups with varying DA and proof configurations.

L3s — rollups deployed on top of L2s — add another layer of the stack. An L3 settling on Arbitrum inherits Arbitrum's security only to the extent that Arbitrum itself is secure and that the L3's own bridge contract is sound. Each additional hop introduces trust assumptions, upgrade risk, and withdrawal latency. Most L3s are effectively validiums with more trust assumptions than their parent L2, targeting low-cost execution for games, social applications, and niche DeFi.

The User Experience Problem

Users experience fragmentation as a UX problem: assets stranded on one L2 that they need on another, requiring bridging steps with associated costs and risks. Cross-L2 bridges process billions of dollars monthly in transfer volume. Each bridge introduces smart contract risk — bridge exploits (Wormhole, Ronin, Nomad) represent some of the largest losses in crypto history.

Interoperability Solutions

The modular architecture is specifically designed to be reunified at the interoperability layer, and several approaches are competing:

Optimism Superchain aims for shared bridging and synchronous composability across all OP Stack chains. The vision: assets move between Superchain members (Base, Zora, Mode, etc.) without third-party bridges, and contracts on different Superchain members can call each other atomically. This requires shared sequencing across the Superchain, which is under active development.

Polygon AggLayer aggregates ZK proofs from multiple CDK chains into a single proof verified on Ethereum, creating a unified settlement layer. The cryptographic unification means that cross-chain transfers can be verified without trusted bridges — a ZK proof attests that the sending chain burned tokens and the receiving chain minted them.

Arbitrum Orbit provides a framework for launching L3s that settle on Arbitrum, with interoperability managed through Arbitrum's bridge infrastructure.

Until these native interoperability solutions mature, users rely on third-party bridges and aggregators. If you are moving assets across rollups and prefer not to manage multiple bridge interfaces, aggregators like ChangeNOW handle the routing across chains without requiring account creation. For active traders operating across multiple L2s — a common pattern for arbitrage or yield farming — the bridging overhead is a real cost centre. Consolidating execution on a single L2 where possible, or using exchanges like MEXC (which supports deposits and withdrawals on Arbitrum, Optimism, and Base directly) to rebalance across chains, can reduce both cost and bridge-related risk.

The most consequential architectural development emerging in the rollup ecosystem is the move toward multi-proof systems — rollups that combine multiple independent proof mechanisms rather than relying on any single one.

The logic is defensive. No single proof system is provably bug-free. ZK circuits could contain soundness errors that allow invalid state transitions to be "proved" valid. Fraud proof systems could have bugs in their on-chain instruction interpreters (as Optimism's August 2024 rollback demonstrated). A multi-proof rollup requires agreement between two or more independent proof systems before accepting a state transition. If the ZK proof says the state root is valid but the fraud proof system identifies an error, the state root is rejected pending investigation.

Taiko implements this today with a combined optimistic and ZK proof approach. Optimism's long-term roadmap explicitly targets a multi-proof architecture. The practical challenge is that running multiple proof systems increases operational complexity and cost, and the interaction between systems creates its own potential failure modes (what happens when two proof systems disagree due to a bug in one of them, and the resolution mechanism itself has a bug?).

Recursive proof aggregation — a ZK proof that verifies the correctness of other ZK proofs — represents a different approach to the same class of problem. Rather than defence in depth across proof types, recursive aggregation allows efficiency in depth: many proofs compressed into one, reducing L1 verification cost and enabling shared settlement across chains. Both approaches will likely coexist, serving different points on the cost-security trade-off curve.

For UK-based users, Layer 2 transactions receive identical tax treatment to Layer 1 transactions under HMRC guidance. Each token swap is a disposal for Capital Gains Tax (CGT) purposes, regardless of whether it occurs on Ethereum mainnet, Arbitrum, Optimism, or any other L2. Using an L2 bridge to move assets does not itself constitute a disposal (you are transferring the same asset to yourself), but if a bridge involves an intermediate token swap, that swap is a disposal.

The FCA's evolving stance on DeFi tokens and whether L2-native governance tokens are regulated under the Financial Services and Markets Act 2023 remains an area of active development. The FCA has not issued specific guidance on L2 tokens, but its general framework for crypto-assets applies: utility tokens are generally unregulated, while tokens that confer rights similar to securities may fall under FSMA.

From a practical standpoint, keeping clear records of cross-L2 movements is essential for SA (Self Assessment) reporting. The proliferation of rollups makes transaction tracking significantly more complex. Tools like Koinly can aggregate transactions across multiple chains including Arbitrum, Optimism, Base, and zkSync Era.

One underappreciated risk: assets held in a Stage 0 rollup with multisig-upgradeable contracts carry counterparty risk that HMRC would not recognise as a mitigating factor if funds were lost. A multisig-operated bridge that is drained due to key compromise is not a "qualifying loss" in the same way as, for example, a hack of a regulated custodian. Users should factor this uncompensated risk into their capital allocation decisions.

Three developments will define the next twelve months of L2 evolution. First, the progression of major rollups from Stage 1 to Stage 2 — particularly whether any ZK-rollup achieves Stage 2, which would require removing multisig override capabilities from bridge contracts. Second, PeerDAS deployment and its effect on blob capacity: if Fusaka ships successfully, blob throughput could increase substantially, keeping L2 fees low even as demand grows. Third, the viability of shared sequencing in production — Espresso and Astria's mainnet integrations will be the first real test of whether decentralised sequencing can match centralised sequencers on latency and reliability.

Additional developments worth monitoring: the maturation of decentralised prover markets (will any ZK-rollup move to permissionless proving in production?), the Optimism fault proof system's recovery from its rollback and progression toward fully permissionless operation, and whether based rollups (Taiko) gain meaningful adoption despite their latency trade-offs.

The underlying question remains whether the L2 ecosystem will converge (a few dominant general-purpose rollups) or continue to fragment (hundreds of specialised chains connected by interoperability protocols). Both outcomes are consistent with the rollup-centric roadmap; they simply have different implications for user experience, liquidity distribution, and where trust ultimately resides.

Primary on-chain and documentation sources for independent verification:

• ›L2BEAT Risk Assessment (l2beat.com/scaling/summary) — the definitive dashboard for rollup Stage classifications, TVL with trust-assumption breakdowns, and bridge contract analyses. Updated continuously; check the "Risk Analysis" tab for each rollup.
• ›Ethereum EIP-4844 Blob Dashboard (blobscan.com) — real-time blob utilisation, blob base fee history, and per-rollup blob posting patterns.
• ›Arbitrum BOLD Documentation (docs.arbitrum.io/bold) — technical specification of the bounded dispute protocol, including bond sizes (~3,600 ETH top-level assertion bond), challenge timing, all-vs-all mechanics, and resource-ratio mechanics.
• ›Optimism Cannon Specification (specs.optimism.io/fault-proof) — detailed specification of the dispute game, MIPS instruction verification, and Cannon's on-chain components. Note the August 2024 rollback context.
• ›Dune Analytics L2 Economics (dune.com/niftytable/rollup-economics) — on-chain data for rollup revenue, L1 data posting costs, and margin analysis across major L2s.
• ›Taiko Protocol Documentation (docs.taiko.xyz) — based rollup architecture, multi-proof implementation, and proposer mechanics.
• ›Ethereum Roadmap Tracker (ethereum.org/en/roadmap) — current status of Danksharding, PeerDAS, and related upgrades.
• ›EigenDA and Celestia Documentation — for evaluating alternative DA layer security models and their interaction with rollup trust assumptions.

Every number in this guide can be cross-referenced against these sources. Where approximations are used (indicated by ~), they reflect ranges observed in on-chain data. TVL figures fluctuate significantly; always verify current numbers at L2BEAT before making deployment or capital allocation decisions. The L2 landscape evolves rapidly; verify current Stage classifications at L2BEAT before making any deployment or capital allocation decisions.