The Sequencer and censorship resistance

The Sequencer’s job is to receive, admit, and order transactions and then publish and post the resulting blocks. The moment ordered transactions are handed to the execution engine, responsibility shifts to the State Transition Function (STF) and ArbOS, where transactions are executed against the chain state, gas is metered, and the new state root is computed. Throughout this section, we flag those handoff points and point to the relevant pages rather than duplicating them.

A transaction’s path through the Sequencer

1. Receipt and admission

A user transaction arrives over JSON-RPC. Before it is allowed anywhere near a block, it passes a series of admission checks: if this node is not the active Sequencer, the transaction is forwarded to the active one; optional sender allowlists and parent chain fee-surplus thresholds can reject it; and internal Arbitrum transaction types and blob transactions are filtered out. Admitted transactions land in an unordered waiting list, the first stage of the Sequencer’s two-stage mempool. What happens next depends on the chain’s transaction ordering policy. Under first-come, first-serve (FCFS), arrival time sets the order. Under Priority Gas Auctions (PGA), each ordering round moves the whole waiting list into a priority queue keyed on the priority fee each transaction pays.

2. Block creation loop

The Sequencer runs a tight loop that drains its queues and groups transactions into a block. It services a retry queue ahead of the regular queue. Under PGA, the loop runs in fixed ordering rounds: each round moves the waiting list into the priority queue, then transfers that queue into the block under construction, highest priority fee first. PGA ordering covers the rounds in detail. Lightweight pre-checks happen here: per-transaction data-size limits, a base-fee check, and a nonce cache that parks too-high nonces and revives them once their predecessor succeeds. The loop also confirms that the parent-chain block number and timestamp are within an acceptable range before producing a block.

A block closes when it reaches the first of these limits:

• A gas target of 32 Mgas. The hard limit is 64 Mgas, and a single transaction can use at most 32 Mgas.
• A calldata limit of 95,000 bytes.
• The end of its last round.

If a block fills before its last round, the Sequencer finalizes it right away and starts the next block rather than idling for the rest of the window. Under load, the chain then produces blocks faster than its nominal block time, up to a cap of 8 blocks per second. That cap keeps the spacing between rounds consistent, which the anti-starvation boost depends on.

3. Handoff to ArbOS and the STF

Once the Sequencer has a finalized ordering, it calls the ExecutionEngine, which in turn invokes ArbOS to produce the block.

4. Persistence and broadcast

The produced block comes back to the Sequencer as a sequenced message. The TransactionStreamer persists it to the local database and, if a coordinator is configured, replicates it to Redis for high availability. It then hands the message to the Broadcaster, which pushes it to subscribers over the real-time feed. This is the moment users get soft finality: a sub-second provisional confirmation that depends on the Sequencer behaving honestly.

On Arbitrum One, a second stream runs alongside the standard feed. The Fast Feed is a paid, authenticated WebSocket stream that publishes each transaction as soon as the Sequencer orders and executes it, inside the PGA round and before the block closes. The Sequencer publishes to the Fast Feed before it stores the transaction, so the block number each message carries is tentative. Soft finality still comes from the standard feed.

5. Posting to the parent chain

Independent of the loop above, the batch poster reads sequenced messages from the TransactionStreamer, Brotli-compresses them with adaptive compression levels, and posts them to the Sequencer Inbox using either calldata or EIP-4844 blobs. To configure this component, see Run a batch poster. Once those batches are finalized on the parent chain, the transactions reach hard finality.

High availability: the Sequencer coordinator

In production, several Sequencer nodes run under a single logical Sequencer, with the SeqCoordinator electing a single active leader via Redis. A chosen-sequencer key records the current leader, which holds a short, time-limited lockout (roughly one minute by default) that it must continually refresh. The active node writes signed messages to Redis; standby nodes follow along so that, if the leader fails or steps down, another can take over with minimal disruption. Activation clears any forwarders and resumes block production; deactivation sets up forwarding to the new leader and pauses local production.

Delayed messages from the parent chain

Not every transaction originates with a direct RPC submission. Deposits and retryable tickets enter through the parent chain’s delayed inbox. The DelayedSequencer watches for these messages to finalize on the parent chain, then sequences them into the child chain so they appear in the ordering and on the feed alongside ordinary transactions. As with execution generally, the act of applying a delayed message is ArbOS/STF territory; the DelayedSequencer’s role is to decide when it enters the order.

PGA ordering

PGA orders transactions by the priority fee each one pays, rather than by the moment each one arrives. The Sequencer evaluates that order in short rounds that run several times per block. Three parts work together.

The two-stage mempool

Arriving transactions land in an unordered waiting list. Intake runs continuously, independent of any ordering work. At the start of each round, the whole list moves into a priority queue keyed on the priority fee, which EIP-1559 computes as min(max_priority_fee_per_gas, max_fee_per_gas - base_fee_per_gas).

Ties break on the arrival timestamp the Sequencer recorded when the transaction first reached it, not on when it entered the queue. Because the priority fee depends on the base fee, the Sequencer re-keys the queue against the new base fee at the start of every block.

The mempool stays private. PGA does not give anyone the right to see or reorder another user’s transactions, so Arbitrum’s protections against harmful MEV are unchanged.

Ordering rounds

A new round starts every B/K, where B is the block time and K is the number of rounds per block. On Arbitrum One, B is 250ms and K is 2, so each round lasts 125ms. Each round runs two phases:

• Intake covers the full round window and absorbs new arrivals into the waiting list. It overlaps with the previous round’s execute phase.
• Execute starts as soon as intake closes. The waiting list moves into the priority queue, and the Sequencer transfers the queue into the block, highest priority first.

The transfer ends when the queue empties, the block fills, or the round runs out of time. Anything still queued waits for the next round.

The anti-starvation boost

At the end of every round in which the priority queue holds transactions, each transaction still waiting gains a priority boost of p / (2K). Here p is the priority of the last transaction the previous round included, or zero if that round included none.

Two properties matter:

• The boost moves a transaction’s position in the queue and nothing else. It never changes the fee the transaction pays.
• The boost compounds across rounds. A transaction that pays no priority fee climbs until it outranks the marginal paying transaction, which bounds its wait to a small number of blocks.

Censorship Timeout

As mentioned in the original Arbitrum BoLD forum post, the initial release of Arbitrum BoLD includes a feature called Censorship Timeout (formerly known as Delay Buffer).

Censorship Timeout aims to limit the negative effects of:

• Prolonged Sequencer censorship, or
• Unexpected Sequencer outages

How the Censorship Timeout works

To explain how this feature improves the security of chains settling to Arbitrum One, consider a scenario where an L3’s parent chain Sequencer (the L2 Sequencer) is censoring or offline. In such a case, every assertion and/or sub-challenge move would need to wait 24 hours before bypassing the L2 Sequencer (using the Sequencer Inbox’s forceInclusion method). In this scenario, a challenge resolution would be delayed by a time t where t = (24 hours) * number of moves for a challenge. To illustrate with sample numbers, if a challenge takes 50 sequential moves to resolve, then the delay would be 50 days.

The Censorship Timeout feature mitigates this by lowering the force inclusion threshold when unexpected delays in message inclusion occur due to one (or all) of the above-mentioned cases of censorship or a sequencer outage, enabling entities to make moves without the 24-hour delay-per-move.

The force inclusion window is the lesser of delayBuffer and delayBlocks, where delayBlocks is a constant currently set to 24 hours, and delayBuffer ranges from 30 minutes to 48 hours.

The delayBuffer value “grows and shrinks” depending on how long the Sequencer is offline or censoring transactions. As a way to measure this behavior, the delayBuffer is decremented by the difference between a delayed message’s delay beyond the threshold and how long it has been delayed (that is, when some delayed messages are delayed by more than the threshold, the difference between the messages’ delay and the threshold is removed from the buffer). For example, if the threshold is 30 minutes and a message was delayed by 32 minutes, the delayBuffer is decremented by 2 minutes. The threshold is set to 30 minutes on Arbitrum One and 1 hour on Arbitrum Nova.

The delayBuffer replenishes at a linear rate when the Sequencer is operating correctly at a nominal rate of one minute for every 20 minutes in which no messages are delayed beyond the threshold.

Below are the initial, proposed parameter values for the Censorship Timeout feature for Arbitrum One and Nova:

• delayBuffer = 14400 parent chain (Ethereum) blocks (2 days)
• threshold = 150 L1 Ethereum blocks (30 minutes) for Arbitrum One and 300 parent chain (Ethereum) blocks (one hour) for Arbitrum Nova
• replenish rate = 5% (meaning one day is replenished every 20 days or roughly a 95% uptime)

We believe that the Censorship Timeout feature provides stronger guarantees of censorship resistance for Arbitrum chains—especially those that settle to Arbitrum One or Arbitrum Nova. As always, chain owners can decide whether to use this feature for their chain and can also change the default parameters as they see fit for their use case.

Decentralized fair sequencing

Arbitrum’s long-term vision includes transitioning from a centralized Sequencer to a decentralized, fair sequencing model. In this framework, a committee of servers (or validators) collectively determines transaction ordering, ensuring fairness, reducing the influence of any single party, and making it more resistant to manipulation. By requiring a supermajority, this approach distributes sequencing power among multiple honest participants, mitigates the risks of front-running or censorship, and aligns with broader blockchain principles of enhanced security, transparency, and decentralization. A transaction ordering policy sits above this layer. Decentralized sequencing changes who enforces the ordering rules, not the rules themselves.