Ethereum core developers moved EIP-7892, the proposed mechanism for Blob Parameter Only hard forks, to “Scheduled for Inclusion” in the Fusaka network upgrade during the All Core Developers Consensus call on April 17, 2025. They also placed EIP-7917, a deterministic validator-proposer lookahead, in the less-committed “Considered for Inclusion” category.
The decision mattered because it converted blob-only scaling from a feature under consideration into work that Ethereum client teams intended to implement for the upgrade following Pectra. It did not activate new rules, increase blob capacity or guarantee that either proposal would reach mainnet unchanged.
A narrower way to increase capacity
Ethereum introduced blobs as temporary data containers for rollups through the Dencun upgrade in March 2024. Rollups use that separate data market to publish information needed to reconstruct and verify their activity without placing all of it in ordinary Ethereum transaction calldata.
EIP-7892 proposed specialized forks that would change blob-capacity parameters through coordinated configuration updates without packaging unrelated protocol changes into each fork. The April 17 discussion settled on representing the schedule in client configuration as records containing an activation epoch and a maximum blob count. Developers agreed not to add a command-line override at that stage, favoring updated configuration releases when a scheduled adjustment needed to be changed or canceled.
That mechanism was intended to complement Peer Data Availability Sampling, or PeerDAS, the main consensus-layer scaling feature planned for Fusaka. PeerDAS was being designed so nodes could verify sampled portions of rollup data rather than every node downloading every complete blob. If that system performed safely, smaller parameter-only forks could provide a way to raise capacity incrementally after observing network conditions.
The institutional significance was therefore operational rather than immediately economic. Ethereum’s upgrade process ordinarily requires specifications, multiple independent client implementations, devnets, public testnets and coordinated activation. EIP-7892 sought to reduce the scope of later capacity adjustments, but it did not remove the need for client agreement, testing or node-operator coordination.
What the inclusion labels meant
Ethereum’s upgrade-process terminology separated proposals by commitment. “Scheduled for Inclusion” meant client teams were committing engineering resources to implement a proposal for the named upgrade. It was stronger than “Considered for Inclusion,” which authorized continued evaluation without guaranteeing implementation. Features could still be removed if testing revealed excessive risk, complexity or delay.
That distinction applied directly to the April 17 outcome. EIP-7892 joined PeerDAS in Fusaka’s scheduled consensus-layer scope. EIP-7917 received only considered status, and the call record described support as limited enough that it could be dropped at the first sign of complications. The latter proposal sought to make the next validator-proposer schedule predictable from beacon-chain state, supporting systems such as based preconfirmations while changing consensus-state handling.
Other consensus proposals discussed for Fusaka were moved out of active consideration. That narrowing reflected a preference to protect delivery of PeerDAS rather than expand the upgrade with every technically desirable feature.
Pectra remained the immediate milestone
Fusaka planning was occurring before Pectra had reached mainnet. The April 17 call retained Pectra’s previously selected activation at epoch 364032 on May 7, 2025, at 10:05:11 UTC. Client teams were aiming to publish compatible releases by April 21 and an Ethereum Foundation announcement by April 23. Those dates were planning targets recorded on April 17, not completed milestones.
Developers also discussed preparing Fusaka’s first combined development network around May 20 using PeerDAS testing work and the blob-only mechanism. That was a tentative engineering target rather than a public-testnet or mainnet commitment.
The defensible event-day conclusion was narrow: Ethereum developers had committed to implementing a mechanism for incremental blob-capacity forks while keeping most of Fusaka’s additional consensus scope provisional. No reviewed evidence establishes an April 17 change in Ethereum capacity, rollup fees, ether’s price or measured network throughput.
The complete source packet and revision history are retained with the newsroom record.
Automated systems may have assisted with source organization and drafting. Coinburn is accountable for the published text and maintains a revision record.
This article provides news and analysis, not investment, legal or tax advice. Digital assets are volatile and may result in total loss.