Rollup Batching Explained: How It Cuts Gas Fees
Rollup batching bundles hundreds of L2 transactions into a single Ethereum submission, cutting per-user fees by up to 90%. Learn how it works, step by step.
Key takeaways
- Rollup batching is the mechanism by which a Layer 2 network aggregates many user transactions into a single compressed bundle before posting to Ethereum L1.
- The sequencer is the component that orders and groups transactions on L2, while the batcher is what posts that data to Ethereum. They have distinct roles in the pipeline.
- EIP-4844 (blobs) introduced a dedicated, cheaper data lane on Ethereum specifically for rollup batches, cutting data posting costs by roughly 90% overnight when activated in March 2024.
- Batch size is a trade-off. Larger batches cost less per transaction but introduce more latency for users waiting for their transaction to be included.
Rollup batching is the core mechanism that makes Ethereum Layer 2 economically viable. By grouping hundreds of transactions into a single L1 submission, it distributes the fixed cost of writing to Ethereum across every user in the batch, turning a $5 mainnet fee into fractions of a cent on L2.
The mechanics behind that cost reduction are more layered than they first appear, and understanding them is useful for anyone building on or using an Ethereum L2 today.
What Is Rollup Batching?
| Quick answer: Rollup batching is the process by which a Layer 2 network collects hundreds or thousands of user transactions, compresses them into a single bundle, and posts that bundle to Ethereum L1 as one transaction. |
That way, the fixed cost of writing to L1 is split across every transaction in the batch rather than charged to each user individually. This cost-sharing mechanism is the fundamental reason L2 transactions can be a fraction of the price of equivalent L1 transactions.
Without batching, every L2 action would require its own separate Ethereum write, and users would pay mainnet prices. Batching changes the economics entirely by amortizing L1 overhead across potentially thousands of users at once.
How Rollup Batching Works (Step by Step)
In short: The batching pipeline moves through four distinct stages:
Each stage serves a specific purpose in making the process both secure and cost-efficient. |
Step 1: The sequencer collects and orders transactions
When a user submits a transaction to a rollup, it enters the L2 network and is picked up by the sequencer – a specialized node responsible for ordering and executing transactions.
The sequencer does not immediately post anything to Ethereum. Instead, it accumulates transactions and produces sequencer batches: ordered lists of L2 transactions tagged with an epoch number and the L2 block timestamp. This ordering step is critical because the sequence in which transactions are processed determines the final state of the rollup.
At this point, users receive soft finality. The sequencer has acknowledged their transaction and committed to an order. This is fast (often sub-second), but it is not yet backed by Ethereum's security.
Step 2: Batcher groups batches into channels
Once the sequencer has produced batches, a separate component called the batcher takes over. The batcher does not post each sequencer batch to L1 individually. Instead, it groups multiple sequencer batches into a structure called a channel.
A channel is a sequence of compressed sequencer batches. The reason for this grouping is purely economic. Compressing multiple batches together achieves a significantly better compression ratio than compressing each batch alone. The result is less data posted to L1, which means lower costs.
If a channel grows too large to fit in a single L1 transaction, it is split into multiple frames, which are sent sequentially. All frames reference the same channel ID so that Ethereum can reassemble them correctly.
Step 3: Compression and data posting
Before posting to Ethereum, the channel data is compressed. Arbitrum Nitro, for example, uses the Brotli algorithm, with the compression level dynamically adjusted between 0 and 11 depending on network congestion. Higher compression levels reduce L1 data size (and therefore cost) but require more computation time from the batcher.
The compressed data is then submitted to Ethereum via one of two methods:
Method | Description | When used |
| Blob transactions (EIP-4844) | Data posted to a dedicated, cheaper blob lane on L1 | Default post-March 2024 |
| Calldata | Data embedded directly in a standard Ethereum transaction | Fallback when blobs are unavailable |
Blob transactions are the default for all major rollups post-EIP-4844, since they operate in a separate fee market and cost far less than calldata at equivalent data sizes.
Step 4: L1 Receives and anchors the batch
Once the batch data lands on Ethereum, it is stored and indexed. The rollup's smart contract on L1 records a state commitment – a cryptographic summary of the new rollup state after executing all transactions in the batch.
This is the moment when the batch achieves hard finality. Anyone can read the raw batch data from Ethereum and independently reconstruct the full L2 state. This data availability guarantee is what makes rollups fundamentally different from sidechains. Even if the rollup operator disappears entirely, the data to reconstruct the state remains on Ethereum permanently.
One L1 transaction now represents hundreds or thousands of L2 transactions. The cost of that L1 transaction is shared proportionally across every user whose transaction was included in the batch.
If you want to understand exactly what soft finality and hard finality mean and how they affect your transactions, this article covers both in detail.
BytebyByte's observation: The part most articles skip
The batching pipeline is often described as if it were a single, uniform action – "transactions get bundled and sent to L1." In practice, it is a three-layer compression hierarchy: individual transactions are ordered into sequencer batches, those batches are grouped into channels for better compression, and channels are split into frames if they exceed L1 transaction size limits. Each layer exists for a specific reason. Understanding this hierarchy matters because it explains rollup fees are also a function of how well the compressor is doing its job, how congested the blob fee market is, and whether the batcher is operating near its optimal channel size. Most users will never see these variables, but they directly determine the gas cost embedded in every swap, transfer, or mint on any major Ethereum L2 today.
Optimistic vs ZK Rollups: Does Batching Differ?
| At a glance: Both optimistic and ZK rollups use the same core batching pipeline, including sequencer, batcher, channel, and L1 posting. The difference lies not in how they batch, but in how they prove that a batch is valid. |
Optimistic rollups (Arbitrum, OP Mainnet, Base) post batch data to L1 along with a claimed new state root. They assume the batch is correct unless someone proves otherwise. Challengers have a 7-day window to submit a fraud proof if they detect an invalid state transition. If no challenge is raised, the batch is considered final.
ZK rollups (zkSync Era, Scroll, Linea) generate a cryptographic validity proof (either an SNARK or STARK) for each batch before or shortly after submission. Ethereum verifies this proof on-chain. If the proof is valid, the state update is accepted immediately. There is no challenge window because correctness is mathematically guaranteed upfront.
Optimistic Rollup | ZK Rollup | |
| Batch data posted | Compressed tx data + state root | Compressed tx data + validity proof |
| Proof type | Fraud-proof (reactive) | Validity proof (proactive) |
| Finality on L1 | ~7 days after batch submission | Near-instant after proof verification |
| Batch flexibility | High – batch anytime | Proof generation cost shapes optimal batch size |
| EVM compatibility | Near-perfect (Arbitrum, OP) | Improving fast (zkEVM networks) |
ZK rollups often operate with two levels of batching internally. ZKsync, for instance, uses miniblocks (small, frequent groups for low-latency L2 UX) and L1 batches (larger consolidated groups optimized for proof efficiency and on-chain cost).
This dual-layer structure reflects the additional constraint ZK rollups face: generating a validity proof is computationally expensive, so batching larger groups together amortizes that proving cost more effectively.
How EIP-4844 Changed Rollup Batching Economics
| Quick answer: EIP-4844 (activated on March 13, 2024, as part of the Dencun hard fork) is the single biggest structural change to rollup batching economics in Ethereum's history. It introduced blob-carrying transactions – a new transaction type that lets rollups post batch data to a dedicated, cheaper data lane rather than paying standard calldata gas prices. |
Before EIP-4844, all rollup batches had to be posted as calldata, which competes for the same block space as ordinary Ethereum transactions. During periods of high L1 congestion, posting a single rollup batch could cost hundreds of dollars – a cost that was directly passed on to L2 users.
After EIP-4844, that same data goes into a blob, which operates in its own separate fee market.
Key properties of blobs:
- Each blob is approximately 128 KB, sized specifically for rollup payloads
- A single Ethereum block can carry up to 6 blobs (target: 3)
- Blob fees adjust dynamically via an EIP-1559-style mechanism, but start extremely low (fractions of a gwei) because blob space is deliberately oversized relative to current rollup demand
- Blob data is stored by consensus clients for approximately 18 days, then pruned, long enough for fraud proofs to settle, but not stored permanently on-chain
The impact was immediate. Average transaction fees on Base dropped from the $0.05–$0.30 range to below $0.001 for most transactions. Every major rollup migrated to blob transactions within weeks of the Dencun upgrade going live.
The Batch Size Trade-off: Efficiency vs Latency
| At a glance: Larger batches cost less per transaction, but they also make users wait longer. This is the fundamental tension in rollup batch sizing, and every sequencer operator must manage it continuously. |
1. The economics are straightforward
- If the fixed cost of posting one L1 transaction is $0.50, and a batch contains 500 transactions, the per-user data cost is $0.001.
- If the same batch contains only 50 transactions (because the sequencer didn't wait long enough), that per-user cost rises tenfold.
Batching larger is always cheaper per user, but only if there are enough users to fill the batch.
2. The latency cost
A sequencer waiting to fill a larger batch introduces a delay. During low-traffic periods, this can mean a user's transaction sits in the sequencer queue for longer than necessary before being committed to L1.
→ This creates a visible UX problem. A transaction can receive soft finality immediately (the sequencer acknowledges it) but take much longer to achieve hard finality (posted and confirmed on L1).
3. How sequencers handle this trade-off in practice
Most rollup implementations use a hybrid trigger model:
- Post a batch when it reaches a size threshold (e.g., the batch fills a blob)
- Post a batch after a time interval regardless of size, to prevent excessive latency during low-traffic periods
Arbitrum Nitro applies this model directly. Batches form either when transactions accumulate to a predefined size or after a set time interval to prevent delays. The Brotli compression level is also adjusted dynamically. During heavy backlogs, the system prioritizes speed by using a lower compression setting, trading some data efficiency for faster throughput.
This means the "cost per transaction" that L2 users see is not a fixed number — it fluctuates with network activity, blob demand, and how well the sequencer's batch size is calibrated to current conditions.
>> Learn more: Ethereum Gas Limit: Why Transactions Fail and Fees Rise
Why Rollup Batching Matters for Users and Developers
| Quick answer: Rollup batching is the direct mechanism responsible for why interacting with Ethereum L2 costs orders of magnitude less than L1. Understanding it helps both users and developers make better decisions about how they use and build on rollups. |
1. For users
The gas fee displayed on any L2 transaction is primarily composed of two parts:
- The L2 execution cost (cheap, because a single sequencer processes it instead of thousands of Ethereum validators)
- The L2's share of L1 data posting costs
The second component is a function of batching. When blob demand is low and batches are large, users pay almost nothing. When blob space is saturated, or batches are small due to low network activity, that cost rises.
EIP-4844's blob market introduced a separate gas dimension that users don't directly interact with, but that shapes the fees they see. This is why L2 fees can spike during periods of unusual Ethereum L1 activity, even when L2 itself isn't congested.
2. For developers
Gas optimization on L2 is not just about writing efficient Solidity. Developers should also consider the data footprint of their transactions. Calldata-heavy operations, like batch transfers with many recipients, or large struct-heavy function calls, post more data per transaction, which increases the rollup operator's L1 cost and, over time, may be reflected in higher user fees or gas cost estimates on specific contract functions.
A practical rule: Minimize on-chain calldata where possible on L2 to reduce the per-transaction data that the batcher must eventually post to Ethereum.
Sources and Further Reading
- Ethereum.org – "Optimistic Rollups" https://ethereum.org/developers/docs/scaling/optimistic-rollups/
- Ethereum.org – "EIP-4844 (Proto-Danksharding)" https://eips.ethereum.org/EIPS/eip-4844
- Arbitrum Docs – "Inside Arbitrum Nitro" https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro
- Arbitrum Docs – "A Gentle Introduction to Arbitrum" https://docs.arbitrum.io/welcome/arbitrum-gentle-introduction
- arxiv.org – "Impact of EIP-4844 on Ethereum: Rollup Transaction Dynamics and Blob Gas Fee Markets" https://arxiv.org/abs/2405.03183
- IET Blockchain – "Cost Optimization in Layer 2 Rollups via EIP-4844: A Gas Efficiency and Economic Analysis" https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/blc2.70014
FAQs About Rollup Batching
The sequencer can technically delay, including a specific transaction. However, most rollups implement a force inclusion mechanism that allows users to bypass the sequencer entirely by submitting their transaction directly to the L1 rollup inbox contract. This ensures censorship resistance even if the sequencer acts maliciously.
