Antler by Autoflux
HomeArbitrum NitroSequencing & Consensus
Report an error

Sequencing & Consensus

How the sequencer orders transactions, the delayed vs. sequencer inbox split, and why L1 remains the ordering authority.

Path: consensus-or-sequencing

Third-party documentation. This is independently authored analysis of the public Arbitrum Nitro codebase — not the official docs, and not reviewed or endorsed by the Arbitrum Nitro team.

Sequencing & Consensus

Nitro's ordering model has two layers, mirroring the OP Stack's pattern: a fast sequencer for day-to-day ordering, and L1 as the authoritative ordering layer that can never be subverted.

The sequencer

A single sequencer (owned by the chain operator) receives user transactions via its RPC, assigns each a sequence number, executes them in order, and publishes the resulting blocks to a high-speed feed for immediate confirmation. This gives users sub-second "I'm in" feedback while the slow, authoritative settlement happens on L1.

Two inboxes on L1

The trick that keeps the sequencer honest is that L1 has two message paths, and the sequencer controls only one:

  • Sequencer inbox — the batch path. The sequencer (and only the sequencer) can call addSequencerL2BatchFromOrigin to publish a batch of ordered messages. This is the fast, cheap path.
  • Delayed inbox — the force-inclusion path. Any L1 caller can add a message to the delayed inbox, which becomes readable by the L2 only after a delay (in Bridge.sol). If the sequencer censors someone, they can bypass it entirely by going through the delayed inbox.

The sequencer's batch header must reference afterDelayedMessagesRead — how many delayed-inbox messages have been incorporated. If the sequencer ignores a delayed message, its next batch is invalid until it accounts for it. This is the mechanism that guarantees liveness even against a malicious sequencer.

Batch structure

Each SequencerInbox batch is compressed (using a custom compression scheme tuned for L2 tx data) and contains a sequence of L2 transactions. Frames within a batch let large batches be split across L1 blocks; a Merkle accumulator (InboxState.acc) commits to the full message history so any subset of batches can be verified incrementally.

Consensus and finality

  • Sequencer fast confirmation — reversible in principle, but the feed makes it feel instant.
  • L1-anchored confirmation — once a batch is on L1 and the L2 replaying it succeeds, the ordering is canonical. This is what a validator trusts.
  • Assertion-based settlement — stakers periodically post assertions (state commitments) to the RollupCore contracts. An assertion becomes final after the challenge period (≈ 8 days on Arbitrum One) or when the challenge game confirms it.

Edge cases

  • A sequencer that publishes a batch referencing the wrong afterDelayedMessagesRead produces an invalid batch; validators skip it and the chain continues from the last valid one.
  • The delay window for delayed inbox messages exists so a malicious batch can't race a forced message — builders on the L1 side must respect delayBlocks when reasoning about censorship resistance.
  • Sequencer batches are batched across many L2 blocks; a single L1 batch can contain hundreds of L2 blocks, so "latest block" on L2 advances in spurts relative to L1.

Interface

Interface
solidity
// SequencerInbox — where ordered batches land on L1.
contract SequencerInbox {
    struct InboxState {
        uint256 count;        // total messages
        bytes32 acc;          // Merkle accumulator root
    }
 
    // Adds a batch of sequencer-ordered messages. Emits SequencerBatchData.
    function addSequencerL2BatchFromOrigin(
        uint256 sequenceNumber,
        bytes calldata data,
        uint256 afterDelayedMessagesRead,
        IGasRefunder refunder
    ) external;
 
    // Messages that bypass the sequencer (L1-to-L2 forced inclusion).
    function addMessageToDelayedInbox(
        uint256 blockNumber,
        address sender,
        uint256 messageNumber,
        bytes calldata data
    ) external;
}
 
STATUSinterface