Force Inclusion

Force Inclusion is a censorship-resistance feature in blockchain protocols, most notably in rollup systems like Optimism and Arbitrum. It functions as a user's ultimate guarantee that a valid transaction will be processed, even if a malicious or faulty sequencer (the entity responsible for ordering transactions) intentionally excludes it. This is achieved by allowing users to submit their transactions directly to the underlying Layer 1 (L1) blockchain, such as Ethereum, which then forces the rollup to include them in its next state update.

The mechanism operates through a delayed submission window. When a user's transaction is ignored by the sequencer, they can submit a proof of this omission—along with the transaction itself—to a smart contract on the L1. After a predefined challenge period (e.g., 24 hours), if the sequencer has still not included the transaction, the L1 contract authorizes its forced inclusion. This process ensures the liveness of the rollup, meaning the network cannot be halted for any individual user.

Force inclusion protects against two primary threats: censorship, where a sequencer blacklists certain addresses, and maximal extractable value (MEV) exploitation, where a sequencer reorders transactions for profit at users' expense. By providing a credible, protocol-enforced alternative path, it aligns the sequencer's incentives with honest behavior. This mechanism is a critical component in maintaining the trust-minimized and permissionless properties of decentralized rollups.

Implementing force inclusion involves careful economic and security design. The delay period must be long enough to allow the sequencer a reasonable time to act but short enough to be practical for users. Furthermore, the cost of submitting to L1 (paying gas fees) acts as a deterrent against spam, ensuring the mechanism is used only when necessary. This creates a balanced system where user rights are protected without overburdening the underlying blockchain.

Force Inclusion is a protocol-level mechanism that allows users to directly submit transactions to the Layer 1 (L1) blockchain, bypassing the rollup's central sequencer, to guarantee their inclusion in the rollup's state. This is a foundational censorship-resistance guarantee. When a user's transaction is ignored by the sequencer, they can submit it as a force inclusion transaction to a special inbox contract on the L1. The rollup protocol is then obligated to process this transaction in a subsequent batch, ensuring the user's operation—such as a withdrawal—cannot be blocked indefinitely.

The process typically involves a mandatory delay or challenge period. After submitting the force transaction to L1, there is a waiting window (e.g., 24 hours) before the rollup is required to process it. This delay allows the honest sequencer a final opportunity to include the transaction normally, which is more gas-efficient. If they fail to do so, the protocol's verifiers or validators will enforce the transaction's inclusion when they post the next state root or batch to L1. This mechanism makes exit scams or malicious sequencer behavior significantly more difficult.

Force inclusion is a key component that differentiates optimistic rollups and zk-rollups from simple sidechains. While sidechains rely entirely on their validator set, rollups inherit Ethereum's security properties through force inclusion and fraud proofs or validity proofs. It acts as a user-operated safety hatch. Prominent implementations include Arbitrum's Inbox.sol contract and Optimism's deposit feed, where users can call functions like forceInclusion or submit to the SequencerFeeVault to compel transaction processing.

In blockchain networks, a delay refers to the mandatory waiting period between when a transaction is broadcast and when it is considered final and irreversible. This delay is not a bug but a fundamental security mechanism, most notably implemented as the confirmation time in Proof-of-Work chains like Bitcoin. During this period, the network achieves consensus, allowing nodes to validate the transaction and ensure it is part of the longest, valid chain. Reducing this delay improves user experience (UX) but can increase the risk of chain reorganizations and double-spending attacks.

The security provided by delay stems from the probabilistic nature of consensus. For example, a Bitcoin transaction with a single confirmation could theoretically be reversed if a longer, competing chain is found. Each subsequent block added on top makes a reorg exponentially less likely, increasing finality. Protocols aiming for faster UX, such as those using instant confirmation mechanisms, must introduce alternative security assumptions—like trusted validators, fraud proofs, or economic penalties—to compensate for the reduced natural delay. This creates a spectrum where designs prioritize either optimistic execution (fast, with dispute periods) or pessimistic finality (slow, with high cryptographic certainty).

Real-world implementations highlight this trade-off. Payment processors often accept zero-confirmation transactions for small amounts, prioritizing UX over the minimal security risk of a double-spend. Conversely, high-value settlements on base layers wait for numerous confirmations. Layer 2 solutions like rollups explicitly decouple this trade-off: they offer fast, cheap transactions for users (good UX) by processing them off-chain, while relying on the slower, more secure base layer (e.g., Ethereum) for ultimate data availability and dispute resolution, thereby inheriting its security after a challenge period delay.