Sequencer Centralization and Forced Inclusion

Sequencer centralization means one operator controls ordinary transaction ordering on a layer 2 rollup. That operator can give users fast provisional confirmations, but its outage or refusal can delay a trade or a collateral withdrawal. Forced inclusion is a protocol route that lets users get a queued message into the rollup's canonical transaction order through the base chain without the sequencer's cooperation. Arbitrum's sequencer documentation

Maya signs a valid Arbitrum One transaction to withdraw ETH to Ethereum. She sends it through the ordinary route, but the sequencer ignores it. She wraps the signed transaction as a supported L2 message and submits it with sendL2Message to Arbitrum's Delayed Inbox contract on Ethereum. It is recorded at Ethereum block N. The wait starts at that block. If the sequencer picks up the message, the normal batch path can advance the queue without a force call. Arbitrum's forced-transactions guide

Suppose the effective window for Maya's message is the full 7,200 Ethereum blocks. A call in block N + 7,200 is too early. N + 7,201 is the first eligible block. If the message is still pending, Maya or anyone else can send a forceInclusion transaction with the matching message details to the Sequencer Inbox contract on Ethereum. When Ethereum includes a successful call, the queue advances through Maya's message and includes every earlier message still pending. Eligibility alone leaves the message waiting. Nitro's forceInclusion implementation

Arbitrum One's BoLD censorship timeout uses the smaller of the configured 7,200-block limit and the effective delay buffer. Past delays can drain the buffer as the contract updates it, down to a 150-block floor. The full window is roughly 24 hours at 12 seconds per block, and the contract applies the cutoff using Ethereum block height. A batch or another force call can change the cutoff returned by forceInclusionDeadline(N). The route depends on Ethereum accepting the transactions. An Inbox pause or allowlist can also prevent a new submission. Arbitrum One's window settings and Inbox conditions

Arbitrum nodes read the message in its canonical order and apply the L2 execution rules. The signed transaction can be dropped if Maya's account nonce (its transaction counter) has changed or if the base fee exceeds her signed fee cap. A transaction that runs and reverts has a failed L2 receipt. The Ethereum receipts track submission and inclusion on the force route. The Arbitrum receipt tracks execution. Arbitrum's signed transaction outcomes

Finality of the Ethereum block recording inclusion secures the message's place in the rollup's order. If Maya's L2 transaction succeeds, it creates a withdrawal message. Ethereum releases the funds through the canonical bridge once the rollup's claim about the resulting state, called an assertion, is confirmed under BoLD's dispute rules and someone executes the claim on Ethereum with a proof that the withdrawal is in the confirmed assertion. That payout is the event Maya can reconcile against spendable Ethereum collateral. Arbitrum's finality guide · Arbitrum's Outbox and withdrawal process