Skip to main content

Configure Batch Poster and Assertion Control

The page for an Arbitrum Orbit chain should describe the available configurations for batch posting (handled by the batch poster) and assertion posting (handled by validators) as follows:

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 Orbit 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​

Maximum size of a batch, if total queued but not posted transaction size archive this number, then batch poster will post this 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 Orbit chain).

  • Configuration Options: Set this in the node.batch-poster section of the config, e.g., "max-size": "100000" for 100000 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., 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.

Validator action minimum frequency:​

Validator node creation frequency: Interval between validator assertions posting​

The validator assertion posting frequency is controlled by the --node.staker.make-assertion-interval (legacy) or --node.bold.assertion-posting-interval (bold) parameter in the Nitro node's configuration. This parameter sets the minimum time to wait since the last assertion before posting a new one (if the validator configuration is to make new assertions via the MakeNodes strategy). The default value is one hour (3600 seconds) for legacy and fifteen minutes (900 seconds) for bold. This interval must always exceed the rollup contract's minimumAssertionPeriod, which defaults to 75 L1 blocks (approximately 15 minutes at 12-second block times).

  • Configuration Options for legacy: Configure this in the node.staker section, e.g., "make-assertion-interval": "45m" for a 45-minute interval.
  • Configuration Options for bold: Configure this in the node.bold section, e.g., "assertion-posting-interval": "45m" for a 45-minute interval.
  • Prevention of Issues: Frequent assertions ensure the chain's state is regularly committed and verifiable on the parent chain, preventing reordering by allowing disputes over any manipulated transaction order. For reorganizations, assertions serve as checkpoints; if a reorganization affects prior batches, validators can challenge and resolve the state to the correct one, thereby maintaining integrity. Infrequent assertions could widen the dispute window vulnerability, but the default balances this with efficiency.
  • Recommended Settings: Set to 20-30 minutes for chains needing low-latency finality, but ensure it's >15 minutes to comply with the minimum period. Higher values (e.g., two hours) are suitable for low-stakes chains to reduce validator operational costs.
  • Note: Validators require staking (bonding ETH or tokens on the parent chain) to post assertions, with the minimum stake set via the rollup contract during chain deployment. If an incorrect assertion is detected, the interval is bypassed, and a new challenge begins. No new assertions get posted if no new batches arrive or force inclusions occur.

Validator node confirmation frequency: Interval between validator assertions confirming​

The validator assertion confirming frequency is controlled by the --node.staker.staker-interval (legacy) or --node.bold.assertion-confirming-interval (bold) parameter in the Nitro node's configuration. This parameter sets the minimum time to wait since the last assertion before confirming a new one (if the validator configuration is to confirm assertions via the ResolveNodes strategy). The default value is one minute (1m0s) for both legacy and bold.

  • Configuration Options for legacy: Configure this in the node.staker section, e.g., "staker-interval": "45m" for a 45-minute interval.
  • Configuration Options for bold: Configure this in the node.bold section, e.g., "assertion-confirming-interval": "45m" for a 45-minute interval.
  • Recommended Settings: Using the default setting will be fine.
  • Note: Validators require staking (bonding ETH or tokens on the parent chain) to confirm assertions.

Reorganization prevention:​

Reorg resistance margin​

The reorganization resistance margin is configurable via the --node.batch-poster.reorg-resistance-margin parameter, which specifies a time duration (e.g., in minutes) during which the batch poster will avoid posting batches if their minimum L1 block number or timestamp is too close to the current L1 head. This margin serves as a safety buffer to prevent posting batches that reference recent L1 states, which are prone to reorganization. The default value is ten minutes (600 seconds), based on observed usage in deployments and error logs.

  • Detailed Explanation of the Message: The message "Disabling batch posting due to batch being within reorg resistance margin from Layer 1 minimum block or timestamp bounds" signifies that the batch poster's logic has detected the proposed batch's minimum required L1 block or timestamp falls within the configured margin of the current L1 chain head. For example, if the margin is ten minutes and the L1 head timestamp is T, the poster disables itself if the batch requires a minimum timestamp greater than (T - 10m) or a minimum block that is too close to the head. This message serves as a protective mechanism: L1 chains, such as Ethereum, can undergo short reorganizations (e.g., uncle blocks or brief forks), which could invalidate a posted batch if it references a block/timestamp that gets reorganized. By temporarily disabling posting, the system waits for L1 to stabilize, ensuring the batch remains valid once posted. The disablement is transient; posting resumes once the margin clears (e.g., as L1 advances). This message often appears in logs during periods of high L1 volatility or when the sequencer's clock/L1 sync is slightly off. It's normal in such cases, but it may indicate setup issues if it persists.
  • Guidance on Configuration: Set this in the node.batch-poster config section, e.g., "reorg-resistance-margin": "5m". Lower values allow for faster posting but increase the risk; higher values enhance safety. Monitor logs for frequent disablements and adjust accordingly based on the parent chain stability (e.g., Ethereum mainnet vs. testnets).
  • Recommended Settings: The default of ten minutes is suitable for most Orbit chains settling to Arbitrum One/Nova, as Ethereum reorgs rarely exceed a few blocks (1-2 minutes). For chains on more volatile bases (e.g., alt L1s), increase the time to 15-20 minutes. Test on devnets to observe behavior.
  • Trade-offs Between Consistency and Latency: A higher margin prioritizes consistency by reducing the chance of orphaned posted batches due to L1 reorgs, which could force manual intervention or state rollbacks—critical for high-value chains. However, it increases latency, as batches may wait longer to post, delaying confirmation times (e.g., from seconds to minutes). A lower margin reduces latency for a better user experience (faster transaction finality) but risks more frequent disablements or invalid postings, potentially leading to temporary chain halts or increased operational overhead. Balance based on chain use case: low margin for gaming/dex chains that require speed; high margin for DeFi/financial apps that emphasize reliability.

Sequencer max time variation​

The sequencer's max time variation is configurable via the setMaxTimeVariation method of the Sequencer Inbox Contract, which will also be set to prevent chain reorganization when there are no batches for an extended period.

MaxTimeVariation struct:

struct MaxTimeVariation {
    uint256 delayBlocks;
    uint256 futureBlocks;
    uint256 delaySeconds;
    uint256 futureSeconds;
}

The MaxTimeVariation struct defines time boundaries that determine whether your chain remains safe or triggers a reorganization (reorg) when posting batches. It uses both block-based and time-based limits to create acceptable windows for message processing between L1 and L2.

How the safety check works​

When your chain attempts to send a batch, it performs a critical timing validation by comparing the first transaction timestamp in that batch with the current (batch sending) time against the configured MaxTimeVariation limits:

  • For MAX bound violations → Stop adding new messages to the batch
  • For MIN bound violations → Completely prevents batch posting with error: "batch is within reorg resistance margin from Layer 1 minimum block or timestamp bounds"

We will explain how the safety check works in more detail in the next section.

Relationship between ReorgResistanceMargin and MaxTimeVariation​

While both ReorgResistanceMargin and MaxTimeVariation are timing-related security parameters in Arbitrum, they serve complementary but distinct purposes in the batch posting mechanism.

How they work together​

MaxTimeVariation establishes the fundamental time bounds for message validity, while ReorgResistanceMargin adds a safety buffer on top ofMaxTimeVariation's minimum bounds:

  1. Calculate L1 bounds using MaxTimeVariation:
   l1BoundMaxBlockNumber = latestL1BlockNumber + maxTimeVariation.futureBlocks
   l1BoundMinBlockNumber = latestL1BlockNumber - maxTimeVariation.delayBlocks
   l1BoundMaxTimestamp = latestL1Timestamp + maxTimeVariation.futureSeconds
   l1BoundMinTimestamp = latestL1Timestamp - maxTimeVariation.delaySeconds
  1. Add ReorgResistanceMargin to L1 minimum bounds:
   safeBlockThreshold = l1BoundMinBlockNumber + (ReorgResistanceMargin / 12 seconds)
   safeTimestampThreshold = l1BoundMinTimestamp + (ReorgResistanceMargin / 1 second)
  1. Stop adding new messages to the batch if MAX bound violations:
  • If the new message's timestamp ≥ l1BoundMaxTimestamp or block number ≥ l1BoundMaxBlockNumber, stop adding new messages to the batch
  1. Reject batch if MIN bound violations:
  • If the first message in the batch has a timestamp ≤ safeTimestampThreshold or block number ≤ safeBlockThreshold, batch posting is disabled with the error: "batch is within reorg resistance margin from Layer 1 minimum block or timestamp bounds"

Why this relationship matters​

This layered approach provides defense in depth:

  • MaxTimeVariation ensures message timestamps stay within acceptable bounds for normal operation
  • ReorgResistanceMargin prevents batch posting when approaching those bounds, reducing the risk that an L1 reorganization could make a recently posted batch invalid