Ethereum core developers continue refining the roadmap for the next major protocol upgrades, with recent discussions heavily focused on Glamsterdam and Hegotá. The conversations covered devnet progress, gas limit ambitions, execution-layer scalability, Engine API changes, deep reorg handling, SELFDESTRUCT debates, and multiple EIP proposal transitions across SFI, CFI, and proposed stages.

Several proposals also moved forward in the governance pipeline as client teams prepared for broader implementation and testing phases.

• Glamsterdam Updates
• Hegotá Updates

Glamsterdam Updates

Ethereum developers spent most of the discussion cycle focusing on Glamsterdam-related engineering work. Devnet testing continues to expand rapidly as teams evaluate the feasibility of larger gas limits, execution-layer optimizations, and multiple new EIPs expected to shape Ethereum’s next phase of scalability.

One of the major highlights was the continued rollout of Glamsterdam devnets. Developers confirmed that glamsterdam-devnet-0 through glamsterdam-devnet-3 have already launched, with glamsterdam-devnet-2 specifically integrating EIP-8061 into testing environments. Alongside this, bal-devnet-6 was reported stable with Lighthouse and Lodestar support, while bal-devnet-7 is expected to launch soon with fixes for EIP-8037 and additional optimizations merged from earlier devnets.

A large portion of the engineering discussions revolved around EIP-8037 and gas accounting complexities discovered during devnet testing. Client teams identified multiple inconsistencies in gas calculations between implementations, creating the need for stronger debugging tools and more transparent gas accounting visibility. Developers discussed whether transaction receipts should include additional gas accounting data or whether dedicated debugging endpoints would provide a cleaner solution.

A proposal for a debug_getBlockReceipts endpoint gained attention as a potential approach to simplify cross-client debugging. The issue becomes increasingly important as Ethereum moves toward significantly larger gas limits where even small accounting mismatches could create serious interoperability issues between clients.

The gas limit discussion itself became one of the most important topics under Glamsterdam. Core developers are targeting a 200 million gas floor, a massive increase compared to Ethereum’s earlier operating ranges. While the increase could improve throughput and scalability, it also exposes several bottlenecks within the protocol’s current architecture.

One of the biggest concerns involves validator deposits. Without restrictions, extremely high gas limits could allow blocks containing more than 8,192 deposits, creating payload sizes that consensus-layer clients struggle to decode reliably. This led to extensive conversations around EIP-8254, which proposes capping deposit requests per block.

Developers noted that historical data shows Ethereum rarely sees blocks with more than 1,000 deposits, making an explicit cap appear practical from an operational perspective. However, the exact limit remains debated. Some discussions referenced a possible maximum of 512 deposits per block to reduce execution complexity and maintain predictable payload behavior.

The proposal is now viewed as critical for enabling Ethereum’s long-term gas expansion goals. Without deposit limits, larger gas targets may introduce instability at the consensus layer, especially during periods of unusually high validator activity.

Beyond gas scaling, developers also explored Ethereum’s ability to survive deep chain reorganizations without triggering client resynchronization. Current discussions propose a minimum reorg depth target aligned with the inactivity leak period of roughly 38 days.

This requirement is intended to ensure that execution-layer clients can recover from deep chain reorganizations while maintaining operational continuity. Geth reportedly already supports reorganizations approaching 90,000 blocks, but several other clients still require significant engineering work to reach similar capabilities.

The issue is particularly important for Ethereum’s long-term resilience assumptions. Developers acknowledged that reorg handling standards should likely have been clarified earlier in Ethereum’s lifecycle, but increasing network complexity now makes standardized expectations necessary.

To support this effort, contributors are preparing Hive tests specifically designed for deep reorg scenarios. These tests will help validate how different clients behave under extreme chain recovery conditions and identify compatibility gaps before future upgrades are finalized.

Another major Glamsterdam topic centered around Ethereum governance processes themselves. Developers finalized a revised interpretation of SFI status after earlier confusion around whether devnet inclusion alone should qualify an EIP for SFI progression.

The older definition often created situations where EIPs technically qualified for SFI status despite not being operationally ready. The revised approach attempts to make SFI more descriptive rather than functioning as an automatic progression trigger.

As part of these governance updates, multiple EIPs moved into SFI status for Glamsterdam, including:

• EIP-7708
• EIP-7778
• EIP-7843
• EIP-7954
• EIP-7976
• EIP-7981
• EIP-8024
• EIP-8037

Developers emphasized that future upgrade planning may increasingly rely on priority-based implementation lists instead of simple inclusion rules tied to devnet activity. Meanwhile, discussions around EIP-8070 also advanced following the merge of related Engine API changes. The proposal focuses on sparse blobpool functionality and required updates after changes were merged into Ethereum’s execution APIs.

Engine API compatibility became another important area of focus. A schema-only fix for Engine API v2 was proposed to align its behavior with Osaka specifications and existing v3 encoding standards. While the fix itself was relatively small, developers highlighted that Engine API modifications require explicit coordination because they cannot simply be discussed through standard RPC channels.

Another heavily debated topic involved Ethereum’s long-running SELFDESTRUCT cleanup efforts. EIP-8246 proposes removing the SELFDESTRUCT burn behavior, and developers confirmed growing support for the idea. However, fully removing the SELFDESTRUCT opcode itself appears unlikely to fit within the Glamsterdam scope due to the complexity of backward compatibility concerns and implementation risks.

The conversation highlighted how Ethereum’s protocol cleanup efforts are becoming increasingly delicate as older EVM assumptions remain deeply embedded across infrastructure, tooling, and smart contracts. While developers continue pushing toward a simplified execution environment, they also acknowledged that aggressive removals require careful coordination to avoid ecosystem disruption.

The proposal was ultimately moved to CFI status for Glamsterdam, while broader opcode removal discussions will likely continue into future upgrade cycles. Developers also assigned several action items to move discussions forward. Stefan Starflinger will work on specifications for improved gas debugging endpoints, Toni Wahrstätter will update EIPs covering deep reorg standards, and Jochem Brouwer alongside Mario Vega will prepare Hive tests for reorg simulations.

Hegotá Updates

While Glamsterdam dominated most technical discussions, developers also began shaping the direction of Hegotá, Ethereum’s likely follow-up upgrade cycle. One of the most notable proposals discussed for Hegotá was EIP-7709, which introduces a mechanism for reading BLOCKHASH values directly from storage while updating associated costs.

The proposal attempts to simplify execution witness construction and improve state access efficiency. Developers noted that the current version of the EIP had become somewhat outdated, leading to a refreshed revision intended to modernize the proposal and address concerns raised during earlier reviews.

Beyond its technical details, EIP-7709 represents part of a broader trend toward simplifying Ethereum’s execution-layer data access patterns. By moving historical blockhash access into storage-oriented workflows, developers hope to improve witness generation and reduce some complexities surrounding state reconstruction.

The proposal has now moved into proposed status for Hegotá, indicating growing interest among client teams and contributors. Another proposal discussed for Hegotá was EIP-8253, which focuses on removing pre-Spurious-Dragon accounts from Ethereum’s state.

The proposal is viewed as a long-term cleanup initiative targeting legacy account structures that remain from older stages of Ethereum’s history. Developers described the idea itself as relatively straightforward despite the size of the associated pull request. EIP-8253 is also being evaluated as either a follow-up or alternative to EIP-7610, which handles contract creation reversion scenarios involving non-empty storage.

Together, these discussions highlight Ethereum’s growing emphasis on state simplification and protocol maintenance. As Ethereum matures, developers increasingly appear willing to revisit older design assumptions and remove historical baggage that may no longer justify its operational complexity.

Account abstraction discussions also appeared briefly during Hegotá conversations. While detailed implementation updates were limited, contributors acknowledged ongoing coordination around AA-related improvements and their relationship to future upgrade planning.

The Hegotá discussions overall remained smaller in scope compared to Glamsterdam, but they offered an early glimpse into Ethereum’s longer-term priorities beyond immediate scalability goals. Another recurring theme involves Ethereum’s gradual state simplification efforts. Proposals targeting old accounts, SELFDESTRUCT behavior, and historical state assumptions all point toward a future where Ethereum’s protocol surface becomes cleaner and easier to maintain.

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.