Force Inclusion

The behavior of force inclusion is governed by key parameters set in each rollup's L1 contracts:

• Delay Period: The mandatory waiting time (e.g., 24h, 2min) before a force-inclusion request is valid.
• Gas Cost & Pricing: Force-included transactions often pay a premium or use a distinct pricing model.
• Submission Window: The timeframe in which a request must be executed after becoming valid.
• Ordering Rule: How force-included transactions are ordered relative to Sequencer batches (usually by L1 block number).

Force inclusion is not just a user escape hatch; it's a core security mechanism. It:

• Disincentivizes Censorship: Makes it economically irrational for a Sequencer to withhold transactions.
• Guarantees L1 Finality: Ensures any transaction can eventually be recorded on the base layer, the ultimate source of truth.
• Enables Trustless Withdrawals: Critical for allowing users to exit the rollup even if the Sequencer is malicious.
• Defines Liveness Assumption: The system's liveness relies on at least one honest actor being able to use the L1 force inclusion function.

Force inclusion is most commonly used to protect against Maximal Extractable Value (MEV) attacks, such as front-running or sandwich attacks. By submitting a transaction directly to a sequencer with a future timestamp, users can guarantee its execution in a specific block, making it impossible for opportunistic validators to reorder or censor it for profit.

• Key Mechanism: The transaction is held by the sequencer and included at the specified block height.
• Target Users: Traders executing large swaps, users closing leveraged positions, or anyone requiring guaranteed, uncensored transaction ordering.

Implementing force inclusion requires specific protocol support and adherence to strict rules. On Optimistic Rollups like Arbitrum, it's implemented via the Delayed Inbox. Key constraints include:

• Queue Position: Transactions are placed in a first-in-first-out (FIFO) queue.
• Time Delay: A mandatory delay period (e.g., 24 hours on Arbitrum One) exists before inclusion to allow for fraud proofs.
• Gas Limits: The transaction must conform to the block gas limit of the destination layer.
• Nonce Management: The account nonce must be valid at the time of forced inclusion, not submission.

The most significant practical limitation is the mandatory delay period. This design is a security feature of Optimistic Rollups, allowing time for fraud proofs to be submitted. However, it renders classic force inclusion useless for real-time protection.

• Consequence: A transaction submitted for force inclusion today is only executable tomorrow, which does not protect against immediate MEV.
• Developer Consideration: This makes force inclusion unsuitable for most DeFi applications requiring instant execution. Its utility is currently for very specific, pre-planned operations where the exact future block is known.

Zero-Knowledge (ZK) Rollups present a paradigm shift. Because they use validity proofs instead of fraud proofs, transactions can be verified instantly. This enables the potential for instant force inclusion with no delay.

• How it works: A user could submit a transaction with a proof directly to a prover or validator, demanding inclusion in the next proven state update.
• Impact: This could finally realize the original goal of real-time, MEV-resistant transaction guarantees, making it a powerful tool for developers building high-stakes financial applications on L2s.

For users needing to execute a force inclusion transaction, the workflow is precise:

1. Construct Transaction: Build your transaction with all necessary parameters (to, data, value).
2. Set Future Block Number: Calculate and set the blockNumber field for a future L2 block (current block + delay period).
3. Submit to Delayed Inbox: Send the transaction to the rollup's specific force inclusion interface (e.g., Arbitrum's DelayedInbox contract).
4. Monitor & Execute: After the delay, the sequencer will include it. You do not need to resubmit.

Best Practice: Always verify the exact delay period and inbox address for your specific rollup network.

It's important to distinguish force inclusion from other anti-MEV tools:

• Flashbots Protect / RPC Private Transactions: These services submit transactions directly to block builders on Ethereum, bypassing the public mempool. They offer real-time protection but rely on builder cooperation and are not a protocol-level guarantee.
• Force Inclusion: A protocol-level guarantee enforced by rollup code. It is not real-time on Optimistic Rollups but is cryptographically assured once the delay passes.

Developer Choice: Use private RPCs for immediate, best-effort protection. Use force inclusion for guaranteed, non-real-time execution where censorship resistance is paramount.

In blockchain networks, transaction priority determines the order in which pending transactions are included in a block. It is typically influenced by:

• Fee rate: Transactions with higher fees per byte (sat/vB in Bitcoin) are prioritized.
• Fee bumping: Techniques like Child Pays For Parent (CPFP) or Replace-By-Fee (RBF) allow users to increase a transaction's priority after broadcast.
• Time in mempool: Older unconfirmed transactions may receive a slight priority boost in some implementations. Force inclusion overrides standard priority rules to guarantee execution.

The mempool is a node's temporary storage for valid, unconfirmed transactions broadcast to the network. It is the staging area where transactions await block inclusion. Key characteristics include:

• Dynamic size: The mempool grows and shrinks based on network demand and block space.
• Eviction policies: Nodes may drop low-fee transactions if the mempool reaches capacity.
• Source of data: Block builders (miners, validators) select transactions from their local mempool to construct new blocks. Force inclusion mechanisms interact directly with the mempool to ensure a transaction is not evicted and is presented for block building.

Force inclusion is the primary technical solution for sequencer censorship resistance in optimistic and zero-knowledge rollups. It addresses the risk where a centralized sequencer might:

• Exclude transactions from specific users.
• Front-run or reorder transactions for profit.
• Go offline, halting the chain. By allowing users to submit transactions directly to the L1 contract via a force inclusion path, the system ensures liveness and permissionlessness. This is a foundational guarantee for decentralized rollups.

Data Availability refers to the guarantee that the data necessary to validate a blockchain's state is published and accessible to all network participants. It is crucial for:

• Rollup security: Validators need transaction data to verify state transitions and detect fraud.
• Force inclusion execution: When a user forces a transaction, they must make the relevant data (e.g., in a blob) available on-chain so the L1 can process it.
• Data availability committees (DACs) and data availability layers are alternative solutions to on-chain DA that may have different force inclusion implications.

Force inclusion is a specific, security-critical type of L1-to-L2 messaging. Standard messaging bridges allow arbitrary communication, but force inclusion is a privileged message that the L2 must process. The typical flow is:

1. User submits a transaction to a designated inbox or portal contract on L1.
2. The L2 sequencer is expected to monitor this inbox and include the message.
3. If not included within a challenge period or timeout, the user can invoke a force inclusion function, proving the message's existence on L1 and compelling the L2 to process it, often with a gas refund.