A route around sequencer censorship
A rollup's fast user experience commonly relies on a sequencer ordering transactions. Forced inclusion provides a slower protocol-defined route when that sequencer refuses or fails to process a message. Arbitrum documents a delayed inbox and a mechanism for forcing eligible delayed messages into the chain after the relevant conditions are met. The objective is to limit indefinite exclusion, not to promise immediate execution at the same speed as the normal sequencer service.
2 sources for this section
Following the complete path
Suppose a sequencer repeatedly ignores a user's transaction. The user may need to submit an appropriate message on the parent chain, pay that chain's fee, wait through a specified delay, and invoke the inclusion mechanism. Each step depends on the rollup's actual contracts and configuration. A frontend button called an escape hatch may expose only part of this process, and a successful submission does not necessarily mean a withdrawal has already settled.
1 source for this section
Inclusion versus final settlement
Forced inclusion addresses access to ordering; it does not eliminate challenge periods, validity requirements, parent-chain congestion, or bridge accounting. A transaction that violates execution rules can still fail after inclusion. Protocol upgrades can also change operational parameters, so instructions should identify the chain, contract version, and current delay. In a network comparison, inspect whether the route is usable by ordinary users, which actors must cooperate, and whether the settlement layer itself remains available.
2 sources for this section
The source notesEvidence & further reading3 sources
- The sequencer and censorship resistance Arbitrum · Primary source · accessed 2026-09-21
- Inside Arbitrum Nitro Arbitrum · Primary source · accessed 2026-09-21
- OP Stack transaction flow Optimism · Primary source · accessed 2026-09-21