Ethereum’s Glamsterdam upgrade is slowly taking shape, and the discussions inside ACDC 170 gave the clearest picture yet of what this next major release might include. With Fusaka about to activate on mainnet, developer attention has fully shifted to defining Glamsterdam’s boundaries, resolving design disagreements, and deciding which upgrades should be delayed to Heka Bogotá instead.

Several proposals were removed, others remain under review, and a few have already been earmarked for the next fork. This article takes you inside the decisions, the debates, and the tensions that shaped the upcoming upgrade.

• What Glamsterdam Already Knows About Itself
• Proposals Removed from Glamsterdam
• Proposals in Discussion for Glamsterdam
• What Will Lock the Fork
• What This Means for Node Operators and Stakers

What Glamsterdam Already Knows About Itself

Over the past few months, the ambition behind Glamsterdam grew rapidly. At one stage it seemed to risk becoming a “kitchen sink” fork that tried to package too many major changes at once.

But ACDC 170 marked a shift in tone. Developers, now looking at the bigger picture, focused on reducing unnecessary complexity and ensuring the fork remains safe and manageable.

Several proposals that once seemed like possible candidates for inclusion were reconsidered. The ecosystem has become more cautious about overloading a single release, especially with ePBS already on the table.

Through this lens, the call was not just about choosing features, but about restoring clarity to the upgrade process.

Proposals Removed from Glamsterdam

Three proposals were decisively removed from Glamsterdam’s scope.

• The first was FOCIL, an upgrade designed to reduce upload bandwidth for validators under ePBS. FOCIL is popular within the community, especially among home stakers, but developers concluded that adding it now would overcomplicate the release.

Instead, it was marked DFI for Glamsterdam and CFI for Heka Bogotá, with a future possibility of SFI depending on Execution Layer input. The intention is not to abandon FOCIL, but to ensure it receives the deliberate focus a feature of its size deserves during the Heka planning cycle.

• Next was EIP-8071, which originally aimed to address a consolidation related issue in validator queues. After further review, developers recognized that cleaner, more targeted alternatives exist.

As a result, 8071 was removed and its problem space handed off to 8061 and 8080.

• The third to be dropped was EIP-8062, the proposal for a small fee on 0x01 sweep withdrawals. While the idea was designed to encourage consolidation toward 0x02 validators, it raised concerns among staking providers, solo stakers, and protocols that rely on predictable payout patterns.

Developers agreed that improving the UX of 0x02 validators must come before any economic incentives or penalties. For now, 8062 will not be part of Glamsterdam.

These removals did more more than reduce fork load. They helped narrow the focus of the upgrade and gave developers a clearer sense of which ideas need more time and which can safely wait for Heka.