Ethereum core developers came together with two parallel priorities shaping the direction of the network’s next upgrades. The first centered on Glamsterdam, where discussions focused on devnet readiness, ePBS stability as a gating factor, and emerging issues around gas accounting and execution layer coordination that continue to influence rollout timelines.

The second thread shifted attention to Hegota, where the focus is now on defining the future of Account Abstraction. With frame transactions moved to a non headliner position, developers are keeping the design space open while evaluating alternative approaches such as Wallet Title Deeds and broader AA proposals before narrowing down the final upgrade direction.

• Glamsterdam Updates
• Hegotá Updates
• Miscellaneous Updates

Glamsterdam Updates

Glamsterdam continues to take shape as a technically dense upgrade, with execution layer improvements, devnet experimentation, and dependency heavy decisions defining its trajectory. The rollout strategy for Glamsterdam is now tightly coupled with the stability of ePBS devnets. If ePBS reaches acceptable stability thresholds, developers plan to proceed with Glamsterdam Devnet 0, followed quickly by Devnet 1 incorporating gas repricing changes.

If not, the fallback path shifts toward a separate BAL Devnet 4 focused on stability fixes and dynamic cost adjustments. Glamsterdam Devnet 3 has been launched, but not without challenges. Developers have identified gas accounting edge cases that require deeper analysis, particularly around how execution costs are calculated in evolving network conditions.

At the same time, EIP-8037 continues to raise open questions, especially regarding spillover gas and state refund behavior. The ePBS devnet environment has also exposed instability. Reports of consensus bugs, peering issues, and client disconnections underline the complexity of integrating proposer builder separation at the protocol level.

Parallel to these testing efforts, gas repricing is emerging as a major theme. Proposed changes are expected to enter early testing in Devnet 0 and stabilize in Devnet 1. Another major area of progress lies in Engine API changes. Developers are working toward allowing zero values for safe and finalized block hashes during checkpoint sync, enabling more flexible node bootstrapping from non finalized states.

Additionally, support for reorganization to an ancestor block is being introduced, ensuring that execution layer clients can better handle reorg scenarios. This becomes especially important in the context of ePBS where payload flexibility increases. There is also a growing push to rethink block status labeling. The potential deprecation of the safe block tag in favor of justified and confirmed reflects an effort to bring execution layer terminology closer to consensus layer realities.

On the performance side, SSZ over REST is being proposed for the Engine API, aiming to improve serialization efficiency and reduce overhead in communication between clients. Beyond technical changes, governance discussions are also gaining importance. A new proposal to clarify the definition of Scheduled for Inclusion or SFI aims to standardize how EIPs move into upgrades. This becomes critical as Ethereum scales and upgrade scope becomes more complex.

Hegotá Updates

Hegota is shaping up as a more exploratory upgrade, particularly around Account Abstraction and its long term direction within Ethereum. One of the clearest decisions so far is that frame transactions have been classified as a non headliner feature.

Rather than being a central upgrade focus, they are now positioned as a placeholder to help guide the broader Account Abstraction direction. This decision reflects a cautious but deliberate strategy.

Account Abstraction is widely recognized as a critical step toward improving user experience and wallet flexibility, but it also introduces deep architectural challenges. Instead of rushing toward a single solution, developers are keeping the design space open.

Non headliner proposals for Hegota are currently open, with no strict deadline. However, developers have committed to providing at least two weeks notice before finalizing decisions. Within this broader exploration, multiple proposals are being discussed.

Antonio Sanso has continued to push forward discussions on Account Abstraction design considerations, while Ben Adams has introduced an alternative approach through ERC-8221, also referred to as Wallet Title Deeds.

This proposal takes a different path compared to existing frameworks like ERC-4337. Instead of relying on separate infrastructure, it uses NFTs to represent wallet ownership, enabling features like key rotation without requiring major protocol changes.

However, this approach is not without limitations.

• It does not support alternative signing schemes out of the box, meaning additional changes at the transaction level would be required. This highlights a recurring challenge in Account Abstraction design.
• Another critical issue being discussed is compatibility. Native Account Abstraction approaches may conflict with Ethereum’s push toward statelessness and proposals like FOCIL. Without specific constraints, integrating these systems at the protocol level could introduce unintended complexity.
• There is also a practical layer to consider. Frame transactions may require centralized relayers or gas account systems to function effectively. This introduces trade offs between decentralization and usability.

To move these discussions forward, a dedicated Account Abstraction breakout call is being planned, with coordination already underway.

Miscellaneous Updates

One of the most important discussions centers around history pruning. Developers are converging on a minimum history requirement of around one month, ensuring nodes retain enough recent data while reducing long term storage burdens.

This sits alongside existing benchmarks such as EIP-4444, which proposes a one year history limit, and shorter windows like the 18 day weak subjectivity period and blob expiry timelines. Together, these efforts reflect Ethereum’s push toward a more sustainable data model.

Another key area of development is the introduction of new RPC capabilities. A proposed method called eth capabilities would allow nodes to expose their effective pruning policies, giving developers and users better visibility into how data is managed across the network.

This could be extended further through optional admin capabilities, enabling clients to share more detailed configuration information. While not part of the core specification, such features could improve debugging and interoperability.

SSZ integration into the Engine API is also being explored, building on earlier discussions. By standardizing serialization formats, Ethereum can improve efficiency in how data is exchanged between layers. Glamsterdam is stress testing execution layer coordination, Hegota is exploring the future of user abstraction, and broader updates are reshaping the network’s data and infrastructure layer.

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.