The Sequencer and Censorship Resistance

The Sequencer is a pivotal component of the Arbitrum stack, responsible for efficiently ordering and processing transactions. It plays a crucial role in providing users with fast transaction confirmations while maintaining the security and integrity of the blockchain.

Role of the Sequencer feed in the network

The Sequencer feed serves several vital functions within the Arbitrum ecosystem:

• State synchronization: Nodes use the feed to keep their state up to date with the latest network state, ensuring consistency across the decentralized platform.
• Application development: Developers can build applications that respond instantly to network events, enabling features such as live updates, instant notifications, and real-time analytics.
• Ecosystem transparency: The feed promotes transparency and trust within the community by providing visibility into transaction sequencing and network activity.

How it works

1. Transaction receipt

When a user submits a transaction via JSON-RPC, it is sent to the Sequencer.PublishTransaction, which begins the following process:

1. Forwarding check: If the node is not the active sequencer, the transaction is forwarded to the active one. Only the elected sequencer produces blocks.
2. Surplus check: If ExpectedSurplusHardThreshold is set, the L1 pricing surplus must exceed the threshold; otherwise, the transaction is rejected (anti-DoS tied to L1 fee economics).
3. Sender allowlist: If configured, only allowlisted addresses may submit (not active on Arbitrum One, Nova, Sepolia).
4. Type filtering: Arbitrum internal transaction types and EIP-4844 blob transactions are rejected.
5. Timeboost delay: If Timeboost is active and the current round has an express lane controller, non-express-lane transactions are delayed by ExpressLaneAdvantage (default: 200ms) before being queued. Express Lane transactions skip this delay.
6. Queue insertion: The transaction is wrapped in a txQueueItem (containing the transaction, result channel, context, Timeboost metadata) and pushed into the txQueue channel (bound by QueueSize, default 1024).

2. Block creation loop

The sequencer runs a tight loop (governed by MaxBlockSpeed, default 250ms minimal interval) that repeatedly calls createBlock:

1. Drain three queues in priority order:

• timeboostAuctionResolutionTxQueue highest priority (auction resolution transactions)
• txRetryQueue transactions retried after nonce/gas issues
• txQueue regular incoming transactions

After the first transaction, it continues draining for up to ReadFromTxQueueTimeout (default 10ms) to batch multiple transactions into a single block.

2. Pre-checks per queued item:

• Context expiration
• MaxTxDataSize (default 95KB)
• BaseFee check (reject GasFeeCap < block's BaseFee)

3. Nonce pre-checking:

• Uses an LRU nonceCache (address → nonce). Transactions with too-high nonces are placed in the nonceFailureCache. When a predecessor later succeeds, waiting transactions are revived and placed in the txRetryQueue.

4. Inactive check:

• If the sequencer discovers it's no longer active (a forwarder was set), all queued items are forwarded to the new active sequencer.

5. L1 block/timestamp validation:

• Ensures the L1 block number is known and the L1 timestamp is within MaxAcceptableTimestampDelta (default 1 hour).

6. Block production:

• Calls ExecutionEngine.SequenceTransactions.

3. Block execution

This is where transactions become a block:

1. Retrieves the current state from the blockchain.
2. Calls arbos.ProduceBlockAdvanced, which:

• Iterates through transactions via hooks.NextTxToSequence.
• Applies preTxFilter (nonce cache check, conditional options check, address filtering).
• Executes each transaction against ArbOS state.
• Applies postTxFilter (revert gas rejection, nonce cache update, nonce failure revival).
• Enforces per-block data size limits.

3. Constructs an L1IncomingMessage from successfully sequenced transactions.
4. Generates blockMetadata—a bitmask recording which transactions were timeboosted.
5. Calls TransactionStreamer.WriteMessageFromSequencer to persist.
6. Appends the block to the local blockchain.

4. Persistence & broadcast

1. Verifies this node is still the chosen sequencer.
2. If a SeqCoordinator is present, it atomically writes the message to Redis and extends the lockout (for high availability replication to standby nodes).
3. Writes the message (with block hash and metadata) to the local database.
4. Calls broadcastMessages to push the message to the WebSocket feed via the Broadcaster.

5. L1 posting

The BatchPoster runs independently, reading messages from the TransactionStreamer in sequence and posting them to L1. The mechanisms that run during this process are:

• Compression: Messages are Brotli-compressed with adaptive compression levels based on backlog size.
• Posting methods: Calldata (addSequencerL2BatchFromOrigin) or EIP-4844 blobs (addSequencerL2BatchFromBlobs).
• DA providers: Supports AnyTrust committees and blob storage as alternatives to direct L1 posting.
• L1 bounds tracking: Ensures batches have valid L1 timestamps.
• Empty batch management: Can post empty batches after MaxEmptyBatchDelay to advance the chain.

note

This is a high-level summary of how the BatchPoster operates within the overall Sequencing mechanism. To learn more about the BatchPoster, refer to the Batch poster deep dive.

6. Sequencer Coordinator (high-availability)

The SeqCoordinator implements Redis-based leader election:

• A CHOSENSEQ_KEY in Redis indicates which sequencer URL holds the lock.
• The active sequencer acquires a time-limited lockout (default 1 minute) and must periodically refresh it.
• Each sequencer that wants to become active sets a WantsLockout key; the highest-priority one is selected.
• The active sequencer writes signed messages to Redis (HMAC-signed). Standby nodes poll Redis and add messages to their local TransactionStreamer.
• Activation: Clears the forwarder, unpauses the sequencer, and syncs the Timeboost state from Redis.
• Deactivation: Sets up forwarding to the new active sequencer, pauses local block production.
• Cleanup: The active sequencer periodically deletes finalized messages from Redis.

7. Broadcast feed system

The feed distributes sequenced messages to all non-sequencer nodes in real-time:

• The Broadcaster runs a WebSocket server, signing each message with a data signer and maintaining a backlog for clients connecting mid-stream.
• On startup or lock acquisition, PopulateFeedBacklog fills the backlog from the database.
• Receiving nodes call TransactionStreamer.AddBroadcastMessages, which validates messages against the local database—feed messages can never reorganize confirmed L1 messages.

note

Batches posted to the parent chain are the second method of the Broadcast feed system. To learn more, refer to the Batch poster deep dive.

8. Delayed sequencer

Handles messages originating on L1 (deposits, retryable tickets):

• Monitors the DelayedBridge for finalized delayed messages.
• Sequences them into the L2 chain via ExecutionEngine.SequenceDelayedMessage.
• Supports address filtering—if a delayed message touches a filtered address, the sequencer halts until the transaction hash is added to an onchain filter.
• Only runs on the active sequencer node.

9. Timeboost/Express lane

Timeboost is a transaction priority auction mechanism. A deep dive can be found on the Timeboost page, but here is a short summary of how it works:

• Time is divided into fixed-duration rounds (minimum 10 seconds).
• Before each round, an auction determines the express lane controller—the address whose transactions get priority.
• The express lane controller's transactions skip the 200ms delay that normal transactions experience when the express lane is active.

Flow for Express Lane transactions

1. Controller submits via Sequencer.PublishExpressLaneTransaction.
2. ExpressLaneService.ValidateExpressLaneTx checks sender == controller, correct round, valid chain ID.
3. ExpressLaneService.SequenceExpressLaneSubmission inserts into a per-round ordering queue (express lane submissions have sequence numbers and are delivered in order).
4. Messages drain in sequence order → PublishTimeboostedTransaction → enters txQueue with no delay.
5. The isTimeboosted flag is preserved through block production into blockMetadata.

Flow for normal transactions when the Express Lane is active

1. Transaction arrives at PublishTransaction.
2. Since CurrentRoundHasController returns true, time.Sleep(ExpressLaneAdvantage) delays by 200ms.
3. Only after the delay does the transaction enter the queue.

Auction system

• The AuctioneerServer runs the auction process using EIP-712-signed bids.
• Auctions resolve during the AuctionClosing window.
• Resolution transactions get their own highest-priority queue in the sequencer.

Soft finality and trust model

“Soft finality” refers to the preliminary confirmation of transactions based on the Sequencer’s real-time feed. Key aspects include:

• Dependence on Sequencer integrity: The feed's accuracy and reliability depend on the Sequencer operating honestly and without significant downtime.
• Immediate user feedback: Users can act on transaction confirmations swiftly, improving the user experience.
• Eventual consistency with the parent chain: While the real-time feed provides quick updates, ultimate security and finality are established once transactions are posted to and finalized on the parent chain.

Trust considerations

Understanding this trust model is essential. While we expect the Sequencer to behave correctly, users and developers should know that soft finality depends on this assumption. In scenarios where absolute certainty is required, parties may wait for transactions to achieve finality on the parent chain.

• Soft finality trust model:
  • Reliance on the Sequencer: Users must trust that the Sequencer operates honestly, sequences transactions correctly, and remains available.
  • Risk of misbehavior: If the Sequencer acts maliciously, it could reorder or censor certain transactions before they achieve hard finality.
• Hard finality trust model:
  • Reliance on the parent chain: Security is based on the consensus and integrity of the parent chain.
  • Reduced trust in Sequencer: Even if the Sequencer misbehaves, transactions included in posted batches are secured once finalized on the parent chain.

Application implications

Developers and users should consider the appropriate level of finality based on their specific use cases:

When to rely on soft finality

• Low-risk transactions: For transactions where the potential impact of reordering or delays is minimal.
• User experience priority: Applications where responsiveness and immediacy enhance user engagement, such as gaming or social platforms.
• Frequent transactions: Scenarios involving a high volume of small transactions where waiting for hard finality is impractical.

When to require hard finality

• High-value transactions: Financial transfers, large trades, or any transaction where security is critical.
• Regulatory compliance: Situations requiring strict adherence to security standards and auditable records.
• Centralized exchanges (CeXs): For deposit and withdrawal operations where certainty of transaction finality is mandatory.

Considerations and limitations

While the Sequencer feed offers significant advantages, consider the following:

• Reliance on Sequencer availability: The effectiveness of the real-time feed depends on the Sequencer’s uptime and responsiveness. Network issues or Sequencer downtime can delay transaction visibility.
• Provisional nature of soft finality: Until transactions reach finality on the parent chain, there is a small risk that the provisional ordering provided by the feed could change in exceptional circumstances.
• Security implications: For high-stakes transactions where security is paramount (e.g., deposits and withdrawals on centralized exchanges), users may prefer to wait for confirmation on the parent chain, even with the longer latency.

Developers and users should design their applications and interactions with these factors in mind, choosing the appropriate balance between speed and certainty based on their requirements.

Censorship Timeout

As mentioned in the original Arbitrum BoLD Forum Post, the initial release of Arbitrum BoLD will come with a feature called ”Censorship Timeout” (originally called “Delay Buffer”). For Arbitrum One and Nova, it is proposed that this feature be enabled by default alongside BoLD’s upgrade.

Censorship Timeout aims to limit the negative effects of:

• Prolonged sequencer censorship, and/or,
• Unexpected sequencer outages.

How the Censorship Timeout feature works

To explain how this feature improves the security of chains settling to Arbitrum One and Nova, 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 SequencerInbox's forceInclusion method described here). In this scenario, 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 (i.e., 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:

• delay buffer = 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 utilize 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. The Timeboost ordering policy is designed to be compatible with decentralized sequencing.