3.11.8 Layer 2 Considerations

For most of Ethereum's history, "deploying a smart contract" meant deploying on Ethereum mainnet. Today the majority of new deployments happen on Layer 2s. Over $30 billion sits in Ethereum L2 contracts as of late 2025, distributed across Arbitrum, Optimism, Base, zkSync, Polygon zkEVM, StarkNet, Scroll, Linea, Blast, and dozens of others. The economics make L2 deployment the default: mainnet transactions cost tens of dollars during congestion; L2 transactions cost cents. Most new users have never used L1.

For a security-conscious protocol developer, L2 deployment introduces a category of considerations that don't exist on L1. The L2's security model differs from L1's. The L2's operational maturity differs. The L2's tooling differs. The L2's transaction ordering differs. And the relationship between L1 contracts and L2 contracts — which is itself a cross-chain relationship — introduces bridge-like trust assumptions that are easy to overlook because they appear to be "within the same ecosystem."

This subsection covers what changes when contracts deploy on L2s rather than L1. The historical case studies in Section 3.10 are largely L1 incidents; the patterns in earlier sections of 3.11 apply across both. What follows is L2-specific: how the rollup architecture affects security, what the sequencer's role implies, how L1-L2 messaging works in practice, and what additional considerations protocols should evaluate when choosing where to deploy.

The L2 Landscape, Briefly

L2s fall into a few categories, each with distinct security properties:

Optimistic rollups (Arbitrum, Optimism, Base, Blast, others). Transactions execute on the L2; periodically, the sequencer posts a state commitment to L1. The commitment is assumed valid unless someone submits a fraud proof during a challenge window (typically 7 days). Fraud proofs revert invalid batches.

ZK rollups (zkSync Era, Polygon zkEVM, StarkNet, Scroll, Linea). Transactions execute on the L2; the prover generates a cryptographic proof that the resulting state is valid. The proof is verified on L1 in a single contract call. No challenge window is needed because validity is proven, not assumed.

Validiums (StarkNet's Validium mode, ImmutableX, some custom L2s). Like ZK rollups, but data availability is stored off-chain rather than on L1. Cheaper than rollups; weaker security because data unavailability can prevent users from reconstructing state.

Sidechains (Polygon PoS, BNB Chain, Avalanche C-Chain, Ronin). Independent chains with their own consensus, connected to Ethereum via a bridge. Not technically L2s in the strict sense — they don't inherit Ethereum's security — but often grouped together in discussions of "L2 deployment."

App-specific rollups / OP Stack / ZK Stack chains. Many protocols now deploy their own rollups using shared infrastructure (OP Stack from Optimism, Polygon CDK, Arbitrum Orbit, zkSync ZK Stack). These inherit the underlying stack's security model with customizations.

The L2BEAT framework classifies L2s into Stages 0, 1, and 2 based on decentralization maturity:

  • Stage 0: training wheels — fully centralized sequencer, no fraud proofs running, governance can upgrade contracts unilaterally
  • Stage 1: limited training wheels — fraud proofs operational, but the security council can override (or proofs are not yet fully permissionless)
  • Stage 2: full decentralization — fraud proofs permissionless, security council removed or limited to safety-critical functions, full censorship resistance

As of late 2025, no major L2 has fully reached Stage 2. Arbitrum, Optimism, and Base are at Stage 1. zkSync, Polygon zkEVM, and StarkNet are at Stage 1 or earlier. This is not a hidden detail — L2BEAT publishes status publicly — but many protocols deploy on L2s without internalizing what "Stage 1" actually means for their security model.

The Sequencer Is a Trust Assumption

Every L2 today has a sequencer — a single (or small set of) entity that orders transactions before they reach L1. The sequencer's role:

  • Receives user transactions via RPC
  • Orders them
  • Executes them on L2
  • Provides users with "soft confirmation" (the sequencer's promise that the transaction will be included)
  • Periodically posts batches to L1

For most L2s in 2025, the sequencer is operated by the L2 team itself (Offchain Labs runs Arbitrum's sequencer; Optimism Foundation runs Optimism's; Coinbase runs Base's). The sequencer has substantial power:

  • Ordering: can reorder transactions arbitrarily within batches, extracting MEV
  • Censorship: can refuse to include specific transactions
  • Liveness control: can delay transactions, effectively pausing the chain
  • Front-running: can submit its own transactions ahead of user transactions

In practice, mainstream sequencers operationally do not extract MEV from their users or censor (their reputation depends on neutrality). The trust model is "the sequencer chooses not to abuse its power," not "the sequencer cannot abuse its power."

What Protocols Should Assume About the Sequencer

The conservative threat model: the sequencer can do anything within its powers; assume it might.

This affects several design decisions:

  • MEV-sensitive operations: a sequencer extracting MEV is theoretically possible. If your protocol's economics depend on neutral ordering, this is a risk.
  • Time-sensitive operations: a sequencer that delays a transaction by minutes can affect price-dependent operations (liquidations, oracle reads, deadline-sensitive trades).
  • Censorship resistance: a user who needs to interact with your protocol in a specific block (e.g., to avoid liquidation) cannot rely on the sequencer to include their transaction. Force-inclusion mechanisms (see below) exist but have their own latency.

For high-stakes protocols, the design should be robust under adversarial sequencer behavior, not merely "the sequencer is operationally honest right now."

Decentralized Sequencer Plans

The L2 ecosystem has been working on decentralized sequencer designs since at least 2022. Several approaches are in development:

  • Shared sequencer networks (Espresso, Astria) — multiple L2s share a single decentralized sequencer set
  • Based sequencing — sequencing happens via L1 block proposers, inheriting L1's security
  • Sequencer auctions — proposers bid for sequencing rights; rotation prevents long-term capture

As of late 2025, none of these has been deployed at scale on a major L2. The roadmaps are public; the timelines have repeatedly slipped. A protocol deploying today should design for a centralized sequencer reality, with the understanding that this may change in the coming years.

L1-to-L2 and L2-to-L1 Messaging

Every L2 provides messaging primitives between L1 and L2:

  • L1 → L2 deposits: a user locks tokens on L1; the L2 mints corresponding tokens. Typically takes 10-15 minutes (one or two L1 block confirmations plus L2 inclusion).
  • L2 → L1 withdrawals: a user burns tokens on L2; after a delay, they can claim corresponding tokens on L1. Optimistic rollups: 7 days (the challenge period). ZK rollups: typically minutes to hours (depends on proof generation cadence).

The withdrawal delay on optimistic rollups is the largest single UX impact of L2 deployment, and one of the most frequently misunderstood. Users who don't realize the delay exists discover it the first time they try to withdraw.

Native vs. Third-Party Bridges

L2 native bridges (Arbitrum Bridge, Optimism Gateway, etc.) inherit the L2's security model. A native bridge from an optimistic rollup has the 7-day challenge period built in. A native bridge from a ZK rollup is as secure as the proof system.

Third-party bridges (Across, Hop, Stargate, Synapse, others) provide faster withdrawals by fronting capital to users. The user gets their funds in minutes; the bridge provider waits the full delay to recover from L2. The user pays a fee for the speed.

The security tradeoff: third-party bridges have their own security models, which are typically weaker than the native bridge's. The Section 3.10 case studies (Section 3.10.4 Poly Network, Section 3.10.5 Ronin, etc.) include several third-party bridge incidents. Protocols that integrate with third-party bridges inherit those bridges' risks.

Cross-Domain Messages

For arbitrary L1-L2 messaging (beyond token transfers), each L2 provides its own messenger contract. The pattern:

On L1:

// Call the L1 cross-domain messenger to send a message to L2
ICrossDomainMessenger(L1_MESSENGER).sendMessage(
    L2_TARGET,
    abi.encodeWithSelector(IL2Contract.someFunction.selector, params),
    1_000_000  // gas limit for the L2 call
);

On L2:

// L2 contract receives the message; must verify msg.sender is the L2 messenger
contract L2Contract {
    address public immutable l1Sender;  // expected sender on L1
    address public immutable l2Messenger;

    function someFunction(...) external {
        require(msg.sender == l2Messenger, "not messenger");
        require(
            ICrossDomainMessenger(l2Messenger).xDomainMessageSender() == l1Sender,
            "wrong L1 sender"
        );
        // ... execute
    }
}

The pattern looks straightforward but has known footguns:

  • Verifying both msg.sender and xDomainMessageSender(). The L2 messenger is the caller; the original L1 sender is what xDomainMessageSender() returns. Forgetting either check is a vulnerability.
  • Aliased addresses. When an L1 contract sends a message to L2, the xDomainMessageSender() may return an aliased version of the L1 address (offset by a fixed constant). Specifically: Optimism's L1→L2 messaging uses address(uint160(l1Address) + 0x1111000000000000000000000000000000001111). A contract that doesn't account for the alias will reject legitimate L1 calls.
  • Replay across chains. The same message format on different L2s with different messengers must include the chain ID or messenger address in its signed content. Otherwise, a message authorized for chain A may be replayable on chain B.

The Hop Bridge Bug (2023, Conceptual)

A well-known pattern: a protocol's L2 contract accepted a message from "the L1 messenger" and trusted it without checking the original L1 sender. The original L1 caller could be anyone who had paid the messenger to send a message; the L2 contract treated all such messages as authorized.

The fix is the xDomainMessageSender() check. The bug exists when developers think the messenger's msg.sender is the authority, rather than understanding it as the delivery mechanism — analogous to checking that an email arrived via your mail server rather than checking who actually sent it.

Differences from L1 That Affect Contracts

Several specific behaviors differ between L1 and major L2s. Protocols deploying to L2 must verify each:

Block Timestamps

Mainnet block timestamps are produced by the proposer with some tolerance (within 12 seconds of consensus expected). L2 block timestamps depend on the sequencer's clock and may have different behavior:

  • Arbitrum: block timestamps are the L1 block timestamp when the sequencer batches transactions to L1. Multiple L2 blocks may share a timestamp.
  • Optimism: L2 blocks have their own timestamps generated by the sequencer; constraints exist to prevent extreme drift.
  • zkSync Era: similar to Optimism — sequencer-generated.

For contracts using block.timestamp (vesting schedules, time-based locks, etc.), the precision and reliability differ. Avoid sub-second precision; verify behavior on the target chain.

Block Numbers

block.number on L2 refers to the L2 block, not the L1 block. On Arbitrum, block.number returns the most recent L1 block number, not the L2 block number — a footgun for protocols ported from L1 that expect block.number to increment per their own transactions. Arbitrum provides ArbSys.arbBlockNumber() for the L2 block number.

Always verify: which block number does this chain return for block.number? What's the actual cadence?

L2 fee mechanisms differ from L1's EIP-1559. block.basefee on Optimism reflects the L2 fee component, not the L1 data-availability component. Contracts that estimate transaction costs from block.basefee may underestimate L2 costs significantly.

Gas Costs

L2 transactions have two cost components:

  1. L2 execution gas — paid normally per opcode
  2. L1 data availability — the cost of posting the transaction's data to L1

The second component can dwarf the first. On Optimism, a swap that costs 200,000 gas at the L2 layer might have an additional 30,000-100,000 gas-equivalent cost for L1 data publication (depending on calldata size). EIP-4844 (proto-danksharding, March 2024) reduced this cost substantially via blobs, but it's still non-trivial.

For protocols designing gas-efficient code, calldata size matters more on L2 than on L1. Optimizations that reduce storage operations may be irrelevant; optimizations that reduce calldata size are highly impactful.

Precompiles and Opcodes

Most L2s implement the same opcodes as L1, but with edge cases:

  • PUSH0 (Shanghai, April 2023): not initially supported on some L2s; compilers needed to be told to target an earlier EVM version
  • BLOBHASH, BLOBBASEFEE (Cancun, March 2024): some L2s adopted slowly; verify before using in production code
  • L2-specific precompiles: Arbitrum's ArbSys, Optimism's L1Block, others. Using these makes contracts L2-specific (no longer L1-deployable).

For protocols that want to be deployable to both L1 and L2, stick to the EVM common subset and avoid L2-specific precompiles. For L2-only protocols, use the precompiles where useful but document the L2-specificity.

Reorg Behavior

L1 has occasional reorgs but they're rare and shallow (1-2 blocks typically). L2 sequencer outputs are "soft-confirmed" from the user's perspective but not finalized until they reach L1 and pass any challenge window. The actual reorg behavior depends on the L2:

  • Optimistic rollups: theoretical reorgs possible if a fraud proof succeeds during the challenge period, but this has not happened in practice
  • ZK rollups: theoretical reorgs possible if the proof is shown invalid after submission, but proofs are intended to be unconditionally sound
  • Sequencer-level reorgs: more common in practice — a sequencer issue can cause L2 blocks to be rolled back before they reach L1

For protocols with operations that require L1-level finality (e.g., releasing funds based on an L2 event), waiting for L1 finalization is the safe practice. For most user-facing operations, L2 soft confirmations are operationally sufficient.

Force-Inclusion and Escape Hatches

Both optimistic and ZK rollups provide mechanisms for users to bypass the sequencer in specific circumstances:

  • Force-inclusion: a user can submit a transaction directly to L1 that the L2 must include within a deadline (typically 1-24 hours). This prevents the sequencer from indefinitely censoring transactions.
  • Escape hatch: in extreme cases (the sequencer is fully offline or compromised), users can withdraw their assets directly from the L1 contract using cryptographic proofs of ownership.

The escape hatch is the ultimate fallback. Its existence is one of the criteria L2BEAT uses to evaluate L2 decentralization. A protocol depending on an L2 should understand:

  • Does the L2 have a working escape hatch?
  • How long would emergency withdrawal take in a sequencer-failure scenario?
  • Are users' funds recoverable if the L2's governance is compromised?

For most users, the answers are "yes, but slow, and most users don't know the procedures exist." This is acceptable for many use cases. For some protocols (large DAOs, treasury custody), the slow-but-cryptographic escape hatch is part of the value proposition of L2 deployment.

Cross-L2 Considerations

Increasingly, protocols deploy on multiple L2s — and the L2s interact with each other. Some patterns:

  • Same asset on multiple L2s: bridged USDC on Arbitrum is not directly fungible with bridged USDC on Optimism. Cross-L2 transfers go through some bridge (native via L1, or third-party direct). The latency and trust assumptions vary.
  • Cross-L2 arbitrage: searchers move price differences between L2s, paying bridge fees for the round trip. This is a major source of MEV (Section 3.11.3) on both source and destination L2s.
  • Shared sequencing across L2s: emerging designs aim to allow atomic transactions across multiple L2s simultaneously. The security and reliability of these mechanisms are early-stage.

For protocols deploying multi-chain, the key principle: each chain's instance is independent unless explicitly bridged. Don't assume cross-L2 atomicity without verifying the specific mechanism.

Practical Checklist

For a protocol deploying to an L2:

  • L2's security stage (L2BEAT Stage 0/1/2) is documented and acknowledged
  • L2's sequencer is identified, and the protocol's exposure to sequencer misbehavior is bounded
  • L1-L2 messaging (if used) verifies both msg.sender (messenger) and xDomainMessageSender() (original sender)
  • Address aliasing is accounted for in L1→L2 message handling
  • block.timestamp and block.number behavior is verified for the target L2
  • Calldata size is optimized (it's the dominant cost on L2)
  • EVM version compatibility is verified (PUSH0, BLOBHASH, etc.)
  • If using L2-specific precompiles, the L2-specificity is documented
  • Withdrawal latency is documented for users (7 days for optimistic, hours for ZK)
  • Third-party bridge integrations have their own security models reviewed (Section 3.11.5)
  • Reorg behavior for the L2 is understood; operations requiring L1 finality wait for it

For a protocol designing for cross-L2 deployment:

  • Each L2 deployment is treated as an independent instance unless explicitly bridged
  • Bridge between deployments has been evaluated against the criteria in Section 3.11.5
  • Cross-L2 arbitrage and MEV implications are considered (Section 3.11.3)
  • Documentation indicates which deployments are canonical and which are bridge-wrapped

Cross-References

  • Cross-chain and bridge security — Section 3.11.5 covers bridges generally; L2 native bridges share the bridge model
  • MEV — Section 3.11.3 covers L2 MEV dynamics and the sequencer's role
  • Composability — Section 3.11.2 covers the general composability surface that L2s inherit
  • Oracles — Section 3.11.1 covers oracle considerations; on L2, oracle availability and latency may differ
  • Anti-patterns — Section 3.7.7 covers patterns that may behave differently on L2 (gas-related, block-data-related)
  • Defensive patterns — Section 3.7.5 covers rate limits and pause mechanisms; especially relevant on L2 where sequencer behavior may differ
  • Account abstraction — Section 3.11.7 covers AA, which is widely deployed on most major L2s
  • L2BEAT — https://l2beat.com covers current L2 stages, sequencer status, and security ratings
  • OP Stack documentation — https://docs.optimism.io for OP Stack chains
  • Arbitrum documentation — https://docs.arbitrum.io for Arbitrum-specific behaviors
  • L2 Security Framework — Quantstamp's framework for L2 security assessment

Closing Section 3.11

Section 3.11 covered eight areas where smart contract security extends beyond contract code: oracles, composability, MEV, flash loans, bridges, governance, account abstraction, and L2s. Each is an area where the right architectural choices matter as much as the right defensive code patterns. Each is an area where the patterns are still evolving and where developers building today must choose among options that themselves are under development.

Two themes recurred throughout:

The threat model has changed substantially in recent years. Flash loans, MEV-aware searchers, AA wallets, multi-chain deployment — each shifts what "a user" can do to a protocol. Designing under an outdated threat model produces protocols that work correctly against honest users but fail against the actual ecosystem. Section 3.10's case studies are largely failures of threat-modeling, not of code.

Defenses involve tradeoffs. Every recommendation in this section comes with a cost. Better oracles cost more; rate limits add friction; pause mechanisms concentrate power; AA compatibility adds complexity. There is no universally-right answer — the right answer for a specific protocol depends on its specific economics, users, and risk profile.

The next section (3.12) closes Book 3 by surveying emerging trends — formal verification, AI-assisted security, decentralized auditing, post-quantum cryptography, zero-knowledge proof system security, non-EVM execution environments, evolving standards, and cyber insurance. The frontier moves rapidly; the goal of Section 3.12 is not to predict the future but to identify where to watch.