Batch Posting

What Is Batch Posting?

Batch posting is the process by which a rollup sequencer bundles multiple Layer 2 transactions together and submits them as a single compressed data package to the Layer 1 blockchain. Rather than posting each L2 transaction individually to the base layer (which would negate the cost savings of using a rollup in the first place), the sequencer accumulates transactions over a short window, compresses them, and writes the entire batch in one L1 transaction.

This mechanism is fundamental to how rollups achieve scalability. The L1 chain only needs to store the compressed batch data for data availability purposes, while the actual execution happens off-chain on the rollup. The result is that users pay a fraction of what a direct L1 transaction would cost, because the fixed overhead of an L1 transaction is split across every L2 transaction in the batch.

How It Works

The batch posting lifecycle follows a consistent pattern across major rollup implementations:

1. Users submit transactions to the L2 sequencer, which receives, orders, and executes them off-chain
2. The sequencer accumulates executed transactions into a batch, either until a size threshold is reached or a maximum time interval elapses
3. The batch is compressed using algorithms like Brotli (Arbitrum) or zlib (Optimism/OP Stack) to minimize the L1 data footprint
4. The compressed batch, along with a state commitment, is posted to an L1 smart contract (such as Arbitrum's Sequencer Inbox)
5. The L1 contract stores the batch data, making it available for verification by validators or challengers

Batch Configuration

Rollup operators configure batch posting through parameters that control when and how batches are submitted. These parameters directly influence the cost-finality tradeoff:

# Arbitrum batch poster configuration
--max-delay=30m          # Maximum time before forcing a batch post
--max-size=100000        # Maximum batch size in bytes
--compression-level=11   # Brotli compression level (0-11)

# OP Stack batcher configuration
OP_BATCHER_MAX_CHANNEL_DURATION=6  # Max channel duration in L1 blocks
OP_BATCHER_TARGET_NUM_FRAMES=1     # Target number of frames per channel

Arbitrum further groups transactions into batches with a default maximum size of 100,000 bytes. The OP Stack batcher groups sequencer batches into "channels" (sequences of batches compressed together) for improved compression ratios, since larger data sets compress more efficiently.

Compression Techniques

Compression is critical to batch posting economics. Rollups employ both general-purpose compression algorithms and blockchain-specific optimizations:

• Brotli compression (used by Arbitrum): achieves approximately 50% size reduction with dynamically adjusted compression levels based on L1 congestion
• Zlib compression (used by OP Stack): achieves roughly 39% compression rate and 43% fee savings, chosen for its speed and broad language support
• Encoding optimizations: replacing 32-byte ABI-encoded fields with tighter encodings (1 byte instead of 32 for small values)
• Zero-byte optimization: in calldata, zeros cost 4 gas versus 16 gas for non-zero bytes, incentivizing compression schemes that maximize zero bytes

One important characteristic: smaller batches compress less efficiently than larger ones because compression algorithms have less data to find patterns in. This means two small batches typically cost more total gas than one large batch of the same aggregate size, creating an economic incentive toward less frequent, larger batch posts.

Batch Posting Economics

The core economic insight behind batch posting is cost amortization. An L1 transaction has a fixed base cost regardless of payload size. By packing hundreds or thousands of L2 transactions into that single L1 transaction, the fixed cost is divided across all of them.

L2 transaction fees must cover three cost components: L2 execution and storage costs, L1 data availability costs (the batch posting itself), and L1 gas costs for proof verification (in the case of ZK-rollups) or fraud proof settlement (for optimistic rollups). The L1 data availability cost typically dominates, making batch posting efficiency the primary driver of L2 fee levels.

Research from Offchain Labs (the team behind Arbitrum) found that a smart batch posting algorithm, which waits for lower L1 gas prices before submitting, can reduce posting costs by 8-29% compared to posting every batch immediately.

The EIP-4844 Impact

Before EIP-4844, rollups posted batch data as calldata in regular L1 transactions, competing for the same block space as all other Ethereum transactions. EIP-4844 (Proto-Danksharding), activated in March 2024 with Ethereum's Dencun hard fork, introduced a dedicated data lane via blob transactions.

Each blob holds approximately 128 KB of data, and a block can carry up to six blobs (with a target of three). Blobs are stored temporarily (approximately 18 days) rather than permanently, and have their own separate fee market independent of the regular gas market. This decoupling was transformative for rollup economics:

• L2 transaction fees dropped roughly 90-95% in the weeks following Dencun
• Median fees on major rollups fell from $0.20-$1.00 ranges to $0.01-$0.10
• zkSync Era's sequencer calldata costs dropped from 0.11 ETH to 0.013 ETH per batch (an 88% reduction)

For a deeper analysis of how blob fees work, see the research article on EIP-4844 and the blob fee market.

Batch Frequency Tradeoffs

Rollup operators face a fundamental tradeoff when configuring batch posting frequency: posting more frequently provides faster finality guarantees on L1 but increases aggregate L1 costs, while posting less frequently reduces costs but delays finality.

Current observed batch posting intervals across major rollups illustrate how different chains navigate this tradeoff:

It is worth noting that these intervals represent data submission to L1, not finality. Optimistic rollups like Arbitrum and Optimism still have a 7-day challenge window before native withdrawals finalize. The batch posting interval determines how quickly transaction data becomes available on L1 for verification.

Comparison with Bitcoin Transaction Batching

Transaction batching on Bitcoin L1 is a related but fundamentally different optimization. Bitcoin batching combines multiple payment outputs into a single on-chain transaction, sharing the fixed transaction overhead across many recipients.

The distinction is one of scope: Bitcoin batching reduces redundancy within L1 transactions by consolidating outputs, while rollup batch posting moves entire computation off-chain and only posts compressed data to L1 for verification. Bitcoin batching might combine 10-50 payments into one transaction; rollup batch posting aggregates hundreds to thousands of full transactions into one compressed submission.

Bitcoin Layer 2 solutions like the Lightning Network and Spark take a different approach to scaling entirely, using off-chain channels and state transfers rather than rollup-style batch posting. For a comparison of these approaches, see the research on rollups versus state channels.

Use Cases

• General-purpose L2 scaling: every major Ethereum rollup (Arbitrum, Optimism, Base, zkSync, Starknet) uses batch posting as its primary mechanism for submitting transaction data to L1
• High-throughput applications: DeFi protocols, NFT marketplaces, and gaming platforms on L2 rely on batch posting to keep per-transaction costs low enough for frequent, small-value transactions
• Data anchoring: some rollups use batch posting to anchor state commitments to L1 even when full transaction data is stored elsewhere (as in validium architectures)
• Cross-chain settlement: batch posting provides the data availability guarantee that enables bridges and cross-chain protocols to verify L2 state against L1

Risks and Considerations

Sequencer Centralization

Most rollups currently rely on a single sequencer to create and post batches. This centralization creates risks around censorship, liveness, and MEV extraction. If the sequencer goes offline, no batches are posted and L2 transactions cannot achieve L1 finality. For a deeper analysis, see the research on L2 sequencer decentralization.

Most rollups mitigate this with a "force inclusion" escape hatch: users can submit transactions directly to the L1 contract, bypassing the sequencer. Arbitrum provides a force inclusion window of approximately 24 hours, while Optimism uses approximately 12 hours.

Delayed Finality

If batch posting is delayed (whether by sequencer failure, gas price optimization strategies, or network congestion), L1 data availability for those transactions is delayed as well. Users relying on L1 finality guarantees are exposed during the gap between L2 execution and L1 batch posting.

Cost Variability

Batch posting costs fluctuate with L1 gas prices and blob fee markets. During periods of high L1 congestion, posting costs spike and are passed through to L2 users. Smaller rollups with lower transaction volume face structurally higher per-transaction costs because they have fewer transactions to amortize the fixed L1 posting cost across.

Data Availability Tradeoffs

With EIP-4844, blob data is only retained for approximately 18 days. After that period, the raw batch data is pruned from the network. Rollups and their users must ensure that any data needed for dispute resolution or historical verification is archived separately before it expires.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.