Force Inclusion & Censorship Resistance

The L1 deposit queue, sequencer-bypass timers, escape hatches, and the L2BEAT Stage 0/1/2 classification that distinguishes a real rollup from a multisig with a marketing budget.

25 min · expert · part of Rollup Architecture & L2 Engineering

Why Censorship Resistance Matters

Suppose the Arbitrum sequencer decides — or is compelled — to refuse all transactions from your wallet address. You broadcast a swap. The sequencer drops it. You broadcast a withdrawal. The sequencer drops it. Your funds on Arbitrum are now stuck — accessible to the rollup as data but inaccessible to you as a user. This is not a theoretical concern. Compelled censorship has happened on Ethereum at the L1 builder layer (OFAC-sanctioned addresses being filtered by major MEV-Boost relays). It could happen on L2s at the sequencer layer. Without a mechanism to bypass the sequencer, an L2 user has weaker censorship resistance than an L1 user — even though L2s position themselves as scaling solutions, not security downgrades. Force inclusion is the mechanism that solves this. Every credibly trust-minimized rollup has some version of it: a way for a user to submit a transaction directly to L1 and have it included on L2 after a delay, bypassing the sequencer entirely. This is the "escape hatch" — the property that says even if the sequencer goes rogue, the user can always exit. The presence and quality of force-inclusion mechanisms — along with permissionless fraud proofs and bridge-upgrade governance — is what distinguishes the L2BEAT Stage 0/1/2 tiers. As of 2026 most major L2s sit at Stage 1; very few have achieved Stage 2.

Also in this lesson

Arbitrum forceInclude: The L1 Delayed Inbox
Optimism Deposit Transactions
L2BEAT Stages: 0, 1, and 2
The Practitioner Tradeoffs and What to Watch

Key terms

Force inclusion: The mechanism by which a user can compel inclusion of a transaction on L2 by submitting it directly to an L1 contract and waiting a configured delay, bypassing the sequencer entirely.
DelayedInbox (Arbitrum): The L1 contract on Arbitrum that queues transactions for sequencer pickup. If the sequencer ignores a queued transaction beyond the delay (~24 hours), anyone can call forceInclusion to compel L2 inclusion.
OptimismPortal: The L1 contract on Optimism (and all OP Stack chains: Base, Mode, Zora, etc.) for deposit transactions. The sequencer must include L1-originated deposit events within the sequencing window or the L2 chain is considered invalid.
Sequencing window: The configurable delay in OP Stack chains (~12 hours on Optimism Mainnet) within which the sequencer must include L1 deposit events. Beyond this window, any node can compel inclusion.
L2BEAT Stage 0: The "training wheels" tier. The rollup uses cryptographic methods and posts data to L1, but operators retain meaningful authority (multisig upgrades without sufficient timelocks, proof systems possibly not on mainnet, whitelisted validators).
L2BEAT Stage 1: Limited training wheels. Functional proof system on mainnet, permissionless or multi-operator participation, timelocks on bridge upgrades. Security Council retains constrained override authority. Most major L2s sit here as of 2026.
L2BEAT Stage 2: Training wheels fully off. Autonomous proof system, no human override outside provable-bug emergencies. Very few L2s have reached Stage 2 as of 2026 — the explicit roadmap target for major rollups.
Security Council: A multisig of trusted parties retained by an L2 with emergency override authority (e.g., to pause the bridge or patch a bug). Constrained authority in Stage 1; very narrow authority (provable bugs only) in Stage 2.
Escape hatch: The general property that L2 users can exit their funds to L1 even under sequencer failure or compromise. Combines force-inclusion, working withdrawal proofs, and bridge contract correctness.

Continue this lesson — 4 more sections in the CryptoBipto app.

Open lesson

Educational only — not financial advice.