Community feedback on non-headlining features in Glamsterdam

EIPs
1

Glamsterdam is the Ethereum upgrade that will follow Fusaka and is estimated for a release in 2026. The headlining features for this fork, chosen by community consensus, are enshrined Proposer Builder Separation and Block-level Access Lists.

The non-headlining features for this fork are now being chosen from the list of features proposed prior to the Oct 30th deadline. These features will be ones that are smaller in scope and don’t significantly delay the implementation of the selected headlining features.

Client teams, who generally have the most context for which features are compatible with headliners and each other, are asked to publish their opinions on which features to include. These opinions will be posted on Forkcast when available.

However, it’s crucial that core developers understand the extent to which some of these features impact various Ethereum communities, especially when there’s overwhelming need for a feature that may not be as visible in core development communities. This form is an opportunity for this support to be organized and voiced ahead feature selection.

If you’d like to share your opinion on feature inclusion, please fill this out - the feedback will be aggregated and presented in an upcoming All Core Dev call.

Proposed EIPs: Glamsterdam - Forkcast

1. What stakeholder category do you represent?

2. Which of the proposed EIPs would have a meaningful impact on your community / your work? Please elaborate on why.

3. Does anything make any of these EIPs particularly urgent for community / your work?

4. Do you have any unaddressed concerns about any of the proposed EIPs?

5. Any additional comments?

Your EIP ranking:

2 Likes
2

1. What stakeholder category do you represent?

Wallet devs / payments infra

2. Which of the proposed EIPs would have a meaningful impact on your community / your work? Please elaborate on why.

7708 will dramatically reduce the cost/complexity of capturing & communicating token/value flows to users

3. Does anything make any of these EIPs particularly urgent for community / your work?

n/a

4. Do you have any unaddressed concerns about any of the proposed EIPs?

n/a

5. Any additional comments?

n/a

1 Like
3

1. What stakeholder category do you represent?

Community education

2. Which of the proposed EIPs would have a meaningful impact on your community / your work? Please elaborate on why.

We should heavily use Declined for Inclusion for EIPs that don’t significantly move the roadmap forward. (See my feedback on Pectra Retrospective - #2 by abcoathup)

We should also prioritize regular shipping (ideally 2 upgrades per year) to allow fast iteration on the roadmap.

Beyond the headliners of ePBS & BALs the priority is repricing.

Based on Why we should prioritize repricings in Glamsterdam – MariusVanDerWijden recommendation we should do Crucial (7 EIPs in S-tier) and Important (3 in A-tier).

Whilst most repricing EIPs appear to be small changes, that is still 10 EIPs to test, leaving very little scope for additional EIPs.

If client & testing teams have capacity, then we could add 4 EIPs (B-tier):

  • EIP-8045 (Exclude slashed validators from proposing) - more of a bug fix
  • EIP-7949 (Genesis File Format) - improve testing
  • EIP-8062 (Add sweep withdrawal fee for 0x01 validators) & EIP-8068 (Neutral effective balance design) - remove disincentives from consolidation

3. Does anything make any of these EIPs particularly urgent for community / your work?

10 repricing EIPs + 4 potential additional EIPs is already too much, increasing upgrade complexity and risk.

For improved DX I’d like to see increased code size (though EIP-2926 in repricing should make this easier) and avoidance of stack too deep, but we can’t keep adding EIPs, so I didn’t include DX improvements.

4. Do you have any unaddressed concerns about any of the proposed EIPs?

There isn’t information on implementation effort, testing complexity (yet) or readiness, which makes it hard to compare EIPs.

Censorship resistance is important and we have a limited window to implement (in case regulatory conditions change), but an estimated additional 2 months to add FOCIL to Glamsterdam likely rules out 2 upgrades in 2026. I’d be more supportive of FOCIL as a headliner in Heka + Bogotá, especially as this gives increased time to improve readiness.

5. Any additional comments?

We need to aid EIP authors with early feedback. Does their EIP significantly move the roadmap forward, is there support from their targeted segment of the community, is there appetite from client teams to implement and what is the testing complexity.

We also need to find mechanisms to capture implementation effort, testing complexity and readiness that can be shared via EIP process/Forkcast.

Your EIP ranking:

glamsterdam-eip-rankings-abcoathup
glamsterdam-eip-rankings-abcoathup1440×960 206 KB

1 Like
4

1. What stakeholder category do you represent?

Solo-stakers via the Stakers Union

2. Which of the proposed EIPs would have a meaningful impact on your community / your work? Please elaborate on why.

Stakers Union has formally voted to support EIP-7805: Fork-choice enforced Inclusion Lists (FOCIL) for inclusion in the next Ethereum network upgrade, Glamsterdam. We believe FOCIL measurably improves censorship resistance, reduces builder centralization risk, and strengthens solo-validator sovereignty without adding undue operational burden to home stakers.

3. Does anything make any of these EIPs particularly urgent for community / your work?

Home validators are the backbone of credible neutrality. FOCIL restores meaningful leverage to validators (not just builders) in the inclusion pipeline. That aligns with our mission to keep Ethereum open to small operators and resilient to policy or profit-driven filtering.

2 Likes