Ethereum core developers gathered for the latest All Core Devs Execution call to review immediate progress on the Glamsterdam upgrade while also discussing new proposals that may shape the scope of the Hegotá fork. The call focused heavily on Glamsterdam Devnet 0 preparations, Engine API changes for deeper reorg support, and testing concerns around EIP-8037, which has emerged as one of the more complex proposals under consideration.

Alongside the immediate push toward Glamsterdam testing, developers also reviewed candidate proposals for Hegotá. EIP-8163 and EIP-7979 were both moved to proposed status, while EIP-8237 was deferred to Hegotá rather than being treated as an urgent addition to Glamsterdam. The meeting also brought organizational updates, including Nixo joining as co-lead of All Core Devs alongside Ansgar.

• Glamsterdam Updates
• Hegotá Updates

Glamsterdam Updates

The biggest immediate milestone discussed during the call was the launch of Glamsterdam Devnet 0, targeted for the next day with support from Prysm and Geth. Developers confirmed that BAL Devnet 4’s test release had already been consumed by clients, and implementation work is ongoing. This marks an important step in moving Glamsterdam from specification and proposal discussions toward practical interoperability testing.

A major technical discussion centered on Engine API changes related to execution layer reorg support. Two competing proposals were considered: PR #770 and PR #786. PR #770 would require execution layer clients to support reorgs to a head’s ancestor, while PR #786 introduces a more limited but practical alternative. PR #786 restricts the no-reorg optimization to an ancestor of the latest finalized block known to the execution layer client and introduces a “Too Deep Reorg” error for situations where the requested reorg exceeds implementation-specific capabilities.

After discussion, developers selected Engine API PR #786 for implementation. The decision was seen as a balanced compromise between functionality and implementation complexity. Execution layer client teams were asked to review both PRs and provide further feedback, especially as these changes may affect future sync and interoperability behavior.

Another major point of concern was EIP-8037. Testing teams reported that the proposal had already broken roughly 30% of tests due to changes in gas accounting and execution assumptions. The dynamic pricing model in particular was identified as the main source of complexity. Developers highlighted that deriving state gas from the block gas limit has broken test determinism, forcing widespread modifications across testing suites.

The new reservoir-based gas accounting model was also criticized for making it harder to predict and intentionally trigger out-of-gas conditions in test scenarios. Refund mechanisms introduce additional edge cases that remain insufficiently tested. Benchmark testing has also become more difficult because many existing tests rely on fixed gas assumptions that no longer hold under the proposal.

Given the scale of these issues, several developers raised strong concerns about whether EIP-8037’s complexity is justified by its benefits. The current sentiment appears to favor simplification before the proposal can move forward. EIP authors and interested teams were encouraged to explore design changes before the next call.

Developers also reviewed EIP-8237, which proposes execution witness optimization by allowing consensus layer clients to perform range sync without downloading and verifying payloads. While the proposal could improve sync efficiency, the group agreed it was not urgent enough for emergency inclusion in Glamsterdam. Instead, it was formally deferred to Hegotá for further review.

On the performance side, client teams discussed improvements for zkEVM-related Engine API performance. Geth contributors highlighted a JSON marshalling improvement PR that could deliver up to 10x performance gains in certain scenarios. This optimization may have broader implications for execution-layer efficiency as Ethereum scales and sees more zkEVM-related workloads.

Outside of protocol mechanics, developers briefly discussed the final call for a mascot for the Glamsterdam upgrade. Community suggestions included names like Ant, Beaver, Bee, Flamingo, Hamster, and Poodle. While lighthearted, these mascot discussions have become part of Ethereum’s culture around major upgrades.

Hegotá Updates

While Glamsterdam remains the immediate priority, developers also reviewed proposals for the Hegotá fork.

EIP-8163 was moved to proposed status for Hegotá. The proposal reserves opcode 0xAE for use by Layer 2 and alternative Layer 1 systems. This could help improve coordination and reduce conflicts as more ecosystems build custom functionality around Ethereum-compatible environments.

EIP-7979 was also moved to proposed status. The proposal introduces CALLSUB and RETURNSUB opcodes. These instructions have been discussed historically as a way to improve subroutine handling and potentially reduce bytecode inefficiencies. While there was enough interest to move the proposal forward, the call acknowledged that deeper technical discussion is still required. Greg Colvin was assigned to schedule a breakout call to explore the proposal further.

EIP-8237, after being discussed in the Glamsterdam section, was officially deferred to Hegotá. Developers agreed that the proposal aligns better with Hegotá’s timeline and can be evaluated there without adding immediate pressure to Glamsterdam’s already complex scope.

Overall, the Hegotá discussion reflected a broader effort to prepare the next fork in parallel without distracting from immediate Glamsterdam deliverables. By moving EIP-8163 and EIP-7979 into proposed status now, developers can begin deeper review and implementation planning while Glamsterdam testing continues.

The call ended with a few clear next steps. Glamsterdam Devnet 0 is expected to launch immediately, providing the first practical environment for testing new changes. Execution layer teams will continue reviewing Engine API changes, while EIP-8037 authors are expected to return with simplification proposals. Meanwhile, Hegotá proposal discussions will continue in parallel as Ethereum core developers balance short-term delivery with long-term roadmap planning.

Glamsterdam is moving quickly toward implementation and interoperability testing. At the same time, Hegotá is beginning to take shape as the next venue for proposals that are promising but not yet urgent. The outcome of the next few Devnets and proposal reviews will likely determine how quickly both forks advance.

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.

To promote your Web3 articles, events, and projects, you may reach out anytime via EtherWorld PR for submissions and collaboration.

Related Articles

1. Highlights of Ethereum's All Core Devs Meeting (ACDC) #153
2. Highlights of Ethereum's All Core Devs Meeting (ACDE) #207
3. Highlights of Ethereum's All Core Devs Meeting (ACDC) #152
4. Highlights of Ethereum's All Core Devs Meeting (ACDE) #206
5. Highlights of Ethereum's All Core Devs Meeting (ACDE) #205

To follow blockchain news, track Ethereum protocol progress, and read our latest stories, subscribe to our weekly today.