Forced Inclusion

What Is Forced Inclusion?

Forced inclusion is a censorship-resistance mechanism built into Layer 2 rollups that allows users to submit transactions directly to the L1 blockchain when the L2 sequencer refuses to process them. Under normal operation, rollup users send transactions to a centralized sequencer that orders and batches them for fast, cheap execution. But if that sequencer goes offline, censors specific users, or acts maliciously, forced inclusion provides a fallback path through L1 smart contracts.

The mechanism exists because most rollups today rely on a single sequencer operated by the rollup team. This centralization creates efficiency gains (faster confirmations, lower fees) but introduces a trust assumption: users must trust the sequencer to include their transactions fairly. Forced inclusion removes that trust assumption by giving users recourse at the L1 level, where Ethereum's decentralized validator set provides the ultimate guarantee of inclusion.

Without forced inclusion, a malicious sequencer could effectively trap user funds on L2 by refusing to process withdrawal transactions. This would undermine the core security promise of rollups: that L1 provides the final settlement guarantee. Forced inclusion is what makes that promise credible.

How It Works

The general pattern across rollups follows three steps: a user submits a transaction to an L1 contract, a mandatory delay period passes to give the sequencer time to include it voluntarily, and then either the sequencer processes it or the protocol forces it into the canonical chain.

The specific implementation varies significantly between rollup architectures. The two most widely deployed mechanisms come from Arbitrum and Optimism.

Arbitrum: Delayed Inbox

Arbitrum uses a two-inbox architecture on Ethereum. The SequencerInbox is where the sequencer posts L2 transaction batches under normal operation. The Delayed Inbox (also called the Bridge contract) is where non-sequencer transactions queue on L1.

1. The user calls sendL2Message on the Delayed Inbox contract, submitting their L2 transaction to the L1 queue
2. Under normal conditions, the sequencer voluntarily picks up delayed messages and includes them within approximately 10 minutes
3. If 24 hours pass without the sequencer processing the message, anyone can call forceInclusion() on the SequencerInbox contract
4. This forces all eligible delayed messages into the canonical L2 chain in FIFO (first in, first out) order

The sequencer cannot selectively skip messages in the delayed inbox. Delaying the message at the front of the queue means delaying all messages behind it, which creates economic pressure against censorship.

// Arbitrum forced inclusion flow (simplified)
// Step 1: Submit transaction to Delayed Inbox on L1
const tx = await delayedInbox.sendL2Message(l2CallData);

// Step 2: Wait for the 24-hour inclusion window
// The sequencer should include it voluntarily within ~10 min

// Step 3: If sequencer fails to include after 24 hours,
// anyone can force it
await sequencerInbox.forceInclusion(
  messageIndex,
  l1BlockNumber,
  timestamp
);

Optimism: L1 Deposit Transactions

The Optimism (OP Stack) approach works differently. Instead of a separate inbox, users call depositTransaction() on the OptimismPortal contract on L1. This emits a TransactionDeposited event that rollup nodes must include when deriving the L2 chain state.

1. The user calls depositTransaction() on the OptimismPortal contract on Ethereum
2. This emits a TransactionDeposited event on L1
3. Rollup nodes monitor L1 for these events and are required by the derivation rules to include them
4. The sequencer has a maximum drift window of 30 minutes to include the deposit, with a broader 12-hour sequencing window as the outer bound

If the sequencer is down for more than 12 hours, OP Stack nodes begin generating blocks deterministically using only L1 deposit transactions. This means the chain continues operating (albeit in a degraded mode) even with a completely offline sequencer.

Other Rollup Implementations

ZK rollups also implement forced inclusion, though with varying degrees of completeness:

• zkSync Era uses a priority queue via the BridgeHub contract, where L1-submitted transactions are appended and must be processed during batch execution
• Based rollups like Taiko take a fundamentally different approach: they delegate sequencing to Ethereum L1 validators entirely, making forced inclusion the default rather than a fallback
• StarkNet currently lacks protocol-level forced inclusion, though application-level escape hatches exist for bridge contracts

Why Forced Inclusion Matters

Forced inclusion is what separates a true rollup from a system where users must fully trust the operator. The security model of a rollup rests on a fundamental claim: L1 provides the ultimate guarantee of fund safety. Without forced inclusion, that claim breaks down because a censoring sequencer could prevent users from ever withdrawing.

L2Beat, the leading rollup risk assessment platform, explicitly evaluates forced inclusion as a security property in their framework. Their analysis has found that roughly 13% of rollup projects have no credible forced inclusion path, meaning users of those systems have no recourse if the sequencer censors them.

For Bitcoin L2 solutions, the same principle applies: users need a guaranteed path to exit with their funds regardless of operator behavior. The trust model comparison across Bitcoin L2s examines how different architectures handle this guarantee, including mechanisms analogous to forced inclusion like unilateral exits on statechains and force-close channels on Lightning.

The broader lesson from Ethereum's rollup ecosystem is that censorship resistance cannot be an afterthought. Systems that launch without forced inclusion often struggle to add it later because the mechanism touches core components of the sequencing and derivation pipeline. The lessons from Ethereum L2s for Bitcoin scaling explore how Bitcoin-native solutions can learn from these architectural decisions.

Use Cases

Withdrawal Under Censorship

The most critical use case: withdrawing funds when the sequencer refuses to process your transaction. A user holding assets on an L2 can submit a withdrawal transaction through the L1 forced inclusion path, ensuring they can always exit the rollup with their funds. This is the minimum viable escape hatch that any rollup must provide.

DeFi Liquidation Protection

Users with DeFi positions on L2 (lending, borrowing, margin trading) face liquidation risk if they cannot interact with protocols. If a sequencer goes down during a market crash, forced inclusion allows users to submit collateral top-ups or position closures through L1, potentially saving them from liquidation.

Regulatory Compliance

For institutions operating on L2 rollups, forced inclusion provides a compliance guarantee: funds cannot be permanently frozen by a third party (the sequencer operator). This is particularly relevant for regulated entities that need assurance about asset accessibility and cannot accept a single point of failure in their custody chain.

Sequencer Downtime Recovery

When a sequencer experiences unplanned downtime (as happened with Arbitrum's sequencer in January 2024 during a ~78-minute outage caused by inscription-related congestion), forced inclusion ensures the chain can continue processing critical transactions. While the 24-hour delay on Arbitrum means short outages resolve before forced inclusion activates, the mechanism remains the ultimate backstop.

Risks and Considerations

Significantly Higher Costs

Forced inclusion requires submitting transaction data to L1, which means paying L1 gas fees. On Optimism, a forced deposit transaction costs approximately $4 in L1 gas, compared to roughly $0.0007 for a normal sequenced transaction. On Arbitrum, the cost is approximately $6 versus $0.002 for normal transactions. This represents a premium of 2,000x to 5,000x, making forced inclusion impractical for routine use and viable only as an emergency fallback.

Mandatory Delay Periods

Forced inclusion is not instant. Arbitrum imposes a 24-hour delay before forceInclusion() can be called, compared to sub-second sequencer confirmations. Optimism's deposit transactions face delays of 30 minutes to 12 hours depending on sequencer behavior. These delays are intentional: they give the sequencer time to include transactions voluntarily and prevent abuse of the forced inclusion path.

Inclusion Does Not Guarantee Execution Success

A subtle but important limitation: forced inclusion guarantees that a transaction will be included in the L2 chain, but not that it will execute successfully. A malicious sequencer can front-run a forced transaction by modifying the L2 state before it executes. For example, a sequencer could manipulate a DEX pool's price to cause a forced swap transaction to revert due to slippage limits. This means forced inclusion protects simple transfers and withdrawals effectively, but complex DeFi interactions may still be vulnerable to sequencer manipulation.

UX and Accessibility Barriers

Using forced inclusion today requires interacting directly with L1 smart contracts. Users need L1 ETH for gas (even if all their assets are on L2), knowledge of the correct contract addresses and function calls, and the technical ability to construct and submit L1 transactions. Most wallet interfaces do not expose forced inclusion as a feature, making it practically inaccessible to non-technical users. Developer SDKs (like Arbitrum's InboxTools) exist but are designed for application developers rather than end users.

Incomplete Adoption

Not all rollups have implemented forced inclusion. StarkNet currently lacks a protocol-level mechanism, and Polygon zkEVM has the code in place but keeps it disabled. L2Beat's risk framework tracks this gap: roughly half of all rollup projects have proposer failure scenarios that can freeze withdrawals, even when forced inclusion exists. A complete escape hatch requires both forced inclusion (to bypass the sequencer) and forced withdrawal (to bypass the proposer), and many rollups only implement one or neither.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.