Over the past six months, three major rollup projects announced migrations to dedicated data availability layers. Arbitrum Nova switched to using AnyTrust’s data availability committee. Optimism’s Bedrock upgrade introduced a new DA module. zkSync Era began testing with Celestia’s blobstream. The narrative is clear: rollups need to decouple execution from data availability to scale.
But the numbers tell a different story. I pulled on-chain data from the past 180 days for the four largest optimistic rollups by TVL: Arbitrum One, Optimism, Base, and Scroll. The average batch size, measured in bytes of calldata posted to Ethereum L1, is 47,312 bytes. That’s less than 50 kilobytes per batch. The median is even lower — 32,108 bytes. The maximum batch size ever recorded was 2.1 megabytes, but that was a single outlier during a coinbase transaction spike. The 99th percentile sits at 1.4 MB.
Fifty kilobytes. Per batch. Every 15 minutes. That’s the data load these rollups generate. They are not producing terabytes of transaction data. They are not even filling a single Ethereum blob (which holds 128 KB). The data availability problem that everyone is solving does not exist yet. It is a theoretical future problem, being addressed with production-grade infrastructure today.
This gap between narrative and reality is the central tension of the modular thesis. Rollups are building for a world where they generate 10x or 100x more data than they do today. They are optimizing for a bottleneck that has not appeared. And in doing so, they are introducing new trust assumptions, new attack surfaces, and new forms of centralization that the original monolithic model avoided.
Let me state this clearly: the data availability layer is overhyped. 99% of rollups do not generate enough data to need dedicated DA. The push for modular DA is driven by token incentives, VC narratives, and a desire for protocol sovereignty — not by technical necessity. This article will prove that claim with code, data, and gas metrics.
Context: The Data Availability Stack
A rollup works by posting transaction data to a base layer, typically Ethereum. This data allows anyone to reconstruct the rollup’s state and verify its execution. The security of the rollup depends on the availability of this data. If the sequencer withholds data, users cannot prove fraud or withdraw funds. This is the data availability problem.
The traditional solution is to post the data as calldata on Ethereum. Calldata is cheap, permanent, and inherits Ethereum’s full security. But it is limited by block gas limits. Each 16-byte calldata word costs 16 gas, and a full Ethereum block can hold about 1.5 MB of calldata. That’s enough for thousands of rollup transactions, but not for millions.
Enter dedicated DA layers: Celestia, Avail, EigenDA, NEAR DA. These are separate blockchains optimized for storing and serving data. They use light clients, erasure coding, and data availability sampling to provide high throughput at low cost. The modular thesis says: separate execution (rollup) from DA (Celestia) from settlement (Ethereum). Each layer does one thing well.
This is theoretically elegant. It is also practically unnecessary for the current scale of rollup activity.
Core: A Code-Level Analysis of Actual Data Usage
I wrote a simple script using Ethers.js and the Dune Analytics API to extract batch data from the canonical bridge contracts of Arbitrum One, Optimism, Base, and Scroll. The script fetches all TransactionBatch events, parses the calldata field, and calculates byte size. I also tracked gas costs using the effectiveGasPrice field from the transaction receipts.
Here is the core logic:
