Ethereum activated the Fusaka upgrade on December 3, 2025, increasing the network’s data availability capacity via Blob Parameter Overrides that incrementally expanded blob targets and maxima.
Two subsequent tweaks increased the target from 6 blobs per block to 10 and then to 14, with a maximum of 21. The goal was to reduce layer 2 merge costs by increasing throughput for blob data, the compressed transaction bundles that post merges to Ethereum for security and finality.
Three months after data collection, results show a gap between capacity and utilization. A MigaLabs analysis of more than 750,000 slots since Fusaka’s activation shows that the network does not reach the target number of blobs of 14.
Median blob usage actually decreased after the first parameter adjustment, and blocks with 16 or more blobs exhibit higher miss rates, indicating that reliability is decreasing at the edges of the new capacity.
The conclusion of the report is direct: no further increases in the blob parameter until the number of missed blobs normalizes and demand arises for the space already created.
What Fusaka changed and when it happened
Ethereum’s pre-Fusaka baseline, established via EIP-7691, set the target at 6 blobs per block with a maximum of 9. The Fusaka upgrade introduced two consecutive Blob Parameter Override adjustments.
The first was activated on December 9, increasing the target to 10 and the maximum to 15. The second was activated on January 7, 2026, increasing the target to 14 and the maximum to 21.
These changes did not require hard forks, and the mechanism allows Ethereum to determine capacity through client coordination rather than protocol-level upgrades.
The MigaLabs analysis, which published reproducible code and methodology, tracked blob usage and network performance during this transition.
This showed that the average number of blobs per block dropped from 6 before the first override to 4 afterwards, despite the network capacity expansion. Blocks with 16 or more blobs remain extremely rare, each occurring between 165 and 259 times in the observation window, depending on the specific number of blobs.
The network has space it is not using.
One parameter difference: the report’s timeline text describes the first override as increasing the target from 6 to 12, but the Ethereum Foundation’s mainnet announcement and customer documentation describe the adjustment as 6 to 10.
We use the The Ethereum Foundation parameters as source: 6/9 baseline, 10/15 after the first override, 14/21 after the second. Nevertheless, we consider the report’s dataset for observed usage and error rate patterns as the empirical backbone.
The number of misses increases with high blob numbers
Network reliability measured via missed slots, which are blocks that do not propagate or attest correctly, shows a clear pattern.
At lower bloc numbers, the basic failure rate is around 0.5%. Once blocks reach 16 or more blobs, the misses increase to 0.77% to 1.79%. At 21 blobs, the maximum capacity introduced by the second override, the miss rate is 1.79%, more than triple the baseline.
The analysis breaks this down across blob counts from 10 to 21, showing a gradual degradation curve accelerating beyond the 14 blob target.
This degradation is important because it suggests that the network’s infrastructure, such as validator hardware, network bandwidth, and attestation timing, is struggling to process blocks at the high end of capacity.
If demand ultimately increases to meet the 14 blob goal or move toward the 21 blob maximum, the higher miss rates could translate into significant finality delays or reorganization risk. The report describes this as a stability limit: the network can technically handle high-blob blocks, but doing so consistently and reliably remains an open question.
Blob economics: why the minimum price matters
Fusaka didn’t just expand capacity. It also changed blob prices via EIP-7918, which introduces a floor price to prevent blob auctions from collapsing to 1 meadow.
Before this change, when execution fees dominated and blob demand remained low, the blob base fee could enter a downward spiral until it effectively disappeared as a price signal. Layer-2 rollups pay blob fees to post their transaction data to Ethereum, and these fees should reflect the compute and network costs that blobs incur.
When fees drop to near zero, the economic feedback loop is broken and rollups consume capacity without paying proportionately. This means that the network loses insight into actual demand.
EIP-7918’s floor price ties blob fees to fulfillment costs, ensuring that even when demand is weak, the price remains a meaningful signal.
This avoids the free-rider problem where cheap blobs encourage wasteful usage and provides clearer data for future capacity decisions: if blob rates remain high despite increased capacity, demand is real; if they fall to the ground, there is headroom.
Early data from Hildobby’s Dune dashboard, which tracks Ethereum blobs, shows blob fees are being charged have stabilized after Fusaka rather than continuing the downward spiral from previous periods.
The average number of blobs per block confirms MigaLabs’ finding that usage has not increased to fill the new capacity. Blocks routinely contain fewer than the target of 14 blobs, and the distribution remains heavily skewed toward lower numbers.
What the data reveals about effectiveness
Fusaka managed to expand technical capacity and prove that the Blob Parameter Override mechanism works without the need for controversial hard forks.
The minimum price appears to be functioning as intended, preventing blob fees from becoming economically meaningless. But utilization is lagging behind capacity, and reliability at the edges of new capacity is showing measurable decline.
The miss rate curve suggests that Ethereum’s current infrastructure can comfortably handle the pre-Fusaka baseline and the 10/15 parameters of the first override, but is starting to push past 16 blobs.
This creates a risk profile: as layer 2 activity increases and regularly pushes blocks to the maximum of 21 blobs, the network may experience increased miss rates that compromise finality and reorg resistance.
Demand patterns provide another signal. Average blob usage drops after the first transfer despite increased capacity, indicating that layer 2 combinations are not currently limited by blob availability.
Either their transaction volumes haven’t grown enough to need 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 take advantage of new headroom.
The pre-Fusaka concern was that limited blob capacity would hinder Layer 2 scaling and keep addition costs high as networks competed for scarce data availability. Fusaka has addressed the capacity constraint, but the bottleneck appears to have shifted.
Rollups aren’t filling the available space, which means demand hasn’t arrived yet or other factors like sequencer economics, user activity, and cross-rollup fragmentation are limiting growth more than blob availability.
What comes next
Ethereum’s roadmap includes PeerDAS, a more fundamental redesign of data availability sampling, which would further expand blob capacity while improving decentralization and security properties.
However, Fusaka’s results suggest that raw capacity is not the binding constraint at this point.
The network has room to grow to the 14/21 parameters before another expansion is needed, and the reliability curve at high blob numbers indicates that infrastructure upgrades may need to catch up before capacity increases again.
The missrate data provides a clear boundary condition. If Ethereum increases capacity while 16+ blob blocks are still experiencing high miss rates, it risks introducing systemic instability that could emerge during high demand periods.
The safer path is to ramp usage toward the current goal, monitor whether miss rates improve as clients optimize for higher blob loads, and adjust parameters only once the network demonstrates that it can reliably handle edge cases.
Fusaka’s effectiveness depends on the benchmark. It successfully expanded capacity and stabilized blob prices through the reserve floor. It did not provide an immediate increase in usage or address reliability issues at maximum capacity.
The upgrade created room for future growth, but whether that growth will materialize remains an open question that the data has not yet answered.