EIP-7773: Glamsterdam Network Upgrade Meta Thread

EIPs
1

Glamsterdam Scoping Timeline

updated July 15, 2025

Following my recent post, here is how I propose we approach Glamsterdam scoping:

  1. [May 26 - June 20] Fork Focus Discussion & Headliner Proposals :white_check_mark:

    • During this period, ACD{E|C} calls should focus on discussing Glamsterdam’s high-level goals. Headliner champions should be invited to present their proposals.
    • Headliner champions must open an Ethereum Magicians thread with the glamsterdam tag at least 48 hours before the ACD call on which they wish to present, including relevant information about their proposal (see template below).
      • Note: While technical readiness is a factor, an EIP is not required at this stage. For instance, a proposal focusing on “reducing disk requirements for nodes” is acceptable even without a specific EIP.
    • The June 19th ACDE call will be the final opportunity to propose new candidate headliners, making June 17th the deadline to share new proposals on Ethereum Magicians.
    • This period should evaluate not only Core Dev preferences for the next upgrade but also broader community preferences. While ACD can provide feedback around which stakeholders should be consulted, headliner champions are responsible for gathering sufficient evidence of support.

  2. [July 17 - Aug 21] Headliner Discussion & Finalization

    • Once candidate headliners are identified, ACD will spend the next month evaluating them, soliciting community feedback, and finalizing decisions on which feature(s) to prioritize for Glamsterdam.
    • The ACD calls from July 31 to August 21 will be used to decide on the fork headliner(s)
    • Client team preferences:
    • Once we’ve settled on a headliner, the Glamsterdam Meta EIP should be updated to reflect it and articulate the rationale for the choice.

  3. [Tentatively Until Aug 21] Non-Headliner EIP Proposals

    • With the headliner Scheduled for Inclusion, ACD should begin reviewing other EIPs Proposed for Inclusion in Glamsterdam.
    • Like for Fusaka, EIP authors proposing their EIP should submit a PR against the Glamsterdam Meta EIP, following the process detailed in EIP-7723.
    • The deadline for EIPs being PFI’d for Glamsterdam should be August 21.

  4. [Sep/Oct] Non-Headliner EIP CFI Decisions

    • After the EIP proposal deadline, use the ACDC and ACDE calls to select which Proposed for Inclusion EIPs should advance to Considered for Inclusion. Remaining PFI EIPs will be Declined for Inclusion.

  5. [Date TBD] CFI → SFI EIP Decisions

    • As Glamsterdam devnets begin, make final decisions regarding which CFI EIPs will be included in the upgrade’s devnet.
Headliner Proposal Template

Headliner Proposal Template

While EIPs and Python specifications effectively describe a proposal’s technical details, they aren’t best suited to explain why a network upgrade should prioritize a specific proposal or its impact on the entire Ethereum community.

To address this, headliner champions should use the following template in their Ethereum Magicians threads to clearly articulate the proposal’s goals, impacts, risks, and readiness.

Consider this template as comprehensive but flexible. The goal is providing an optimal overview of each proposal. Champions should also update their threads to link notable community feedback or useful inputs. Here is a good historical example for EIP-1153. Another useful format is a “readiness checklist,” such as those used for The Merge or EIP-4844.

6 Likes
2

EIP: EIP-7773: Hardfork Meta - Amsterdam

1 Like
3
4 Likes
4
1 Like
5
1 Like
6
7
2 Likes
8

Thought it was important to flag that the rule about “not being able to resubmit a headliner EIP as a vanilla EIP” doesn’t seem fair.

I think it’s great to keep experimenting on new ways to ship forks faster, in a more streamlined way (e.g., the new headliner initiative EIP-7773: Glamsterdam Network Upgrade Meta Thread). But it turns out FOCIL is basically the archetype of an EIP that doesn’t neatly fit into the headliner structure because it touches both the EL and the CL, and because it is a “not too big, not too small” upgrade.

To be fair, @timbeiko pointed out it was mentioned here: “Once a feature is declined as a potential headliner, it cannot return as a regular EIP within the same fork cycle to prevent back-door reprioritization.” (Community Consensus, Fork Headliners & ACD Working Groups). But I think most people were not aware of the rule, and it still doesn’t make sense to me in practice. I also don’t think the risks of back-door reprioritization are real, if people don’t like an EIP they just wouldn’t include it in a fork either way.

A potential worst case scenario that could be considered as capture risk is an EIP that cannot be CFI’d just because it doesn’t fit into the governance process. Fork scope/complexity are both valid arguments but I wouldn’t want the process to just exclude EIPs for the sake of new/experimental rules.

4 Likes
9

In the present case of EOF, it consists of a number of EIPs, some of which are useful separately and worth introducing.

10
1 Like