Good evening,
Tonight, I’m discussing several top-of-mind topics in Ethereum protocol development.
First, I dig into the actual status of the Glamsterdam upgrade. Despite recent headlines suggesting the upgrade has entered its “final stage,” that characterization is obviously wrong to anyone who has been following its development.
Glamsterdam is making meaningful progress, but it is still in active implementation, testing, and scope refinement. My read is that developers are roughly 60% of the way there, and I explain why below.
Second, I cover an important new discussion regarding the introduction of EIP-8282, a proposal that developers have now agreed is technically necessary for Glamsterdam but could meaningfully delay the upgrade timeline.
Finally, I address Hsiao-Wei Wang’s departure from the Ethereum Foundation and what it signals about the EF’s ongoing restructuring, its narrower role in the ecosystem, and the broader question of who will step up to fund and coordinate Ethereum protocol development going forward.
Let’s get into it.
Yours truly,
Christine D. Kim
🗒️ Call Minutes
First, a quick summary of the latest Ethereum developer call, All Core Developers Execution (ACDE) #239.
Glamsterdam devnet updates
Developers are continuing to test the Glamsterdam upgrade on Glamsterdam-Devnet-5. A full list of code changes and features being tested on the devnet is listed here.
Ethereum Foundation (EF) Developer Operations Engineer Barnabas Busa said the Prysm client team is investigating and fixing issues surfaced on the devnet. Most other client teams are preparing for the launch of Glamsterdam-Devnet-6, which is tentatively scheduled to launch mid-next week.
Glamsterdam specifications changes
Developers agreed to include Ethereum Improvement Proposal (EIP) 8282, Builder Execution Requests, in Glamsterdam.
As discussed on last Thursday’s call, this proposal would give third-party block builders their own dedicated execution-layer (EL) request contracts for deposits and exits. This removes edge cases associated with bundling builders and validators into the same queue.
Although developers did not mention it on this Thursday’s call, they highlighted on Monday during the All Core Developers Testing (ACDT) call that adding this EIP may delay the upgrade by up to three months.
Developers discussed on ACDT #83 potentially activating the EL-side of the upgrade, dubbed Amsterdam, earlier and separately from the consensus layer upgrade, dubbed Gloas.
Developers agreed to add an optional networking EIP, EIP 8189, to Glamsterdam. This proposal builds on EIP-7928, Block-Level Access Lists (BALs), and enables a BAL-based state-healing process in nodes during snap sync, enabling faster chain recovery during periods of network instability.
Developers debated a potential change to EIP-7928 that would restructure how stack overflow checks are handled in BALs to address edge cases. Half of the client teams leaned towards no changes, as the edge case is rather small and unlikely to be exploited. The other half leaned towards a redesign proposed by Dragan Rakita, a Reth client developer at Paradigm.
Developers agreed to reach a decision over the next few days so that any changes can be incorporated into testing on Glamsterdam-Devnet-6. A discussion thread for this issue has been opened on Discord.
EF Researcher Maria Silva shared updates on the Glamsterdam gas repricing EIPs. She confirmed that no gas cost repricing will be needed in Glamsterdam to reach the target throughput of 100 million gas per second. Thus, EIP-7904, which was a placeholder for general gas-cost repricing, has now been updated to an informational EIP that will not affect any protocol or client code.
Silva also mentioned various changes to other gas repricing EIPs, including EIPs 8037, 8038, and 2780, that will be included for testing on Glamsterdam-Devnet-6.
Hegota EIP Proposals
The following EIPs were proposed for inclusion in Hegota:
EIP 8304 (Trustless log & transaction index)—This EIP provides a simplified design for a trust-minimized framework to verify event logs and transaction data without relying on third-party indexing protocols or infrastructure providers.
EIP 2488 (Deprecate the CALLCODE opcode)—This EIP disables an old, mostly unused Ethereum instruction, reducing unnecessary complexity for client developers while accepting a small risk of breaking ancient contracts that still rely on it.
EIP 7645 (Alias ORIGIN to SENDER)—This EIP seeks to simplify two Ethereum instructions, ORIGIN and SENDER, for improving smart contract security and enabling future upgrades supporting native account abstraction.
Announcements
Client teams participating in Glamsterdam-Devnet-6 testing must include two new system contracts in their code to support the new addition of EIP-8282. Details for the system contracts and other specifications for Devnet-6 can be found here.
There is a 3 ETH bounty posted on Poidh for feedback on two Ethereum encrypted mempool proposals, EIP 8105 and 8184.
There is a community discussion happening on Ethereum Magicians about the emoji mascot for the Glamsterdam upgrade.
🌕 That’s all for my summary of ACDE #239. Continue reading for my insights on Ethereum development and governance. To read the rest of the newsletter, make sure you are signed up for a premium subscription:
🌓 Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for ACD After Hours:
🌑 I also run a research and advisory firm called Protocol Watch for businesses building on Bitcoin and Ethereum. Learn more about how I can help your business understand and stay ahead of protocol changes:
🔎 Insights
Glamsterdam Is Not in Its “Final Stage” Yet
On Tuesday, CoinDesk published an article headlined “Ethereum’s biggest protocol overhaul in years moves into its final development stage.” It prompted several other news outlets, including The Defiant and Unchained, to publish similar articles the following day with a similar headline.
As someone who has been tracking Glamsterdam development weekly, I found the framing surprising.
