Two Forks Per Year: Can Ethereum Really Do It?

ACDC #170 was expected to be a straightforward checkpoint on the road to finalizing the Glamsterdam upgrade. Instead, it opened up one of the most important process conversations Ethereum has had in a long time.

The call showed that the challenge ahead is not just about which proposals should ship. It is about whether Ethereum’s upgrade machinery itself can handle the pace the community expects.

With Fusaka approaching activation, Glamsterdam nearing its final shape, and Heka Bogotá already entering early discussion, developers found themselves working across three timelines simultaneously. This overlap exposed deeper coordination issues that will need attention if Ethereum wants to reliably ship two upgrades every year.

• The Headliner Process Breaks Down
• Why Two Forks Per Year Is Still Difficult
• The Problem of Overloaded Forks
• What Needs to Change

The Headliner Process Breaks Down

The headliner idea was created to bring clarity to upgrades by choosing one major feature early and shaping the fork around it. In theory, this should have created discipline.

In practice, during Glamsterdam, it created friction instead. The intense debate around FOCIL revealed gaps in how the process is understood across teams.

Different groups interpreted the meaning and timing of DFI, CFI and SFI signals in different ways, leading to tension and late stage uncertainty. Proposals ended up competing with each other rather than being evaluated on their own merits.

Some developers felt that important decisions were arriving too late, while others believed certain proposals had not received enough early visibility. By the end of ACDC 170, there was agreement that the headliner process needs to be simpler and more predictable.

The clearest suggestion was a two step method for Heka Bogotá. First, decide whether FOCIL is a headliner. After that, choose only one additional major feature, such as six second slots.

Why Two Forks Per Year Is Still Difficult?

Ethereum has long aimed for two major upgrades each year. On paper, this seems like a reasonable target for a global protocol, but ACDC #170 made it clear that the ecosystem is not yet organized for such a rhythm.

The overlapping timelines of Fusaka, Glamsterdam and Heka created pressure on teams who were simultaneously testing, scoping and planning three different upgrades.

Instead of a clean pipeline where one fork hands off to the next, the boundaries between cycles blurred, creating stress and slowing decision making. Developers acknowledged that this situation could not continue if twice yearly upgrades are to become the norm.

The root of the problem lies in weak pipelining. Ethereum’s upgrade process has traditionally followed a linear pattern where one fork is finalized before the next is scoped. In reality, large features are interconnected, and decisions in one fork inevitably influence the next.

This causes scoping delays and encourages late debates. ACDC #170 showed that Ethereum needs a more modern workflow in which the next fork is partly defined before the current one finishes, and the fork after that already has a preliminary set of headliners.

The Problem of Overloaded Forks

Another challenge the call highlighted is the recurring issue of overloaded releases. When too many changes are bundled into one fork, risks increase, testing becomes complicated, and timelines become unpredictable.

Developers agreed that earlier forks attempted to solve too many problems at once, slowing the entire upgrade cycle. Glamsterdam benefited from deliberate pruning, which removed FOCIL, EIP-8071 and EIP-8062.

What Needs to Change

ACDC #170 highlighted exactly what Ethereum must fix to reach a reliable twice yearly upgrade cadence. Fork scoping needs to begin earlier, and headliners must be selected with enough lead time to prevent last minute conflicts.

Forks must remain lighter and more predictable so that testing remains manageable. Cross fork dependencies must be acknowledged rather than ignored, especially for features like ePBS.

Execution Layer and Consensus Layer coordination must improve to avoid situations where major decisions stall due to misalignment. Finally, a stronger incident response culture, demonstrated by Fusaka’s preparedness, should become standard across all upgrades.

The lesson from ACDC #170 is clear. Ethereum has the engineering talent and community determination to ship two forks per year, but the current process is not yet optimized for that speed.

By reforming the headliner process, improving pipelining, and keeping forks intentionally lightweight, Ethereum can move toward a more reliable upgrade rhythm. Glamsterdam marks the beginning of this shift, but the true measure of progress will come with Heka Bogotá.

If you find any issues in this blog or notice any missing information, please feel free to reach out at yash@etherworld.co for clarifications or updates.

Related Articles

1. Ethereum Launches $2 Million Fusaka Audit Contest to Fortify Protocol Security
2. Ethereum Developers Announce "The Weld" Repository Merger
3. Ethereum Developers Target September 22 for Holesky Client Releases
4. Ethereum Developers Face Blockers in Shadowfork Testing Ahead of Fusaka
5. A New Playbook for Ethereum: Fusaka Rethinks Testnet & Mainnet Schedules