Why a force inclusion transaction might not appear on-chain

29 October 2026

A force inclusion transaction is a Layer 1 (L1) mechanism that lets a user force an L2 sequencer to include a pending transaction in the next rollup batch. If it does not appear on-chain, the most likely reason is that the sequencer has not yet processed the force-inclusion request within the required time window, or the transaction itself was invalid at the L1 level. The procedure varies by rollup type, but in all cases, failure to appear means either the sequencer ignored the request (and the challenge period has not expired), the request was never properly submitted to the L1 contract, or the transaction could not be executed due to state or gas issues.

How force inclusion works in practice

Force inclusion is a safety mechanism built into optimistic and some ZK rollups. It allows a user to bypass a sequencer that is censoring or delaying their transaction. The user submits the transaction data directly to an L1 smart contract (often the rollup's inbox or canonical bridge), along with a fee. The sequencer is then obligated to include that transaction in the next batch it submits to L1. If the sequencer fails to do so within a defined period - typically 24 hours to 7 days depending on the rollup - the user can escalate by triggering a forced batch or challenge.

Common Reasons a Force Inclusion Transaction Fails to Appear On-Chain

1. The sequencer has not yet reached the deadline. Most rollups give the sequencer a grace period (e.g., 24 hours on Arbitrum, 7 days on Optimism) to include the forced transaction. If you check the L1 contract before this window closes, the transaction may simply be pending. It will appear once the sequencer processes it or the deadline passes.

2. The force transaction was invalid at the L1 level. A force inclusion request must include valid calldata (e.g., a properly formatted L2 transaction) and a sufficient fee paid to the L1 contract. If the calldata is malformed, the fee is too low, or the transaction would violate L2 state rules (like a nonce mismatch), the L1 contract will reject it immediately, and it never enters the queue. Check the L1 transaction receipt for a revert reason.

3. The sequencer included the transaction but it failed on L2. Force inclusion only guarantees the transaction is included in a batch - it does not guarantee successful execution. If the transaction reverts on L2 due to insufficient balance, a failed contract call, or gas limit issues, it will still appear as a finalized L2 transaction (visible on L2 block explorers) but with a "failed" status. If you are looking only at the L1 chain, you may miss this.

4. The L1 contract's force-inclusion queue is full or has a delay. Some rollups batch force inclusion requests into a queue. If the queue is long, the sequencer may process requests in order, and yours may still be pending even after the deadline. This is rare but possible if many users submit force requests simultaneously.

5. The L2 network is in a disputed or emergency state. On optimistic rollups, if a fraud proof challenge is active or the network is in a "paused" mode (e.g., via a security council), sequencers may halt processing. Force inclusion requests submitted during such periods may remain unprocessed until the dispute resolves. Check the rollup's status page or the L1 contract's pause flag.

6. You submitted to the wrong L1 contract. Force inclusion is handled by a specific contract (e.g., the "Inbox" on Arbitrum, the "CanonicalTransactionChain" on older Optimism versions). If you sent the transaction to the bridge contract or a different L1 address, it will not be recognized as a force request. Verify the contract address against the rollup's official documentation.

Step-by-Step Troubleshooting

If your force inclusion transaction has not appeared on-chain, follow these steps:

1. Wait the full challenge period. Check the rollup's documentation for the exact force-inclusion timeout (commonly 24 hours for Arbitrum, 7 days for Optimism). Do not assume failure before this period ends.

2. Verify the L1 transaction succeeded. Look up the L1 transaction hash on Etherscan. Confirm it did not revert. A successful L1 submission will emit an event (e.g., InboxMessageDelivered on Arbitrum). If no event was emitted, the request was not accepted.

3. Check the L2 block explorer for the transaction. Force inclusion transactions appear on L2 explorers (like Arbiscan or Optimistic Etherscan) once included. Search by your L2 account address or the transaction hash from the L1 event. If it is there but marked "failed," the force succeeded but the transaction did not execute.

4. Look for sequencer or network status updates. Check the rollup's official status page, Discord, or X account for announcements about delays, maintenance, or disputes. If the sequencer is down, no force transactions will be processed until it resumes.

5. Contact the rollup's support or community. If the deadline has passed and the transaction is neither on L1 nor L2, something went wrong. Provide the L1 transaction hash and the L2 account address to support. They can check the internal sequencer queue.

When force inclusion matters most

Force inclusion is a last-resort tool. It is most useful when a sequencer is actively censoring transactions (e.g., during a governance attack or a network outage). For routine delays - like high gas on L1 or a slow sequencer - simply waiting or resubmitting normally is more reliable. The mechanism exists to ensure censorship resistance, not to speed up normal transactions. If your transaction is not critical, avoid using force inclusion; it costs extra L1 gas and may take longer than a normal submission.

Back to layer 2s