Week 11 — L2, Rollups & Modular Blockchain Security

“An L2’s marketing tells you it’s ‘secured by Ethereum’. The auditor’s job is to take that sentence apart: which guarantees actually flow from Ethereum, which depend on a fraud-proof system that hasn’t been battle-tested, which depend on a single sequencer’s goodwill, and which depend on a 7-of-13 multisig nobody mentions on the landing page. The gap between ‘secured by Ethereum’ and ‘an L1 user’s actual position on this chain right now’ is where every L2 bug lives.”

Tags: web3-security l2 rollup optimistic zk-rollup data-availability sequencer modular l2beat Learner: Past Tuan-10-Bridge-Cross-Chain-Security — comfortable with cross-chain trust models, finality and messaging. Time: 7 days (5–6h/day; one of the densest weeks because the surface is genuinely large) Related: Tuan-10-Bridge-Cross-Chain-Security · Tuan-09-Oracle-MEV-Economic-Attack · Tuan-12-Wallet-AA-Key-Management · Case-Wormhole-2022 · Case-Nomad-Bridge-2022

1. Context & Why

1.1 The audit reframe

In 2026 most TVL doesn’t live on L1 anymore. It lives on rollups. If you’re auditing a DeFi protocol that deploys to “Optimism + Arbitrum + Base + zkSync + Linea + Scroll”, you are not auditing one deployment — you are auditing six chains, each with different sequencer policies, different upgrade authorities, different DA assumptions, different withdrawal timing, and different fault-proof status.

The pitch “we deploy on L2 to save gas” silently imports a set of additional trust assumptions that did not exist on L1. The auditor’s job is to make every one of those assumptions explicit before signing off.

A good Week 11 graduate can finish this sentence for any L2: “If the sequencer of <chain> goes down right now, here’s exactly what users can and cannot do, and within what time window.” If you cannot answer that question for a chain your client is deploying on, you have not finished the audit.

1.2 The three orthogonal questions

Every rollup architecture can be decomposed by three orthogonal questions:

How is correctness enforced?
- Optimistic: assume correct, allow challenge during a window (fraud proofs).
- Validity (ZK): prove correctness before publishing (validity proofs).
Where is the data?
- Rollup proper: on L1 (calldata, or post-Dencun, blobs via EIP-4844).
- Validium: off-chain (DAC, or DA-layer like Celestia / EigenDA / Avail).
- Volition: per-tx user choice.
Who orders transactions?
- Centralized sequencer: a single operator (current default).
- Decentralized / shared sequencer: a committee or external network (Espresso, Astria; mostly forward-looking in 2026).

A “ZK rollup” is one specific point in this 2×3×2 cube. A “validium” is another. A “shared-sequenced optimistic chain with Celestia DA” is another. The auditor’s mental model must accommodate the cube, not just the named systems.

1.3 What you’ll be able to do by Friday

Sketch the rollup-pipeline diagram (user → sequencer → batcher → proposer → verifier → L1 bridge) for both optimistic and ZK families and identify where each component lives.
Read the L1 bridge contract of a major L2 on Etherscan, identify the upgrade authority, and state the worst-case timing of a malicious upgrade.
State, for an arbitrary L2 deposit, the maximum time a user might wait to withdraw under (a) normal conditions, (b) sequencer down, (c) bridge compromised.
Use L2Beat’s risk-row schema to triage any L2 in <5 minutes.
Identify the dominant trust assumption for at least three classes of DA: blobs, Celestia, EigenDA.
Write a one-paragraph threat model for an arbitrary protocol’s L2 deployment, distinct from its L1 threat model.

1.4 Primary references

Source	URL	Why
L2Beat (especially the Stages framework)	https://l2beat.com/ · https://l2beat.com/stages	Industry’s de-facto risk taxonomy; required reading for every L2 audit
OP Stack Specs	https://specs.optimism.io/	The reference optimistic-stack spec; many L2s are forks
Arbitrum Nitro docs	https://docs.arbitrum.io/	Mature alt-optimistic with interactive fraud proofs (BoLD)
zkSync Era docs	https://docs.zksync.io/	Native AA + Boojum prover stack
Scroll docs	https://docs.scroll.io/	Type-2 zkEVM with bytecode-level Ethereum equivalence
Linea docs	https://docs.linea.build/	ConsenSys zkEVM
Starknet docs	https://docs.starknet.io/	Cairo VM; STARK-based; non-EVM execution surface
Polygon zkEVM docs	https://docs.polygon.technology/zkEVM/	EVM-equivalent zk
EIP-4844	https://eips.ethereum.org/EIPS/eip-4844	Proto-danksharding (blobs); the post-Dencun DA primitive
Celestia docs	https://docs.celestia.org/	Sovereign DA layer with data-availability sampling
EigenDA docs	https://docs.eigenda.xyz/	Restaking-based DA service (DAC, not a DA chain)
Avail docs	https://docs.availproject.org/	KZG + erasure-coded DA
Vitalik — “An Incomplete Guide to Rollups”	https://vitalik.eth.limo/general/2021/01/05/rollup.html	The canonical taxonomy
Vitalik — “Endgame”	https://vitalik.eth.limo/general/2021/12/06/endgame.html	The trust-minimized centralized-production thesis
Espresso Systems	https://www.espressosys.com/ · https://docs.espressosys.com/	Shared-sequencer reference
Astria	https://www.astria.org/ · https://docs.astria.org/	Shared-sequencer + Celestia DA reference
Trail of Bits — Rollup audit reports	https://github.com/trailofbits/publications	Public reports on OP Stack, Optimism Bedrock, zkSync etc.
ChainSecurity — L2 reports	https://chainsecurity.com/	Reports on Linea, zkSync, others

Currency note: L2 architecture is the fastest-moving piece of Web3 in 2026. L2Beat stages, fraud-proof status, sequencer decentralization, and DA integrations all change quarterly. Treat every concrete claim below as [verify] at audit time. The methodology is durable; the snapshot is not.

2. Why L2 Exists — and the Cost the Auditor Must Account For

2.1 The scalability trilemma applied to rollups

The classical formulation: a blockchain can pick at most two of {scalability, security, decentralization}. Rollups try to slip the trilemma by outsourcing execution off-chain while inheriting security from L1. The trick:

The rollup executes transactions off-chain in a sequencer that can run much faster than L1.
The rollup publishes enough information to L1 that L1 can verify (or at least challenge) the off-chain execution.
If the rollup is honest, L1 doesn’t have to do the work. If the rollup is dishonest, the publication on L1 lets honest actors catch it.

The two flavors differ in what “publish enough information” means:

Family	Published to L1	Correctness check on L1
Optimistic rollup	Transaction data (so anyone can replay)	Fraud proof (challenge during window)
ZK / validity rollup	Transaction data (or commitment) + validity proof	Verifier contract checks proof immediately

The cost-of-correctness shifts: optimistic rollups push it to “honest watcher exists in the 7-day window”; ZK rollups push it to “prover system is sound, verifier contract is correct, trusted setup (if any) was honest”.

2.2 The auditor’s reframe of “secured by Ethereum”

The phrase obscures more than it reveals. Break it into the layers that might be secured by Ethereum and the layers that might not:

Property	Inherited from Ethereum?	Conditional on
Censorship resistance	Partially	Existence of a working escape hatch / forced inclusion under L1-only conditions
Liveness	No (depends on sequencer)	Sequencer being honest and online
Safety (you don’t lose funds)	Partially	Fault-proof system being live, permissionless, and battle-tested or validity proofs being sound and verifier upgrade controlled
State availability	Yes if data on L1 (calldata/blobs); No if external DA	Where the DA layer is
Finality	Depends — soft (sequencer) vs hard (post-challenge or post-proof)	Time to bridge withdrawal

In an audit, never accept “L2 inherits Ethereum’s security” without forcing the protocol team to specify which of these properties they actually mean. The marketing answer ≠ the audit answer.

2.3 Rollup-centric roadmap → Endgame

Vitalik’s 2020 “rollup-centric roadmap” pushed Ethereum to scale via L2s rather than via increasing L1 throughput. The 2021 “Endgame” essay argued that production of blocks can be centralized while verification and censorship resistance stay decentralized — and that this asymmetry is fine if validity proofs / fraud proofs / inclusion lists exist.

Auditor’s reading of Endgame:

Producers can be few and capital-intensive (centralized sequencer is acceptable in principle).
Verifiers must be many and cheap (anyone can run a verifier; this is what ZK proofs and DA sampling enable).
Inclusion must be permissionless (forced inclusion mechanisms must actually work).

If any of those three pillars is broken for the L2 you’re auditing, the Endgame architecture doesn’t hold — and the marketing implication that it does is itself a finding.

3. Rollup Taxonomy

3.1 The 2x3x2 cube

flowchart TB
  subgraph Correctness[Correctness model]
    O[Optimistic — fraud proof]
    Z[ZK / Validity proof]
  end
  subgraph DA[Data Availability]
    DA1[On-chain L1 calldata]
    DA2[On-chain L1 blobs EIP-4844]
    DA3[External DA: Celestia/EigenDA/Avail]
    DA4[Validium DAC]
  end
  subgraph Seq[Sequencer model]
    S1[Centralized single sequencer]
    S2[Shared / decentralized sequencer]
  end

	On-L1 DA	External DA	DAC (validium)
Optimistic	OP Mainnet, Arbitrum One, Base	OP Stack with Alt-DA (e.g., Manta Pacific historically), Mantle (uses EigenDA)	Rare in pure optimistic
ZK	zkSync Era, Scroll, Linea, Polygon zkEVM, Starknet, Taiko	zkSync Validium mode, custom Starknet variants	Immutable X, dYdX v3, Sorare (StarkEx)

Volition (per-tx DA choice) is mostly a StarkEx primitive used by some app-chains.

3.2 Optimistic rollups in depth

The mental model:

sequenceDiagram
  participant U as User
  participant Seq as L2 Sequencer
  participant Bat as Batcher
  participant Prop as Proposer
  participant L1 as L1 (Verifier + Bridge)
  participant Ch as Challenger

  U->>Seq: tx
  Seq-->>U: receipt (soft)
  Seq->>Bat: batch tx
  Bat->>L1: post calldata/blobs
  Prop->>L1: post output root (state commitment)
  Note over L1: 7-day challenge window opens
  Ch-->>L1: challenge (if root is wrong)
  L1->>L1: interactive bisection → 1-step proof
  L1-->>Prop: slash bond if proven wrong
  Note over L1: window closes → root final

Critical timing facts (mostly [verify]):

Challenge window: standard 7 days for OP Mainnet, ~6.4 days for Arbitrum One under BoLD.
Soft finality on L2: ~2 seconds after sequencer accepts.
Hard finality (i.e. safe to bridge to L1): end of challenge window.

The dispute mechanics:

Type	Approach	Used by	Audit angle
Single-round (non-interactive)	Challenger re-executes the disputed block on L1	Cannon (OP Stack fault proofs) executes a MIPS VM step-by-step	L1 gas cost; need to fit MIPS state in L1
Interactive bisection	Disputants bisect from full block down to one instruction; L1 only adjudicates the disputed step	Arbitrum Nitro / BoLD	More gas-efficient on L1; harder protocol; timing complexity

Bond / slashing: challenger must post a bond. If they lose the challenge, bond is slashed (to discourage spam). If they win, they get the proposer’s bond. Audit angle: if the bond is too low, an attacker with deep pockets can spam challenges to grief honest proposers; if it’s too high, no one will challenge. BoLD specifically formalizes a worst-case-bounded delay.

Permissionless vs permissioned proposers [verify]:

Many L2s historically had a permissioned proposer set. Both Arbitrum (via BoLD) and Optimism have moved toward permissionless fault-proof validation, but the proposer role (publishing state roots) and the challenger role are operationally distinct. Always check the live state on L2Beat.
The audit question: can a non-whitelisted address challenge? If only the protocol team can challenge, the fraud-proof system is a marketing claim, not a security mechanism.

3.3 ZK rollups in depth

sequenceDiagram
  participant U as User
  participant Seq as L2 Sequencer
  participant Pro as Prover
  participant Ver as L1 Verifier
  participant Br as L1 Bridge

  U->>Seq: tx
  Seq-->>U: soft receipt
  Seq->>Seq: execute, build state diffs
  Seq->>Pro: trace
  Pro->>Pro: generate ZK proof (minutes-hours)
  Pro->>Ver: submit proof + state root
  Ver->>Ver: verify proof on-chain
  Ver->>Br: state root finalized
  Note over Br: ~hours, not 7 days

Trusted setup matters for SNARK families:

System	Trusted setup?	Used by
Groth16	Per-circuit trusted setup	Older zkSNARKs; some app-specific
PLONK (universal)	Universal trusted setup (one-time, reusable)	Many modern zkEVMs (zkSync’s Boojum is FRI-based hence transparent; others use PLONK variants)
STARKs	Transparent (no setup)	Starknet
FRI-based / Boojum	Transparent	zkSync Era

Audit implication: if the rollup uses Groth16, ask which ceremony, who participated, was the ceremony output published with all participants’ attestations. A compromised trusted setup means anyone holding the toxic waste can mint arbitrary state transitions. The verifier contract trusts the proof, the proof trusts the setup.

Recursive proofs: most modern zkEVMs use recursion — prove batches of transactions, then prove a batch of those proofs. Audit angle: every layer of recursion is another circuit; an under-constrained constraint at the recursion layer can break the whole stack even if the leaf circuits are fine.

Verifier upgrade risk (this is the biggest unsung audit finding for ZK L2s):

The L1 verifier contract is a piece of Solidity code that checks proofs. Like any contract, it can be upgraded. Whoever can upgrade the verifier can effectively mint state on the rollup arbitrarily. They replace the real verifier with one that accepts any proof, then submit a state root that transfers all funds to themselves.

For each ZK L2, the audit checklist must answer:

Who can upgrade the verifier?
Is there a timelock?
How long?
Is there a Security Council veto?
What’s the M-of-N threshold?

zkSync Era’s current model [verify]: standard upgrades go through DAO + ~3-day timelock + Security Council (6/12) approval; emergency upgrades via EmergencyUpgradeBoard (3/3 multisig of Security Council + Guardians + Foundation) bypass the timelock. The auditor should write down precisely what this means in attack-time-cost terms.

3.4 Validium and Volition

Validium: same correctness model as ZK rollup (validity proofs), but DA is off-chain. Trade-off:

	Validium	True ZK rollup
Throughput	~9k+ TPS realistically	Capped by L1 DA
DA cost	Near-zero	Real (blobs, but real)
DA failure mode	DAC withholds data → funds frozen	None (L1 always has the data)
Safe from DA committee compromise?	No	Yes

The validium DA committee withholding attack: if the DAC stops publishing state data, users cannot generate the Merkle proofs needed to withdraw. Validity proofs ensure the state transitions are correct, but the state itself becomes inaccessible. The classic frozen-but-not-stolen failure mode.

Volition: each user picks per-tx whether their tx data goes on-chain (rollup mode) or off-chain (validium mode). Used by StarkEx-based deployments (Immutable X, dYdX v3, Sorare). Auditor angle: the user (or their wallet) is now making a security decision per transaction. If the wallet defaults to “validium for cheap fees”, the user has unknowingly opted into the DAC trust assumption.

3.5 The headline rollups, briefly [verify all]

L2	Family	Native VM	DA	Notable feature	L2Beat Stage (likely current)
OP Mainnet	Optimistic	EVM (OP Stack)	Blobs	Superchain shared sequencer plan	Stage 1
Arbitrum One	Optimistic	Arbitrum Nitro (EVM-compat + ArbOS)	Blobs	BoLD interactive fraud proofs	Stage 1
Base	Optimistic	EVM (OP Stack)	Blobs	Coinbase-operated sequencer	Stage 1
zkSync Era	ZK	zkEVM (Type 4, native AA)	Blobs	Boojum STARK→SNARK prover, native account abstraction	Stage 0
Scroll	ZK	zkEVM (Type 2)	Blobs	Bytecode-level EVM equivalence	Stage 0 / 1
Linea	ZK	zkEVM	Blobs	ConsenSys ecosystem	Stage 0
Polygon zkEVM	ZK	zkEVM (Type 2/3)	Blobs	Plonky2 prover	Stage 0 / 1
Starknet	ZK	Cairo VM (non-EVM)	Blobs (gradually)	STARK proofs, native AA	Stage 0 / 1
Taiko	ZK (based-rollup)	zkEVM	Blobs	Based-sequencing (L1 proposer = L2 sequencer)	varies
Immutable X	ZK Validium	StarkEx-Cairo (non-EVM)	DAC	NFT-focused	Validium — separate framework

Mark every chain you’re auditing against L2Beat the day of the audit and again at report-delivery. Numbers shift.

4. The Rollup Components

A rollup is a pipeline. Every component is an audit surface.

flowchart LR
  User -->|tx| Seq[Sequencer]
  Seq -->|batches| Bat[Batcher]
  Bat -->|L1 calldata/blobs| L1Inbox[L1 Inbox / Batch Submitter]
  Seq -->|state root| Prop[Proposer]
  Prop --> L1Out[L1 Output Oracle / State Manager]
  Pr[Prover ZK only] -->|proof| L1Ver[L1 Verifier]
  L1Ver --> L1Out
  L1Out --> L1Br[L1 Bridge / Portal]
  L1Br <-->|deposits / withdrawals| L2Msg[L2 Messenger]
  L2Msg <--> User

4.1 Sequencer

Today: almost always a single operator [verify] on every major L2.
What it does: receives user txs, orders them, executes them, returns a soft receipt.
Audit angles:
- Liveness: if it goes down, the L2 stops producing blocks. User funds may be locked.
- Censorship: it can refuse to include your tx. Forced inclusion via L1 is the escape — does it actually work? See §6.
- MEV: with no decentralization, sequencer can extract MEV trivially. Most L2s claim “first-come-first-served” as policy, but no L2 cryptographically enforces it.
- Sequencer-set MEV revenue is the implicit budget for the chain. Audit thesis: chains with no MEV pricing model are subsidized; that subsidy can stop.

4.2 Batcher

What it does: bundles L2 transactions and posts them to L1 as calldata or blobs.
Audit angles:
- Liveness: if the batcher stops, the rollup state can still progress on the sequencer but L1 doesn’t see the data. After enough delay, fraud-proof systems / validity proofs cannot proceed.
- Censorship via batching: a batcher that omits certain txs achieves censorship even if the sequencer ordered them honestly. Forced-inclusion txs go through a separate L1 inbox that bypasses the batcher.
- Compression bugs: batchers compress L2 transactions before posting. A compression bug could cause L1 derivation to disagree with sequencer-claimed state — a chain-halt class of bug.

4.3 Proposer

What it does: posts the L2 state root to L1 periodically (every few minutes / hours, varies by chain).
Audit angles:
- Permissioned vs permissionless: many chains restrict proposer role to a whitelist. If proposer is offline and no fallback, no new state is committed, no withdrawals finalize.
- Bond: in optimistic systems the proposer’s bond is what makes fraud proofs economically meaningful.
- Slashable conditions: precisely which behaviors are slashable?

4.4 Prover (ZK only)

What it does: takes the trace of L2 execution, generates the ZK proof of correctness.
Audit angles:
- Centralized prover: most ZK L2s have one prover (the team) [verify]. If the prover stops, no new proofs are submitted, withdrawals stop.
- Prover hardware: many provers need beefy GPUs; failure mode is operational.
- Soundness bugs in prover: a prover bug that produces an invalid-but-accepted proof is catastrophic (would mint arbitrary state). Far rarer than verifier-side bugs but more impactful.

4.5 L1 Verifier contract (ZK only)

A Solidity contract that runs the proof-verification algorithm.
Audit angles:
- Upgradeability: see §3.3. The single largest centralization vector in ZK L2s.
- Verifier correctness: subtle bugs (wrong field arithmetic, wrong curve constants, missing constraint checks at the boundary) can break soundness.
- Gas costs: a verifier that’s too gas-heavy can be DOS’d by L1 base-fee spikes during proof submission.

4.6 L1 Bridge contract (the most concentrated risk)

The L1 bridge contract holds every dollar of canonical L2 TVL. If this contract is compromised, the entire L2’s user balance is at risk regardless of whether the L2 itself is functioning.

Examples: OP Stack’s OptimismPortal, Arbitrum’s Inbox + Bridge + Outbox, zkSync’s L1SharedBridge / Mailbox.
Audit angles:
- Upgrade authority: who can upgrade? Timelock? Multisig threshold?
- Withdrawal proof verification: bridge contract verifies Merkle proofs of withdrawal events from L2; any bug in proof verification = forge withdrawal.
- Pause mechanism: who can pause? Does pause stop deposits, withdrawals, or both? See §6.5.
- Reentrancy on relayMessage: bridge contracts execute L2-originated calls on L1; if reentrancy guards are weak, an L2 message can re-enter and double-withdraw.

4.7 L2 Messenger

The L2-side contract that emits withdrawal events / accepts deposit messages.
Audit angles:
- Trusting msg.sender: the L2 messenger must verify that L1-originated messages came from the bridge address; this is usually done via a special predeploy address that the rollup OS guarantees.
- Replay protection: messages must be one-shot or have a nonce.

5. Data Availability

DA is the seam between an L2 and L1 that auditors most commonly hand-wave. Get specific.

5.1 DA = “can someone other than the sequencer reconstruct the state?”

If only the sequencer has the data, then the sequencer can stop the world: it stops publishing, no one can withdraw, no one can compute proofs, the chain effectively dies with all user funds frozen.

If everyone can get the data, then even if the sequencer dies, anyone can spin up a new sequencer from the historical data.

5.2 The DA spectrum

Mode	Where data lives	Trust assumption	Cost	Recovery if sequencer stops
Calldata on L1 (pre-Dencun, 2024-)	Ethereum L1 history	Ethereum’s full security	Highest	Anyone with an Ethereum archive node can reconstruct
EIP-4844 blobs (post-Dencun)	Ethereum L1 temporarily (~18 days)	Ethereum’s full security + retention assumption	~10–100x cheaper than calldata	Anyone with blobs cached within retention period
Celestia / Avail (external DA chain)	Celestia / Avail blockchains	DA chain’s BFT honest-majority + data-availability sampling	Cheap	Anyone running a DA chain light client can sample
EigenDA (DAC backed by restaking)	Eigen committee, slashable via EigenLayer	Honest-majority of committee + economic slashing	Cheapest	Honest committee member must serve
Pure DAC (validium)	A committee of N parties	M-of-N committee honesty	Near zero	Honest committee member must serve

5.3 EIP-4844 (blobs) — the post-Dencun world

EIP-4844 (“proto-danksharding”) activated on Ethereum mainnet March 13, 2024 [verify]. Key facts:

A new transaction type carries blobs: 4096 field-elements × 32 bytes = 128 KiB each.
Up to 6 blobs per block (target 3, max 6) [verify with current spec].
Blobs are committed via KZG commitments; consensus-layer verifies the commitments, execution-layer never sees blob bytes (only the commitment hash via BLOBHASH opcode).
Blobs are pruned after ~18 days on consensus nodes. After that, they’re gone from Ethereum’s storage.
Result: L2 data-posting costs dropped ~10–100x post-Dencun.

Auditor implications:

Retention is not permanent. If the rollup goes dormant for >18 days and nobody saved the blobs, the historical state is non-reconstructible from Ethereum alone. The protocol’s claim of “secured by Ethereum DA” weakens after blob expiry. Mitigation: third-party blob archives, the team’s own archive, or fallback to calldata.
KZG ceremony trust. The KZG trusted setup (“Powers of Tau” ceremony, 2023) was Ethereum’s largest multi-party ceremony — but a successful collusion of all participants would let an attacker forge KZG commitments. Auditor’s “post-quantum / setup-trust” disclosure should note this.
Blob fee market is separate from gas. A spike in blob demand drives blob base fee up while gas fee stays flat; an L2 protocol that doesn’t reprice batches in response can lose money or get DOS’d. (Not the auditor’s problem, but worth flagging in design review.)

5.4 External DA layers

The post-2024 reality is that “L2 with external DA” has become commonplace for cost reasons. Don’t treat external DA as morally equivalent to L1 DA.

Celestia:

A sovereign blockchain whose only purpose is to provide DA.
Uses erasure-coded blocks + 2D Reed-Solomon so that light clients can sample random chunks and probabilistically verify availability without downloading the whole block.
Trust assumption: honest-majority of Celestia validator set + DAS soundness assumption.
Auditor checklist: how much Celestia security cost is bonded? What’s the DAS threshold parameter? Has any rollup integration produced a working light-client bridge back to Ethereum that surfaces DA failure on L1?

EigenDA:

A Data Availability Committee (DAC) operated by restaked Ethereum validators (via EigenLayer).
Not a blockchain — there’s no public verification that data is in fact stored. The bridge contract on Ethereum can only check that committee members have signed attestations that they hold the data.
High throughput, lower trust than Celestia (in the “cryptographic verifiability” sense), higher trust in the “economic slashing” sense.
Auditor angle: the EigenLayer slashing for DA-withholding is non-trivial; verify the slashing module is live and the slashable conditions are precise. The classic failure: AVS attestation that “data is held” without any later cryptographic challenge.

Avail:

Polkadot-origin DA chain; KZG commitments + erasure coding + DAS.
Similar to Celestia in design philosophy; different ecosystem.

Audit rule: when a chain claims “secured by Ethereum” but uses an external DA layer, the correct phrasing is “settlement-secured by Ethereum; DA-secured by <other system>“. The user’s actual security is the minimum of the two.

5.5 The DA-sampling concept

Light clients on a DA chain don’t download the whole block. Instead:

The block is erasure-coded into a 2D matrix.
The light client samples K random cells.
If even one sample is unavailable, the light client rejects the block.
With erasure coding, recovering >50% of the data lets you reconstruct everything; conversely, withholding any data means making >50% of cells unavailable, which is overwhelmingly likely to be detected by random sampling.

The result: a network of many light clients collectively guarantees availability without any single one storing the whole block. This is the modular-DA value proposition. Auditing a rollup that depends on it: verify the DAS parameters (sample count, erasure rate, finality assumption).

6. Audit Angles for L2 / Rollups

This is the section to internalize. Every L2 audit walks this checklist.

6.1 Sequencer trust assumption

Question: if the sequencer is malicious or offline, what’s the user’s recourse?

Failure mode	Recourse	Time
Sequencer down (liveness)	Forced inclusion via L1 inbox	Hours to days [verify]
Sequencer censors specific user	Forced inclusion	Same
Sequencer corrupts state	Fraud proof (optimistic) / proof never generated (ZK — chain halts)	7 days / indefinite
Sequencer steals MEV	None at protocol level; off-protocol MEV-resistant order flow (PBS, encrypted mempool)	n/a

A live, working, empirically tested forced-inclusion mechanism is the difference between “trusted sequencer” and “trust-minimized sequencer”. Most L2s have a forced-inclusion mechanism on paper. Few have been exercised at scale. This is a finding even when the mechanism technically exists.

6.2 Escape hatch / forced inclusion

The mechanism (varies per L2):

Arbitrum:

User submits tx directly to L1 SequencerInbox.forceInclusion.
After a 24-hour delay [verify], if the sequencer hasn’t included it, the tx can be force-included into the L2 from L1.
24h delay exists to prevent users from disrupting the sequencer’s batching.

OP Stack:

User can deposit to L1 OptimismPortal.depositTransaction, which generates an L2 transaction directly.
This bypasses the sequencer’s choice; the transaction is included in the canonical chain at the next L1 batch.
Useful for “I want to call this L2 contract even if the sequencer hates me”.

zkSync, Scroll, Linea (ZK):

Each has its own L1 priorityQueue / forced-tx mechanism with chain-specific timing [verify per chain].

Critical audit findings around escape hatches:

The escape hatch must work without sequencer cooperation. Many implementations have the forced-inclusion transaction routed through the sequencer with a “delay timer”; if the sequencer is fully malicious and stops processing, the timer never elapses. Verify the L1-side derivation rules force the transaction into the canonical chain even if the sequencer never observes it.
L1 gas under censorship event = nightmare: a real censorship event means everyone tries to escape simultaneously, gas prices spike, and the escape mechanism becomes economically inaccessible to retail users.
Some “escape hatch” mechanisms only allow native ETH withdrawal, not arbitrary L2 contract calls. If you can’t call withdraw() on the lending protocol you have funds in, the escape hatch hasn’t saved you.
For ZK rollups, the escape hatch is conditional on a working prover. If the prover is offline (centralized), withdrawals stop even if the L1 escape mechanism queues your tx; the state-root needed to verify your balance is never published.

6.3 L1 ↔ L2 message timing

Three time windows live in every rollup:

Window	Optimistic	ZK
L1 → L2 deposit	Minutes (next sequencer block)	Minutes
L2 → L1 withdrawal initiation	Instant on L2	Instant on L2
L2 → L1 withdrawal finalization	7-day challenge window	Hours (after proof)
Bridge availability under sequencer down	After force-inclusion delay (~24h)	After force-inclusion + prover availability

For DeFi protocols that operate cross-L2, the withdrawal timing is the core constraint. A protocol that allows users to “bridge USDC to L1 and back” with 7-day finality on optimistic is fundamentally different from one on a ZK chain with 6-hour finality.

Fast bridges (LayerZero, Across, Stargate, Synapse, hop) work around this by fronting liquidity: a relayer pays the user on L1 immediately and waits for the slow canonical withdrawal to refill. This adds a separate trust model (the relayer / liquidity provider) on top of the L2’s. See Tuan-10-Bridge-Cross-Chain-Security.

6.4 Upgrade authority

The single most under-disclosed L2 risk.

For each L2 in scope, identify:

Bridge upgrade authority: who can change the L1 bridge contract?
Verifier upgrade authority (ZK only): who can change the L1 verifier?
Predeploy upgrade authority (OP Stack): predeploys on L2 (like the cross-domain messenger) can sometimes be upgraded via L1 admin actions.
Timelock duration: instant, 3 days, 12 days?
Veto / Security Council: is there a multisig that can block / accelerate upgrades?
DAO involvement: token-vote in the loop?

Typical patterns in 2026 [verify per chain]:

OP Mainnet: upgrade controlled by Optimism Security Council + Optimism Foundation; significant timelock for non-emergency.
Arbitrum: upgrade controlled by ArbitrumDAO + Security Council; timelock varies.
zkSync Era: 3-day timelock + DAO + Security Council (6/12) for standard; emergency path via 3/3 multisig with no timelock.
Most others: M-of-N multisig + various timelocks; usually shorter than they should be.

Auditor formulation: “If the upgrade multisig is compromised, X people / Y hours stand between the attacker and the entire L2 TVL.” Then evaluate whether X and Y are commensurate with the value at risk. For chains with $1B+ TVL, X should be >=8 and Y should be measured in days, not hours. Most L2s fall short of this on at least one path.

6.5 Pause / circuit breaker

A pause function on the L1 bridge can:

Stop deposits (preventing new fund inflow while a bug is investigated).
Stop withdrawals (catastrophic if abused — funds locked).
Pause both.

Who can pause? For how long? What rationale?

A unilateral withdraw pause by a small multisig is a freezing vector. The audit finding writes itself: “A 2-of-5 Sequencer Operator multisig can pause all withdrawals indefinitely; users cannot exit the chain without DAO override.”

6.6 Bridge contract reentrancy and replay

The L1 bridge processes proofs of L2 events and executes corresponding L1 actions. Specific risks:

Reentrancy via relayMessage callback: L1 bridge calls into user-specified target contract during finalization. If the bridge writes finalized-flag after the external call, reentrancy can finalize the same withdrawal twice.
Replay of L2 → L1 messages: every proven withdrawal must be marked as consumed. Missing this flag, or a flag keyed on hashing that has collisions, enables replay.
Confused-deputy on xDomainMessageSender: when L1 contract code asks “who sent this message from L2?”, the bridge must return the right sender. Bugs here have appeared multiple times in L2 history.

For OP Stack specifically: the historical OVM_L1CrossDomainMessenger had this class of bug pre-Bedrock. Bedrock cleaned it up but the audit angle persists in any OP Stack fork — check the fork’s exact version.

6.7 Cross L1↔L2 reentry / replay

Beyond the bridge itself, app-level code must defend against:

Withdrawal replay on the L1 side of a third-party bridge.
L1→L2 message that triggers L2 state that emits a L2→L1 withdrawal that loops back. Most L2 OS implementations defend against this; verify it for the specific chain.
Message ordering: if your protocol relies on L1→L2 messages arriving in order, verify this assumption against the OS. Some OS implementations do not guarantee strict ordering across separate inbox queues.

7. L2Beat Framework — Use It Religiously

L2Beat is the closest thing the industry has to an L2 risk-rating consensus. Treat it as the ground truth for audit-time disclosures (and verify it against on-chain reality yourself for each finding).

7.1 The Stages framework

L2Beat groups rollups into three maturity stages [verify the precise current criteria]:

Stage 0 — Full training wheels:

Source-available L2 software; any user can in principle reconstruct state from L1 data.
But the operator still has unilateral upgrade authority (or close to it).
Most “ZK L2s” are here as of 2026.

Stage 1 — Limited training wheels:

Functional fraud-proof system (optimistic) or validity-proof system (ZK).
Permissionless fraud-proof submission (anyone can challenge).
User can exit without sequencer coordination.
Security Council can intervene only for specific on-chain-adjudicable bugs.

Stage 2 — No training wheels:

Fraud / validity proofs are fully permissionless.
Upgrades go through significant time delays giving users time to exit.
Security Council role minimized to provable bugs only.

Auditor’s reading: Stage 0 = “trust this team”; Stage 1 = “trust this team less, but they still have escape hatches we depend on”; Stage 2 = “code is law, ish”. As of 2026, very few L2s are Stage 2 [verify on L2Beat]. Arbitrum One and OP Mainnet are Stage 1; many ZK L2s remain Stage 0.

7.2 The risk rows

L2Beat surfaces a row of “colored” risk indicators per chain (the exact set evolves):

State validation: how is the rollup state validated? (None / Fraud proofs / ZK proofs)
Data availability: where is the data? (L1 / Off-chain DAC / External DA)
Sequencer failure: what happens if the sequencer fails / censors? (Force-tx available, with delay; or no recourse)
Proposer failure: what happens if the state proposer fails? (Permissioned and only proposer can update; or permissionless)
Upgradeability: how is the chain upgraded? (Instant / Delayed / DAO+Timelock / etc.)

Use in audit: for each L2 your protocol deploys to, screenshot the L2Beat risk row at audit start, list each red/orange cell as an explicit trust assumption the protocol inherits. Don’t let the protocol team paper over this with “L2 is secure”.

7.3 What “worst color” means in practice

When you see a red row on L2Beat, that’s not “an idiosyncrasy”. It’s the protocol-team’s-most-significant-claim-of-trust translated into a visual. For example, if the Upgradeability cell is red because “Code can be changed by a 3/5 multisig with no delay”, then the chain’s effective security is the minimum of (its protocol design, the 3/5 multisig’s operational security). Every other guarantee the chain provides is conditional on that multisig not being compromised.

The auditor’s translation: a single red row reduces the chain’s effective security to the level of that row’s mechanism. Don’t average green and red — take the minimum.

8. Shared Sequencers (Forward-Looking)

Most L2s today have a single sequencer (the team’s). The decentralized-sequencer projects worth watching:

8.1 Espresso Systems

A network that sells sequencing-as-a-service to multiple rollups. Rollups plug their sequencer interface into Espresso, which orders transactions across rollups and provides shared finality.

The pitch: cross-rollup atomic composability. A trade that needs to atomically clear a swap on Rollup A and a swap on Rollup B can be ordered into the same shared block, with consistency across both. As of 2026, full atomic execution across rollups is still an open problem (shared ordering is achieved; shared atomicity requires extra protocol work like bundling / dispute handling) [verify].

8.2 Astria

A shared-sequencer network for optimistic rollups; uses CometBFT (Tendermint) for consensus, posts to Celestia for DA.

The pitch: a decentralized sequencer plus a decentralized DA layer for many rollups, all in one stack. Built specifically for the “lazy rollup” pattern where the rollup VM doesn’t have to run consensus or DA.

8.3 Why this matters to auditors

A protocol that deploys to a shared-sequencer L2 has a different sequencer-trust model than the same protocol on a single-team sequencer:

Censorship resistance: better (no single operator).
MEV extraction: changes; now distributed across the sequencer set; new bundle/auction dynamics.
Sequencer failure: a network-wide consensus failure now affects multiple rollups simultaneously — a different shape of correlated risk.
Cross-rollup atomicity (if achieved): opens new compositional surfaces for cross-rollup arbitrage and new attack surfaces (cross-rollup reentrancy, MEV across atoms).

For auditors in 2026, this is mostly horizon-scanning — most protocols don’t deploy to shared-sequenced chains yet. But every audit that lasts beyond 6 months has to anticipate the chain’s migration plan.

9. The Modular Stack View

The intellectual shift since ~2021 is the modular thesis: a blockchain is not one monolithic system; it’s a stack of replaceable modules:

+----------------------------+
| Execution (the VM)         |  ← EVM / Cairo / SVM / MoveVM / custom
+----------------------------+
| Settlement                 |  ← Ethereum L1 / a settlement L2 / Celestia (no settlement!) / etc.
+----------------------------+
| Consensus                  |  ← inherited from settlement, or separate (CometBFT, Babylon, etc.)
+----------------------------+
| Data Availability          |  ← Ethereum blobs / Celestia / EigenDA / Avail / DAC
+----------------------------+

A “monolithic chain” (Ethereum L1, Solana) implements all four layers itself. A “modular chain” picks each layer separately.

Auditor implications:

Layer	If broken	Effect
Execution	Wrong state transition	Bugs in this rollup; not other rollups using same DA
Settlement	Settlement chain rolls back / changes consensus	All rollups using this settlement chain affected
Consensus	Liveness failure	Chain stops
DA	Data withheld	State frozen; possibly recoverable, possibly not

Modular = composable trust assumptions. Every additional module is another supply-chain entry. The auditor’s mandate: explicit, per-module, named-party trust statement.

10. Lab — Walking the L2 Trust Path End-to-End

10.1 Lab goal

Build hands-on intuition for:

Reading the actual L1 contracts that secure an L2.
Walking through a withdrawal end-to-end.
Reading L2Beat as an auditor (not just a user).
Reasoning about forced-inclusion in code.

All commands assume Foundry installed and a working Ethereum RPC. Use a public RPC for read-only ops (e.g., Llama Nodes, Ankr, Cloudflare ETH gateway). For write/test ops, use a free Sepolia faucet.

10.2 Exercise 1 — Read the OP Stack `L2OutputOracle` on mainnet

The Optimism mainnet bridge architecture pre-Bedrock used L2OutputOracle to track L2 state roots; post-Bedrock the architecture shifted toward DisputeGameFactory + OptimismPortal2 once fault proofs went live. [verify the current Optimism architecture against docs at audit time.] We’ll read both shapes.

# Address — verify current value from https://docs.optimism.io/chain/addresses
# (As of late-2024 / early-2026 the value referenced was:)
ORACLE=0xdfe97868233d1aa3e83a5c11343e7e72b8b8e6a8   # L2OutputOracle [verify]
 
# Read the proposer
cast call $ORACLE "PROPOSER()(address)" --rpc-url $ETH_RPC
 
# Read the challenger
cast call $ORACLE "CHALLENGER()(address)" --rpc-url $ETH_RPC
 
# Read the finalization period (seconds)
cast call $ORACLE "FINALIZATION_PERIOD_SECONDS()(uint256)" --rpc-url $ETH_RPC
 
# Get the next output index to be proposed
cast call $ORACLE "nextOutputIndex()(uint256)" --rpc-url $ETH_RPC
 
# Read the latest output root + its L2 block number + L1 timestamp
cast call $ORACLE "latestOutputIndex()(uint256)" --rpc-url $ETH_RPC
# Then for that index N:
cast call $ORACLE "getL2Output(uint256)((bytes32,uint128,uint128))" $N --rpc-url $ETH_RPC

Tasks:

Note the proposer address. Look it up on Etherscan. Is it an EOA, a multisig, or a contract?
Note the challenger address. Is it the same set of people? What does this tell you about the rollup’s adversarial assumption?
Compute: how many output roots has Optimism posted? At what cadence (use getL2Output for two recent indices and diff the timestamps)?
Read the finalization period. Confirm it’s ~7 days (604800 seconds).

If the L2OutputOracle has been deprecated in favor of DisputeGameFactory/OptimismPortal2, the analogous walk-through is: read respectedGameType() on OptimismPortal2, then list the latest DisputeGame deployments via the factory, then read each game’s bond, challenger, and status. The audit takeaway is the same: who’s authorized to propose, who’s authorized to challenge, what’s the timing.

10.3 Exercise 2 — Walk a withdrawal end-to-end

Take an existing Optimism mainnet withdrawal (find one on https://optimistic.etherscan.io/withdrawaltx) and walk through the three on-chain actions:

Initiation on L2 — find the L2 transaction that called L2ToL1MessagePasser.initiateWithdrawal(...). Note the calldata, the amount, the target on L1.
Proof on L1 — find the L1 transaction that called OptimismPortal.proveWithdrawalTransaction(...). Note the Merkle proof, the output root referenced.
Finalization on L1 — find the L1 transaction that called OptimismPortal.finalizeWithdrawalTransaction(...). This must happen at least 7 days after step 2.

Tasks:

Record the L2 block number of step 1, the L1 block number of step 2, the L1 block number of step 3. Compute the gap.
Identify which L1 contracts are involved: OptimismPortal, L1CrossDomainMessenger, L1StandardBridge, etc. For each, look up the upgrade authority (proxy admin slot).
Auditor write-up: in 200 words, describe what the user had to trust at each step. Be explicit about: “the user trusts that the proposer’s output root is not fraudulent; the user trusts that no successful challenge happens during the 7-day window; the user trusts that the L1 bridge is not upgraded to a malicious version during that window.”

10.4 Exercise 3 — Read L2Beat for two L2s side-by-side

Pick one optimistic (Arbitrum One or OP Mainnet) and one ZK (zkSync Era or Scroll). For each:

Go to https://l2beat.com/scaling/projects/<chain>.
Note the stage (Stage 0 / 1 / 2).
Note the worst-color row in the risk panel — typically Upgradeability, State Validation, or Sequencer Failure.
For that row, click through to read the rationale.

Tasks:

Tabulate: chain, stage, worst row, what’s red about it, what’s the recourse.
Reason about: if you had $10M to deposit today, which would you pick and why? Specifically what does each chain’s worst row imply for your downside?
Note: the answer isn’t “both are red so both are bad”. The right framing is “where would you rather take risk, and is the risk you’d take consistent with the protocol you’re deploying”?

10.5 Exercise 4 — Forced-inclusion mechanism

Pick Arbitrum (best-documented forced-inclusion). On Sepolia or in code, walk through:

Read https://docs.arbitrum.io/how-arbitrum-works/deep-dives/sequencer — identify the SequencerInbox.forceInclusion function signature and the 24-hour delay constant.
Locate SequencerInbox on Sepolia.
Write a Foundry script that: a. Submits a delayed message via the L1 inbox. b. Waits the delay (simulate with vm.warp in a fork test). c. Calls forceInclusion and asserts the message is now in the L2 derivation queue.

// test/ArbitrumForceInclusion.t.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
 
import "forge-std/Test.sol";
 
interface ISequencerInbox {
    function forceInclusion(
        uint256 _totalDelayedMessagesRead,
        uint8 kind,
        uint64[2] calldata l1BlockAndTime,
        uint256 baseFeeL1,
        address sender,
        bytes32 messageDataHash
    ) external;
 
    function maxTimeVariation()
        external
        view
        returns (uint256 delayBlocks, uint256 futureBlocks, uint256 delaySeconds, uint256 futureSeconds);
}
 
contract ArbitrumForceInclusionTest is Test {
    // Address — verify against current Arbitrum docs for the network you fork
    ISequencerInbox constant SEQ_INBOX = ISequencerInbox(0x5a563d28cebDdDCBA9aF67D107811cd1A8Ad8E03);
 
    function setUp() public {
        // Fork mainnet at recent block; assumes RPC env var
        vm.createSelectFork(vm.envString("ETH_RPC"));
    }
 
    function test_delay_constants() public view {
        (uint256 delayBlocks, , uint256 delaySeconds, ) = SEQ_INBOX.maxTimeVariation();
        emit log_named_uint("delay blocks", delayBlocks);
        emit log_named_uint("delay seconds", delaySeconds);
        // Expected: delaySeconds ~= 86400 (24h) [verify]
        assertGe(delaySeconds, 60 * 60); // at least an hour
    }
}

Run: forge test --match-test test_delay_constants -vv

Discussion:

Why is the delay 24 hours? Because the sequencer needs time to sequence the tx; without the delay, anyone could grief the rollup by repeatedly forcing inclusion of garbage.
What happens if the sequencer ignores all transactions for >24h? The forced-inclusion path becomes active, and L1 derivation will pick up the queued messages even without the sequencer’s participation. This is the chain’s escape valve.
Auditor finding template: “If the sequencer goes down or censors, a user can force-include a withdrawal after <delay>. In a chain-wide censorship event, L1 gas spikes would likely make this mechanism inaccessible to retail users without significant L1 ETH on hand.”

10.6 Stretch — Read a Verifier contract

Pick zkSync Era or Scroll. Find the verifier contract (via L2Beat → contracts tab, or chain docs). On Etherscan:

Read the verifier proxy’s implementation slot (EIP-1967 slot 0x360894...).
Identify the upgrade authority.
Read one recent proof-submission transaction’s calldata. Identify which function on the verifier is called.
Note the gas cost. Compare to a typical L1 transaction.

Discussion: the verifier is the security-critical contract for a ZK rollup. Anyone who can swap it out can mint state. Bond that observation to the upgrade-authority analysis.

10.7 Expected learning outcome

After this lab, you can:

Quote the actual on-chain addresses of the major L2 components for at least one optimistic and one ZK chain.
Trace any L2 withdrawal on a block explorer step by step.
Read L2Beat’s risk page as an auditor’s checklist, not as a user dashboard.
Reason about forced-inclusion code without confusing it with normal deposit/withdraw flows.

11. Anti-patterns (cataloged for the audit checklist)

Add to your developing audit checklist:

12. Trade-offs and Open Debates

Decision	Option A	Option B	Auditor view
L2 family	Optimistic	ZK	Optimistic = 7-day exit; ZK = hours but higher centralization in prover. Pick based on whether your protocol cares about withdrawal latency or capital-efficiency.
DA	On-L1 blobs	External DA (Celestia/EigenDA/Avail)	On-L1 = strictly more secure; external DA = strictly cheaper. For high-TVL, on-L1. For app-chains with weak threat model, external is acceptable with disclosure.
Sequencer model	Centralized	Shared / decentralized	Shared still nascent in 2026. Default centralized today, but design the protocol so migration is easy.
Verifier upgrade	Instant emergency	Long timelock only	Instant emergency is a back door. The defensible argument is “only for soundness bugs that are themselves verifiable on-chain”. If the emergency path is “we noticed something we don’t like”, that’s not soundness, that’s discretionary control.
Force inclusion delay	24h (Arbitrum-style)	Instant (some others)	Instant looks better but enables sequencer DOS via spam. 24h is a defensible compromise.
Cross-L2 strategy	Native bridge each direction	Third-party bridge (LayerZero, Across)	Native = slowest but most-trust-minimized. Third-party = fast but adds a separate trust model. Real apps mix both, with native as fallback.
Multi-deploy	Same contract address everywhere via CREATE2	Different addresses, manage upgrades per chain	Same address is great for UX, dangerous for upgrade discipline. Document and verify.

13. Quiz (self-check, ≥80% to advance)

Q: A protocol claims “we deploy on Optimism, which is fully secured by Ethereum”. An auditor counters: “name three trust assumptions that statement hides”. What are three? A: (1) Sequencer is currently centralized and operated by a single team; (2) Upgrade authority for the OP Stack contracts on L1 is concentrated in a Security Council + Foundation rather than Ethereum itself; (3) Fraud-proof system is permissioned/recently-permissionless [verify] — until permissionless, only specific actors can challenge. Other valid answers: data availability via blob retention (~18-day cliff); prover-equivalent risk doesn’t exist but proposer can collude with sequencer; L1 finalization relies on Ethereum but L2 itself relies on the sequencer’s honesty for soft finality.
Q: An L2 is described as a “ZK rollup”. The auditor’s checklist for the L1 verifier contract has at minimum which questions? A: (a) Who can upgrade the verifier? (b) What timelock applies? (c) Is there a Security Council veto on emergency upgrades? (d) What’s the multisig threshold for the upgrader? (e) Has the verifier been audited by a top firm? (f) If the trusted setup applies, who participated and where can the ceremony output be verified? Bonus: (g) is there an emergency-pause path that effectively bypasses the upgrade controls?
Q: Define data-availability sampling in one sentence. Why does it allow DA layers to scale beyond Ethereum’s blob throughput? A: Light clients sample random small chunks of each block (after erasure coding) and probabilistically verify that all data is available, without any single client downloading the full block. This means block-size can grow without each verifier’s bandwidth needing to grow.
Q: What’s the worst-case scenario for a validium user, and why is it not “money stolen”? A: The DAC withholds data. Funds aren’t stolen — the validity proofs guarantee state-transitions were valid — but users cannot generate the Merkle proofs needed for withdrawal. Funds are frozen, possibly indefinitely. This is the “DA committee compromise” failure mode that distinguishes validiums from rollups.
Q: A user submits a forced-inclusion transaction on Arbitrum. How long, in the worst case, until that transaction is in the canonical L2 chain? A: ~24 hours (the delaySeconds constant in SequencerInbox.maxTimeVariation). [verify current value.] During this window, the sequencer can include the transaction normally; after the window, anyone can force it.
Q: A protocol holds USDC on Optimism. The sequencer goes permanently offline. The protocol’s claim is “user funds are safe — they can always exit via the L1 escape hatch”. Critique this claim. A: Partial truth. (1) Forced inclusion can queue transactions, but if the proposer also goes offline, no L2 state root is posted to L1 and the L1 bridge has nothing to finalize against. (2) Users can only force-include arbitrary L2 calls; whether that lets them call withdraw() on the lending protocol depends on the lending protocol’s reachability without sequencer cooperation. (3) An L1 gas-spike during a real censorship event makes the escape economically inaccessible to most retail users. (4) Even if all of this works, the wait is at least the challenge window + delays.
Q: EIP-4844 blobs are pruned after ~18 days. An L2 audit finding suggests the protocol must mitigate this. Why? What’s a reasonable mitigation? A: After pruning, the L2’s historical state is no longer reconstructible from Ethereum’s own data. If the chain goes dormant and the team’s archive is lost, state becomes unrecoverable. Mitigation: third-party blob archive (e.g., a separate DA layer for cold storage), the team’s own archive node, an L2-archive consortium, or fallback to calldata for the most-critical batches.
Q: L2Beat shows Chain X as Stage 1. Chain Y as Stage 0. The protocol team picks Chain Y for “better fees”. The auditor’s response? A: Document the trust gap precisely: Stage 0 means the chain depends on the operator’s discretion for upgrades and possibly for fraud-proof submission; Stage 1 has at least permissionless fraud proofs + working user-exit. The fee difference is the visible trade; the invisible trade is a strictly higher trust dependency. The protocol must (a) disclose this in user docs, (b) maintain the ability to migrate to Stage 1+ chains, (c) ideally not deploy until the chain reaches Stage 1, if TVL warrants it.
Q: A shared sequencer is integrated. How does this change MEV extraction relative to a single-team sequencer? A: MEV extraction shifts from “the team’s sequencer captures arbitrage” to “the shared sequencer set captures arbitrage, then auctions/distributes it according to its policy”. Cross-rollup MEV (atomic arbitrage between Rollup A and Rollup B) becomes structurally possible, which is both a feature (markets price more efficiently) and a risk (new sandwich-style flows that don’t exist on single-chain sequencers). For auditors, the protocol’s MEV-sensitivity needs re-evaluation under cross-rollup ordering.
Q: The L1 bridge contract for an L2 has a pauseWithdrawals function callable by a 2-of-3 multisig with no timelock. The chain’s TVL is $1 B . S e v er i t y ? * * A * * : H i g ha t minim u m; a r gu ab l y C r i t i c a l d e p e n d in g o n t h e a u d i t f i r m^{'} sr u b r i c . J u s t i f i c a t i o n : ana tt a c k er w h oco m p ro mi ses 2 o f 3 s i g n ersc an f reeze$ 1B indefinitely. Pause is not “loss of funds” in the literal sense, but indefinite freezing of $1B of user assets is functionally equivalent for severity scoring. Mitigation must include either (a) higher threshold, (b) timelock, (c) DAO override path, or all three.

14. Week 11 Deliverables

L2Beat audit-time snapshot for two chains; risk-row analysis written up in your notes.
End-to-end withdrawal walk-through (L2 init → L1 prove → L1 finalize) for one mainnet withdrawal on Optimism (or Arbitrum); diagram with timestamps annotated.
Read and summarize the upgrade authority for the L1 bridge of one optimistic chain and one ZK chain.
Foundry test of forced-inclusion delay constants on Sepolia (or testnet equivalent) for at least one chain.
One paragraph: “If I were auditing a $100M TVL DeFi protocol that deploys to a Stage 0 ZK rollup, what specific risks would I list in my report?”
Personal trust-seam diagram for an arbitrary L2 (any of the ones in §3.5), annotated.
Master audit checklist updated with §11’s anti-patterns.

15. Where this leads

Next week: Tuan-12-Wallet-AA-Key-Management. After two weeks deep in multi-chain trust models (bridges, then L2s), the focus shifts to the user’s edge of the stack — wallets, account abstraction, key management. Many of the L2 trust assumptions only become operationally meaningful when paired with how a user interacts; e.g., AA on zkSync Era is native and changes the signature model, while AA on OP Stack is via ERC-4337 as on L1. The combined picture — how does a real user-facing transaction on an L2-deployed AA wallet propagate trust — is a Week 12 + 11 composition.

The shift in mindset: through Week 11, the auditor’s mental model has been “where is the trust?” — answered at protocol layer. From Week 12 forward, it’s “who’s actually signing what, and what are they being shown?” — which centers the user as the final adversarial trust seam.

Last updated: 2026-05-16 See also: Roadmap · References · MOC-Web3-Security-Mastery · Tuan-10-Bridge-Cross-Chain-Security · Tuan-12-Wallet-AA-Key-Management

lthieu's notes

Explorer

Tuan-11-L2-Rollup-Modular-Security

Week 11 — L2, Rollups & Modular Blockchain Security

1. Context & Why

1.1 The audit reframe

1.2 The three orthogonal questions

1.3 What you’ll be able to do by Friday

1.4 Primary references

2. Why L2 Exists — and the Cost the Auditor Must Account For

2.1 The scalability trilemma applied to rollups

2.2 The auditor’s reframe of “secured by Ethereum”

2.3 Rollup-centric roadmap → Endgame

3. Rollup Taxonomy

3.1 The 2x3x2 cube

3.2 Optimistic rollups in depth

3.3 ZK rollups in depth

3.4 Validium and Volition

3.5 The headline rollups, briefly [verify all]

4. The Rollup Components

4.1 Sequencer

4.2 Batcher

4.3 Proposer

4.4 Prover (ZK only)

4.5 L1 Verifier contract (ZK only)

4.6 L1 Bridge contract (the most concentrated risk)

4.7 L2 Messenger

5. Data Availability

5.1 DA = “can someone other than the sequencer reconstruct the state?”

5.2 The DA spectrum

5.3 EIP-4844 (blobs) — the post-Dencun world

5.4 External DA layers

5.5 The DA-sampling concept

6. Audit Angles for L2 / Rollups

6.1 Sequencer trust assumption

6.2 Escape hatch / forced inclusion

6.3 L1 ↔ L2 message timing

6.4 Upgrade authority

6.5 Pause / circuit breaker

6.6 Bridge contract reentrancy and replay

6.7 Cross L1↔L2 reentry / replay

7. L2Beat Framework — Use It Religiously

7.1 The Stages framework

7.2 The risk rows

7.3 What “worst color” means in practice

8. Shared Sequencers (Forward-Looking)

8.1 Espresso Systems

8.2 Astria

8.3 Why this matters to auditors

9. The Modular Stack View

10. Lab — Walking the L2 Trust Path End-to-End

10.1 Lab goal

10.2 Exercise 1 — Read the OP Stack L2OutputOracle on mainnet

10.3 Exercise 2 — Walk a withdrawal end-to-end

10.4 Exercise 3 — Read L2Beat for two L2s side-by-side

10.5 Exercise 4 — Forced-inclusion mechanism

10.6 Stretch — Read a Verifier contract

10.7 Expected learning outcome

11. Anti-patterns (cataloged for the audit checklist)

12. Trade-offs and Open Debates

13. Quiz (self-check, ≥80% to advance)

14. Week 11 Deliverables

15. Where this leads

Graph View

Table of Contents

Backlinks

10.2 Exercise 1 — Read the OP Stack `L2OutputOracle` on mainnet