Ethereum activated the Fusaka upgrade on 12/3/2025, significantly expanding the network's data availability capacity through the Blob Parameter Overrides mechanism. This mechanism allows gradual adjustment of the target and maximum cap of blobs—compressed transaction data packets uploaded by layer-2 rollups to Ethereum to ensure security and finality.
The two subsequent adjustments increased the blob target per block from 6 to 10, then to 14, while the maximum cap was raised to 21. Fusaka's core goal is to reduce costs for rollups by increasing throughput for blob data.
However, after three months of data collection, results show a clear gap between technical capacity and actual usage levels. MigaLabs' analysis of over 750,000 slots since Fusaka's activation indicates the network has not yet reached the goal of 14 blobs per block.
Notably, median blob usage even decreased after the first parameter adjustment. Blocks containing 16 or more blobs have a significantly higher miss rate, indicating network reliability declines as it approaches the new capacity limit.
The report's conclusion is quite straightforward: blob parameters should not be increased further until the miss rate in blocks with many blobs returns to normal levels and actual demand justifies filling the capacity created.
What did Fusaka change and when
Before Fusaka, per EIP-7691, Ethereum aimed for 6 blobs per block with a maximum cap of 9. The Fusaka upgrade introduced two consecutive Blob Parameter Override adjustments.
The first was activated on 12/9/2025, increasing the target to 10 and the cap to 15. The second occurred on 01/7/2026, further raising the target to 14 and the cap to 21.
Ethereum's Fusaka upgrade roadmap shows blob parameters increasing from the basic 6/9 to 12/15 and then 14/21 between December 2025 and January 2026. These changes do not require a hard fork, allowing Ethereum to adjust capacity via client coordination rather than protocol upgrades.
MigaLabs' analysis, with reproducible source code and methodology, tracks blob usage and network performance throughout this transition. Results show the median number of blobs per block decreased from 6 to 4 after the first override, despite overall capacity expansion. Blocks with 16 or more blobs are extremely rare, occurring only 165 to 259 times across the entire observation period.
In other words, the network has room for growth but has not yet fully utilized it.
The report also points out an inconsistency: the timeline states that the first override increased the target from 6 to 12, while Ethereum Foundation's mainnet announcements and client documentation confirm the increase was from 6 to 10. This analysis uses the official parameters from Ethereum Foundation, while empirical data on usage and miss rates from MigaLabs serve as the basis for interpretation.
Sharp increase in miss rate for blocks with many blobs
Network reliability is measured via missed slots—blocks that are not propagated or validated correctly—showing a very clear trend.
At low blob counts, the miss rate hovers around 0.5%. When blocks contain 16 or more blobs, the miss rate rises to between 0.77% and 1.79%. At the cap of 21 blobs, after the second override, the miss rate reaches 1.79%, more than three times the baseline.
Analysis across blob levels from 10 to 21 shows a gradually increasing reliability curve, becoming more pronounced beyond the target of 14 blobs.
This is especially important because it indicates that Ethereum's current infrastructure—including validator hardware, network bandwidth, and attestation timing—struggles to handle high-capacity blocks.
If future demand surges and frequently pushes blocks near the 21-blob cap, high miss rates could lead to delayed finality or increased reorg risk. The report considers this a stability boundary: the network can technically handle many blobs per block, but maintaining that reliably and stably remains uncertain.
Error rates remain below 0.75% for blocks with fewer than 16 blobs but rise above 1% at higher blob counts, reaching 1.79% at 21 blobs.## Blob economics and the role of reserve price
Fusaka not only expanded capacity but also changed blob pricing mechanisms via EIP-7918, which introduced a reserve price to prevent blob auction prices from collapsing below 1 wei.
Previously, when demand was low and execution costs dominated, the base fee for blobs could spiral toward zero, rendering price signals meaningless. Meanwhile, layer-2 rollups pay blob fees to upload transaction data to Ethereum, and these fees are expected to reflect computational costs and network load caused by blobs.
When fees approach zero, the economic feedback loop breaks, encouraging capacity consumption without proportional costs, and obscuring actual demand signals. The reserve price in EIP-7918 links blob fees to execution costs, ensuring that even in low-demand scenarios, prices serve as meaningful economic signals. This helps prevent free-rider behavior and provides clearer data for future capacity expansion decisions.
Initial data from Hildobby's Dune dashboard shows blob fees stabilized after Fusaka, rather than continuing a sharp decline seen in previous phases. The average blobs per block also support MigaLabs' conclusion that usage has not yet increased enough to fill the new capacity.
Blob transaction fees peaked at over $2 million at the start and end of 2024 before gradually decreasing throughout 2025, remaining low in 2026.## How effective is Fusaka?
Technically, Fusaka has succeeded in expanding capacity and demonstrated that the Blob Parameter Override mechanism can operate without contentious hard forks. The reserve price also appears effective, preventing blob fees from becoming economically meaningless.
However, usage remains below capacity, and reliability declines sharply at the upper edge of the new capacity. The miss rate curve indicates that current infrastructure handles pre-Fusaka levels and the 10/15 parameters after the first override well but begins to strain beyond 16 blobs.
This creates a clear risk profile: if layer-2 activity spikes and consistently pushes blocks near the 21-blob cap, the network could face high miss rates, impacting finality and reorg resistance.
Conversely, the decrease in median blob count after the first override, despite capacity expansion, suggests rollups are not yet limited by blob availability. Their transaction volumes may be too small, or they might be optimizing compression and batching to fit current capacity rather than expanding usage.
Data from Blobscan also shows individual rollups maintaining relatively stable blob counts over time, rather than rapidly exploiting the newly available excess capacity.
Next steps for Ethereum
The Ethereum roadmap still includes PeerDAS, a deeper redesign of data availability sampling to expand blob capacity while improving decentralization and security.
However, results from Fusaka indicate that gross capacity is not the main bottleneck. The network still has room to grow within the 14/21 range before further expansion is needed, while high blob-level miss rate data suggests infrastructure upgrades are also necessary.
A safer approach is to let usage gradually approach the current target, monitor whether miss rates improve as clients and validators optimize for higher blob loads, and only adjust parameters when the network demonstrates stable handling of edge cases.
Fusaka has created space for future growth and stabilized blob economics, but has not yet triggered a usage surge or fully addressed reliability challenges at maximum capacity. Whether this capacity will be fully utilized remains an open question, as current data cannot definitively answer it.
Shach Sanh
