Skip to main content

Batch Poster

Batch posting configurations allow the sequencer to group, compress, and post transaction batches from the Arbitrum chain (L3) to its parent chain (typically an L2 such as Arbitrum One or Nova). Key parameters include the maximum delay before posting a batch and the maximum size of a batch to be posted, both of which control the frequency and timeliness of postings. These help prevent transaction reordering by ensuring that the sequencer commits batches in the order transactions are received, posting them atomically to the parent chain's inbox contract. This batch posting creates an immutable record on L1 (via the L2), reducing the risk of malicious reordering. For chain reorganizations, timely batch posting minimizes the window for L1 reorgs to affect unposted data, as posted batches become part of the canonical chain history.

Assertion posting configurations enable validators to periodically create and post assertions (state roots) of the Arbitrum chain's execution to the parent chain. Parameters control the interval between assertions and staking requirements. These prevent reordering and reorgs by allowing any honest validator to challenge incorrect assertions during a dispute window (typically seven days on Arbitrum chains). Regular assertions ensure state commitments are frequent enough to detect discrepancies early, triggering onchain resolution via bisection games, which enforce the correct chain state and deter reorganizations.

Batch posting minimum frequency​

Maximum wait time to post a batch​

The batch posting minimum frequency is primarily controlled by the --node.batch-poster.max-delay parameter in the Nitro node's configuration (set via the JSON config file or command-line flags when deploying an Arbitrum chain). This parameter defines the maximum time the batch poster will wait after receiving a transaction before posting a batch that includes it. The default value is one hour (3600 seconds).

  • Configuration options: Set this in the node.batch-poster section of the config, e.g., "max-delay": "30m" for a 30-minute maximum wait. Lower values increase posting frequency but may result in smaller, less efficient batches during periods of low activity, thereby increasing gas costs on the parent chain. If no transactions are received, no batches will post regardless of this setting.
  • Prevention of issues: A shorter max delay reduces the opportunity for transaction reordering by minimizing the time transactions sit uncommitted in the sequencer's mempool. It also limits exposure to chain reorgs, as batches post sooner, anchoring them to the parent chain before potential L1 fluctuations can invalidate sequencing. However, extremely low settings (e.g., seconds) could spam the parent chain with tiny batches, resulting in increased costs without any benefits.
  • Recommended settings: For high-throughput chains, set to 5-15 minutes to balance latency and efficiency. For low-activity chains, stick to the default one hour to avoid unnecessary postings.

Maximum batch size to post a batch​

The maximum size of a batch controls when the batch poster posts based on data volume. If the total queued but unposted transaction size reaches this number, the batch poster will post the batch. It is controlled by the --node.batch-poster.max-size parameter in the Nitro node's configuration (set via the JSON config file or command-line flags when deploying an Arbitrum chain).

  • Configuration options: Set this in the node.batch-poster section of the config, e.g., "max-size": "100000" for 100,000 bytes. Lower values increase posting frequency but may result in smaller, less efficient batches during periods of low activity, thereby increasing gas costs on the parent chain. If no transactions are received, no batches will post regardless of this setting.
  • Prevention of issues: A smaller max size reduces the opportunity for transaction reordering by minimizing the time transactions sit uncommitted in the sequencer's mempool. It also limits exposure to chain reorgs, as batches post sooner, anchoring them to the parent chain before potential L1 fluctuations can invalidate sequencing. However, extremely low settings (e.g., a few hundred bytes) could spam the parent chain with tiny batches, resulting in increased costs without any benefits.
  • Recommended settings: For high-throughput chains, consider a lower max size to ensure frequent posting. For low-activity chains, the default value is generally sufficient to avoid unnecessary postings.