Glamsterdam at Crossroads: What’s In, What’s Out & What’s Still Uncertain

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.

Proposals in Discussion for Glamsterdam

Although several proposals were dropped, the validator queue discussion is far from over. Glamsterdam must include at least one fix for queue and churn behavior, but developers are still weighing the tradeoffs between EIP-8061 and EIP-8080.

EIP-8080 offers a simple improvement by allowing the consolidation queue to support exits when needed. It is elegant, narrow, and easy to test. EIP-8061 expands on this by modifying churn parameters and adjusting exit behavior in more significant ways. While 8061 may provide a broader improvement, it touches on weak subjectivity and requires more analysis before being considered safe for inclusion.

Developers did not want to rush this decision. Instead, they will revisit it in the next ACDC once client teams and researchers complete a more thorough review of 8061’s implications. The key takeaway is that Glamsterdam will include a queue fix, but the final choice remains open.

Another proposal still under consideration is EIP-8045, which would prevent slashed validators from proposing new blocks. This is especially valuable during mass slashing events where many scheduled proposers fail to produce blocks, harming the network’s liveness.

At first glance, 8045 seems straightforward, but the deeper technical concerns lie in how clients determine the proposer set. The proposal interacts with state caching and lookahead logic, and inconsistencies could cause clients to diverge.

Developers agreed to keep 8045 in a CFI position for now, but it will remain conditional on further analysis. If any safety issues arise, it will be removed before Glamsterdam locks.

Stable containers, introduced by EIP-7688, aim to make SSZ data structures more flexible and future ready. Many developers like the idea because it reduces the need for repeated hard coding of container limits, making Ethereum’s internals cleaner and easier to evolve.

However, because 7688 touches SSZ encoding, client teams want a complete understanding of performance and audit needs. Until then, 7688 remains in a “leaning yes” but undecided state.

What Will Lock the Fork

Two upcoming moments will define Glamsterdam.

1. The first is the December 5 ePBS breakout, which must resolve trustless payments for the fork to proceed cleanly.
2. The second is the next ACD meeting, where developers will:

• Choose between 8061 and 8080
• Confirm or remove 8045
• Decide on 7688 after hearing from the champion
• Process the ACDE signal for FOCIL
• Finalize the headliner process for Heka

Once these decisions are made, Glamsterdam will have a fully defined scope.

What This Means for Node Operators and Stakers

While Glamsterdam is still being shaped, the direction is becoming clearer. Node operators can expect:

• ePBS to be the dominant feature
• streamlined queue improvements
• stable containers possibly entering the SSZ codebase
• a more predictable fork scope than in previous releases

For validators, especially solo stakers, the removal of 8062 and the postponement of FOCIL give them breathing room. The ecosystem now acknowledges that consolidation must be supported through better UX rather than penalties.

The trustless payments debate inside ePBS is one of the biggest reasons Glamsterdam cannot yet finalize its scope. Developers discovered at Devconnect that the design is not universally understood, especially around failure modes and economic behavior.

The December 5 ePBS breakout will determine whether the current design is ready or needs revisions. Because ePBS is the headline item of the fork, its unresolved portion prevents the entire upgrade from being locked in.

Once trustless payments are clarified, Glamsterdam’s remaining pieces can fall into place.

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