Did Ethereum’s Fusaka Upgrade Fix the Wrong Bottleneck for Rollups?

Ethereum’s Fusaka upgrade was pitched as a pragmatic way to give rollups more room to breathe. By dialing up blob capacity without a hard fork and stabilizing blob pricing, it aimed squarely at one perceived bottleneck: data availability limits that kept Layer 2 (L2) fees sticky. Three months of data now suggest that Ethereum may have over‑provisioned that specific constraint while underestimating other limiting factors in the rollup stack.

From 6 to 21 blobs: what Fusaka actually changed

Fusaka, activated on Dec. 3, 2025, introduced a live, tunable mechanism for increasing Ethereum’s data availability capacity via Blob Parameter Overrides (BPOs). Instead of a hard‑forked protocol change, clients coordinated on new blob targets and maximums, letting core developers adjust capacity with far less governance friction.

Before Fusaka, Ethereum operated on a baseline set by EIP‑7691: a target of 6 blobs per block with a hard maximum of 9. Fusaka then rolled out in two steps:

• First override (Dec. 9, 2025): target raised from 6 to 10, maximum from 9 to 15.
• Second override (Jan. 7, 2026): target raised from 10 to 14, maximum from 15 to 21.

The stated goal was straightforward: increase throughput for blob data so rollups can post more compressed transaction batches at lower cost, without pressuring execution gas limits. In theory, that should relieve a core pain point for L2s and translate into cheaper end‑user fees.

A MigaLabs study, covering more than 750,000 slots since Fusaka’s activation, provides the first systematic look at whether that new headroom is actually being used—and at what cost to reliability. It also highlights a small but important documentation discrepancy. While the report’s narrative text refers to the first override as moving the target from 6 to 12 blobs, the Ethereum Foundation’s mainnet announcement and client docs define it as 6 to 10. Using the Foundation’s parameters as authoritative, the analysis still treats MigaLabs’ utilization and miss‑rate data as the empirical ground truth.

Capacity vs. reality: why blob usage fell instead of rising

The clearest surprise in the post‑Fusaka data is not at the ceiling but at the median. Rather than drifting upward to meet the new target, blob usage actually declined after the first BPO.

MigaLabs finds that the median blob count per block fell from 6 blobs pre‑override to 4 blobs afterward, despite the network now being capable of 14‑blob targets and a 21‑blob hard maximum. High‑blob blocks are especially rare: blocks containing 16 or more blobs occurred only between 165 and 259 times each across the observation window, depending on the exact blob count.

For teams designing or operating rollups, this divergence between capacity and usage matters more than the headline 21‑blob ceiling. It implies:

• Blob availability isn’t currently the binding constraint. If rollups were truly starved for data availability, the natural response to a 2–3x increase in room per block would be a visible jump in average blob usage. The opposite happened.
• Rollup activity is not scaling to match the new headroom. Blobscan data points to consistent, relatively flat blob usage patterns per rollup, rather than a coordinated surge to capitalize on extra capacity.
• Upstream economics and user behavior may be more limiting than DA capacity. Sequencer incentives, user demand, and fragmentation across many L2s likely matter more right now than raw blob limits.

In other words, Ethereum successfully built a much wider “data lane” for rollups, but traffic has not materialized to fill it. For infrastructure analysts, that suggests Fusaka solved a hypothetical future bottleneck more than a present one.

Reliability at the edge: miss rates explode above 16 blobs

While the average block rarely pushes the new limits, the blocks that do get close to the cap offer a preview of what sustained high utilization might look like. Here, the data is less reassuring.

MigaLabs measured network reliability using missed slots—blocks that fail to propagate or attest correctly. At low to moderate blob counts, the baseline miss rate hovers around 0.5%. However, once blocks cross into high‑blob territory, reliability degrades noticeably:

• Below 16 blobs: miss rates remain under roughly 0.75%.
• 16–20 blobs: miss rates trend up into the 0.77%–1%+ range, forming a clear upward curve.
• 21 blobs (full capacity): the miss rate reaches 1.79%—more than three times the baseline.

The gradient is smooth but unfavorable: reliability gradually worsens as blob counts rise from 10 to 14 and accelerates past the 14‑blob target, peaking at the 21‑blob maximum.

This isn’t a theoretical concern. The pattern suggests that current network infrastructure—validator hardware, bandwidth, client implementations, and attestation timing—is already near a stability boundary when handling high‑blob blocks. Ethereum can technically process these blocks, but doing so consistently and reliably is not yet proven at scale.

If future rollup demand were to regularly drive usage to the 14‑blob target or closer to the 21‑blob ceiling, this elevated miss‑rate profile could translate into:

• Longer time to finality as more attestations are missed or delayed.
• Increased reorg risk under stress, especially during demand spikes.
• Stronger sensitivity to geographic and hardware disparities across validators.

The MigaLabs report’s recommendation follows directly from this data: no further increases in the blob parameter until miss rates at high blob counts normalize and real demand emerges to justify the existing headroom.

Blob pricing post‑Fusaka: the role of the reserve price floor

Fusaka was not only about capacity. Through EIP‑7918, it also re‑shaped blob fee dynamics by introducing a reserve price floor designed to prevent blob base fees from collapsing to near‑zero.

Before EIP‑7918, when execution gas dominated and blob demand was soft, the blob base fee could decay all the way toward 1 wei. At that point, two problems emerge:

• Blobs become effectively free at the margin, letting rollups consume capacity without paying in proportion to the load they impose.
• The fee signal disappears, making it harder for protocol designers and analysts to infer true demand or make capacity decisions based on prices.

EIP‑7918’s response is to tie blob fees to execution costs via a reserve floor, ensuring that even in low‑demand regimes, prices don’t evaporate into noise. Economically, this tries to:

• Prevent “free‑rider” behavior where cheap blobs encourage wasteful posting.
• Keep blob fees as an informative metric: if they remain elevated after a capacity increase, demand is real; if they sink toward the floor, the network still has headroom.

Early post‑Fusaka data from Hildobby’s Dune Analytics dashboard is consistent with that design intent. Blob fees, which had peaked above $2 million at times in early and late 2024 before trending down across 2025, appear to have stabilized rather than continuing a downward spiral.

At the same time, average blob counts per block corroborate MigaLabs’ findings: utilization has not surged to match the new ceiling, and the distribution of blobs per block remains skewed heavily toward lower counts. The reserve floor is doing its job as a guardrail for pricing and signal quality, but it is not—nor was it intended to be—a demand driver on its own.

Did Fusaka target the wrong bottleneck for rollups?

Taken together, the post‑Fusaka data points to a nuanced conclusion. By most engineering metrics, the upgrade worked:

• Blob capacity was safely increased via BPOs without a contentious hard fork.
• The network demonstrated it can handle occasional high‑blob blocks, albeit with a higher miss‑rate profile.
• The reserve price floor kept blob pricing from becoming meaningless when demand softened.

But if the original concern was that limited blob capacity was keeping rollup fees elevated and constraining L2 growth, the empirical picture is less aligned with that narrative. Key signals point elsewhere:

• Median blob usage dropped after the first override, from 6 to 4 blobs per block.
• High‑blob blocks are rare, indicating that rollups are not racing to fill the new 14/21 headroom.
• Individual rollups show steady, not accelerating, blob posting patterns, according to Blobscan.

This suggests that, at present, rollups are not materially constrained by blob availability. The bottleneck appears to have shifted—away from on‑chain data availability caps and toward factors like:

• Sequencer economics and business models.
• Underlying user demand across applications.
• Fragmentation across multiple L2s and ecosystems.
• Compression and batching strategies that remain optimized for earlier capacity levels.

From a protocol‑design perspective, Fusaka looks less like a targeted fix for an active pain point and more like an investment in future headroom. It also exposes a tension: the network can scale its DA limits faster than its operational reliability at those limits, and much faster than rollup utilization is currently scaling.

Roadmap implications: PeerDAS and when to turn the next dial

Fusaka is not the end of Ethereum’s data availability roadmap. Upcoming work such as PeerDAS aims to redesign how data availability sampling works, further expanding blob capacity while strengthening decentralization and security properties.

However, the current data indicates that raw capacity is not the short‑term constraint. The network already has significant room to grow into the existing 14‑blob target and 21‑blob maximum. At the same time, the miss‑rate curve at high blob counts draws a clear boundary: pushing capacity higher while blocks with 16+ blobs still exhibit 1%–1.79% miss rates would risk importing systemic instability, especially under peak activity.

For developers and infrastructure teams, the near‑term priorities implied by the Fusaka results are:

• Let utilization naturally approach current parameters before considering another BPO increase.
• Focus on client and networking optimizations so that high‑blob blocks no longer carry a 3x miss‑rate penalty versus baseline.
• Use blob fees and usage distributions as primary signals for when DA capacity is again becoming a true bottleneck.

On its own terms, Fusaka expanded capacity and improved the economic clarity of blob pricing. It did not catalyze a surge in rollup activity, nor did it fully resolve reliability challenges at the edge of the new capacity envelope. Instead, it created headroom that the ecosystem has yet to need—and a set of empirical guardrails that should inform when, and how, Ethereum dials the next round of DA scaling.

Whether that headroom ultimately proves prescient or premature will depend less on the protocol’s ability to raise blob ceilings and more on whether rollup demand, infrastructure, and economics converge to actually use the space already on offer.