Skip to main content

The batch poster

Batch posting is a fundamental process for the Sequencer's operation in Arbitrum. It involves collecting multiple child chain transactions, organizing them into batches, compressing the data to reduce size, and sending these batches to the Sequencer Inbox contract on the parent chain. This mechanism securely records transactions on the parent chain while optimizing for costs and performance.

How it works​

Batch poster path. The batch poster pulls sequenced messages from the `TransactionStreamer`, builds a block, routes the data to a data availability provider, encodes the parent chain transaction as calldata or blobs with a delay proof, verifies the batch, posts the transaction, and lands it in the parent chain SequencerInbox contract. Building a block expands into four substeps: compute the parent chain block bounds, fill batch segments and compress them with adaptive Brotli, decide whether to post now or wait, and CloseAndGetBytes to recompress at a higher level, which returns to building the block. Posting expands into three substeps: fee calculation, nonce management, and sign and send, which returns to posting the transaction.

1. Messages arrive (upstream handoff)​

A transaction’s journey into the batch poster begins after it’s already been sequenced. The poster pulls ordered child chain messages from the TransactionStreamer—that’s a handoff into the batch poster; sequencing, execution, and soft finality all happened before this point and live outside of the batch poster.

2. The poster decides where it stands​

The main loop (MaybePostSequencerBatch) first does a safety check (refuse to post if a prior batch reverted), then asks “what batch number and the parent chain nonce am I on?” and establishes the parent chain time/block window the batch will use. That window comes from reading the parent chain SequencerInbox contract’s MaxTimeVariation—a read-only handoff out to the parent chain.

3. Messages become a compressed batch​

The poster receives messages in order, turning each into typed segments (the transaction itself, plus small bookkeeping notes for delayed-message markers and time/block advances) and streaming them through Brotli. It watches size and segment-count caps, and adapts compression effort to how far behind it is—more compression when calm, less when backlogged. When it decides the batch is ready (full enough, old enough, or a delayed message is about to expire), it seals and recompresses it. This is the core work done inside the batch poster.

4. The data is routed to storage (DA handoff)​

The sealed bytes are handed to a data availability (DA) provider—an offchain AnyTrust/DAS committee or a custom backend—via the small Writer.Store interface, with a fallback to putting data directly on Ethereum (calldata or blobs). What comes back is either a certificate (offchain) or the raw data (EthDA). The committee aggregation, BLS signing, and blob KZG cryptography all happen behind that interface—handoffs that the batch poster isn’t involved in.

5. The batch is wrapped for the parent chain and self-checked​

The poster builds calldata for the right SequencerInbox method (calldata vs. blobs, with or without a delay proof) and—as a correctness gate—replays the whole batch through the InboxMultiplexer (the same read/decode machinery used to consume batches) to confirm it decodes back to the exact original messages before anything is sent.

6. The transaction is shipped to the parent chain (DataPoster handoff)​

The batch poster hands the calldata, blobs, and gas estimate to the DataPoster—the “shipping department.” From here, nonce selection, fee bidding, signing, queue persistence, and replace-by-fee-if-stuck are the DataPoster’s job, deliberately kept separate so the batch poster never has to deal with Ethereum gas mechanics. The DataPoster ultimately submits the transaction to the parent chain SequencerInbox contract.

7. Finality and feedback​

Once the parent chain transaction confirms, the transactions cross from the Sequencer’s soft finality into hard finality anchored on the parent chain. The poster updates its backlog estimate (feeding back into compression effort and fee urgency), and a background revert watcher monitors the parent chain—if a posted batch ever fails onchain, it halts all posting for operator intervention.