Ethereum activated the Fusaka upgrade on Dec. 3, 2025, raising the network’s data availability capacity through Blob Parameter Overrides that incrementally expanded blob targets and maximums.

Two subsequent adjustments raised the target from 6 blobs per block to 10, then to 14, with a maximum ceiling of 21. The goal was to reduce layer-2 rollup costs by increasing throughput for blob data, the compressed transaction bundles that rollups post to Ethereum for security and finality.

Three months into data collection, the results reveal a gap between capacity and utilization. A MigaLabs analysis of over 750,000 slots since Fusaka’s activation shows that the network isn’t reaching the target blob count of 14.

Median blob usage actually declined after the first parameter adjustment, and blocks containing 16 or more blobs exhibit elevated miss rates, suggesting reliability degradation at the edges of new capacity.

The report’s conclusion is direct: no further increases in the blob parameter until high-blob miss rates normalize and demand materializes for the headroom already created.

What Fusaka changed and when it happened

Ethereum’s pre-Fusaka baseline, established through EIP-7691, set the target at 6 blobs per block with a maximum of 9. The Fusaka upgrade introduced two sequential Blob Parameter Override adjustments.

The first was activated Dec. 9, raising the target to 10 and the maximum to 15. The second was activated Jan. 7, 2026, pushing the target to 14 and the maximum to 21.

These changes didn’t require hard forks, and the mechanism allows Ethereum to dial capacity through client coordination rather than protocol-level upgrades.

The MigaLabs analysis, which published reproducible code and methodology, tracked blob usage and network performance across this transition.

It found that the median blob count per block fell from 6 before the first override to 4 afterward, despite the network’s capacity expanding. Blocks containing 16 or more blobs remain extremely rare, occurring between 165 and 259 times each across the observation window, depending on the specific blob count.

The network has headroom it isn’t using.

One parameter discrepancy: the report’s timeline text describes the first override as raising the target from 6 to 12, but the Ethereum Foundation’s mainnet announcement and client documentation describe the adjustment as 6 to 10.

We use the Ethereum Foundation’s parameters as source: 6/9 baseline, 10/15 after the first override, 14/21 after the second. Nevertheless, we treat the report’s dataset for observed utilization and miss-rate patterns as the empirical backbone.

Miss rates climb at high blob counts

Network reliability measured through missed slots, which are blocks that fail to propagate or attest correctly, shows a clear pattern.

At lower blob counts, the baseline miss rate sits around 0.5%. Once blocks reach 16 or more blobs, miss rates climb to 0.77% to 1.79%. At 21 blobs, the maximum capacity introduced in the second override, the miss rate hits 1.79%, more than triple the baseline.

The analysis breaks this down across blob counts from 10 to 21, showing a gradual degradation curve that accelerates past the 14-blob target.

This degradation matters because it suggests the network’s infrastructure, such as validator hardware, network bandwidth, and attestation timing, struggles to handle blocks at the upper end of capacity.

If demand eventually rises to fill the 14-blob target or push toward the 21-blob maximum, the elevated miss rates could translate into meaningful finality delays or reorg risk. The report frames this as a stability boundary: the network can technically process high-blob blocks, but doing so consistently and reliably remains an open question.

Blob economics: why the reserve price floor matters

Fusaka didn’t only expand capacity. It also changed blob pricing through EIP-7918, which introduces a reserve price floor to prevent blob auctions from collapsing to 1 wei.

Before this change, when execution costs dominated and blob demand stayed low, the blob base fee could spiral downward until it effectively disappeared as a price signal. Layer-2 rollups pay blob fees to post their transaction data to Ethereum, and those fees are supposed to reflect the computational and network costs that blobs impose.

When fees fall to near zero, the economic feedback loop breaks, and rollups consume capacity without paying in proportion. This results in the network losing visibility into actual demand.

EIP-7918’s reserve price floor ties blob fees to execution costs, ensuring that even when demand is soft, the price remains a meaningful signal.

This prevents the free-rider problem where cheap blobs encourage wasteful usage and provides clearer data for future capacity decisions: if blob fees stay elevated despite increased capacity, demand is genuine; if they collapse to the floor, headroom exists.

Early data from Hildobby’s Dune dashboard, tracking Ethereum blobs, shows that blob fees have stabilized after Fusaka rather than continuing the downward spiral seen in earlier periods.

The average blob count per block confirms MigaLabs’ finding that utilization hasn’t surged to fill the new capacity. Blocks routinely carry fewer than the 14-blob target, and the distribution remains heavily skewed toward lower counts.

What the data reveals about effectiveness

Fusaka succeeded in expanding technical capacity and proving the Blob Parameter Override mechanism works without requiring contentious hard forks.

The reserve price floor appears to be functioning as intended, preventing blob fees from becoming economically meaningless. But utilization lags behind capacity, and reliability at the edges of new capacity shows measurable degradation.

The miss rate curve suggests Ethereum’s current infrastructure comfortably handles the pre-Fusaka baseline and the first override’s 10/15 parameters, but begins to strain past 16 blobs.

This creates a risk profile: if layer-2 activity surges and pushes blocks toward the 21-blob maximum regularly, the network could face elevated miss rates that compromise finality and reorg resistance.

Demand patterns offer another signal. Median blob usage falling after the first override, despite increased capacity, suggests that layer-2 rollups aren’t currently constrained by blob availability.

Either their transaction volumes haven’t grown enough to require more blobs per block, or they’re optimizing compression and batching to fit within existing capacity rather than expanding usage.

Blobscan, a dedicated blob explorer, shows individual rollups posting relatively consistent blob counts over time rather than ramping up to exploit new headroom.

The pre-Fusaka concern was that limited blob capacity would bottleneck Layer 2 scaling and keep rollup fees elevated as networks competed for scarce data availability. Fusaka addressed the capacity constraint, but the bottleneck appears to have shifted.

Rollups aren’t filling the available space, which means either demand hasn’t arrived yet or other factors, such as sequencer economics, user activity, and cross-rollup fragmentation, are limiting growth more than blob availability was.

What comes next

Ethereum’s roadmap includes PeerDAS, a more fundamental redesign of data availability sampling that would further expand blob capacity while improving decentralization and security properties.

However, the Fusaka results suggest that raw capacity isn’t the binding constraint right now.

The network has room to grow into the 14/21 parameters before needing another expansion, and the reliability curve at high blob counts indicates that infrastructure upgrades may need to catch up before capacity increases again.

The miss rate data provides a clear boundary condition. If Ethereum pushes capacity higher while 16+ blob blocks still show elevated miss rates, it risks introducing systemic instability that could surface during high-demand periods.

The safer path is to let utilization rise toward the current target, monitor whether miss rates improve as clients optimize for higher blob loads, and adjust parameters only once the network demonstrates it can reliably handle edge cases.

Fusaka’s effectiveness depends on the metric. It expanded capacity successfully and stabilized blob pricing through the reserve floor. It didn’t drive immediate utilization increases or solve the reliability challenges at maximum capacity.

The upgrade created headroom for future growth, but whether that growth materializes remains an open question the data hasn’t answered yet.