Ethereum core developers continue refining the roadmap for the upcoming Glamsterdam & Hegota upgrades, with recent discussions focusing on execution-layer performance, Block Access Lists (BAL), native privacy proposals, state growth management, and legacy opcode removal. During the latest All Core Devs discussions, client teams reviewed the status of Glamsterdam Devnet-4 while also evaluating several Proposed for Inclusion (PFI) candidates for the Hegota fork.

The conversations highlighted a broader theme shaping Ethereum’s roadmap in 2026 balancing scalability, protocol simplicity, privacy, and long-term sustainability without compromising decentralization or client diversity.

• Glamsterdam Updates
• Hegotá Updates

Glamsterdam Updates

Developers began by reviewing the status of Glamsterdam Devnet-4. Nethermind and Ethrex showed progress on the execution layer side, while Prysm, Lodestar, Lighthouse, and Nimbus continued consensus-layer coordination. Although the devnet was targeted for launch, teams acknowledged that remaining bugs could still delay testing.

One of the biggest discussions centered around EIP-7904, which originally proposed repricing compute-heavy operations to improve execution performance. However, recent BAL optimizations significantly changed the conversation. Developers noted that clients are now reaching nearly 100 million gas per second during benchmarks after implementing BAL-related improvements.

Several contributors argued that if BAL optimizations already solve the bottleneck, introducing additional repricing may unnecessarily complicate the protocol. Nethermind benchmark results were considered promising, while teams are still awaiting final confirmation from Geth before making a decision. If similar performance is confirmed, the proposal could potentially be removed or deferred from Glamsterdam.

Another major topic involved EIP-7702 and Block Access Lists. Developers reviewed an edge case involving delegation addresses and validation checks. Under the updated logic, delegation addresses are only added after gas checks, balance validation, and stack-depth verification pass successfully.

The updated specification and tests have already been merged, although the BAL adjustment itself was deferred from Glamsterdam Devnet-4 due to timing concerns. Client teams agreed further coordination is required before activation across all implementations.

BAL continues emerging as a key optimization effort for Ethereum’s execution layer. The proposal aims to improve state access efficiency while reducing transaction processing overhead. Developers repeatedly emphasized the importance of standardized BAL behavior across clients to avoid consensus inconsistencies later.

Teams also reviewed execution API standardization, including JSON-RPC compatibility, debug metrics, and whether certain APIs should eventually become part of formal specifications rather than remaining client-specific implementations.

While these discussions may appear small compared to major hard fork features, they remain critical for ecosystem interoperability. Wallets, infrastructure providers, rollups, and tooling platforms all depend on predictable client behavior.

Hegotá Updates

While Glamsterdam discussions focused heavily on execution optimization, Hegota conversations explored deeper protocol-level challenges around privacy, state growth, and Ethereum’s long-term sustainability. One of the most ambitious proposals discussed was EIP-8188, which introduces state tiering based on write age.

The proposal aims to reduce Ethereum’s long-term database burden by separating frequently accessed “hot” state from older “cold” state. The system introduces metadata tracking for accounts and storage slots, allowing clients to identify how recently state entries were modified.

Prototype testing reportedly showed up to 78% database reduction, making the proposal particularly important for long-term node sustainability. Supporters argued that Ethereum’s growing state size remains one of the protocol’s biggest long-term challenges. State tiering could reduce storage pressure without sacrificing accessibility.

However, developers also raised concerns around metadata overhead, write amplification, and unpredictable gas costs for users interacting with inactive accounts. Questions were also raised around archival strategies, RLP encoding changes, and whether read metadata should influence state tiering as well.

Although still in early stages, many developers acknowledged that Ethereum will eventually require more advanced state management systems to remain sustainable. Another major discussion involved EIP-8182, which proposes private ETH transfers through an enshrined shielded pool system contract.

The proposal uses Groth16 proofs over BN254 and introduces a native privacy pool directly at the protocol level. Unlike application-layer privacy systems such as Railgun, the proposal attempts to integrate privacy functionality directly into Ethereum itself.

Supporters argued that privacy should become a fundamental Ethereum feature rather than depending entirely on external protocols. Critics, however, raised concerns around protocol complexity, trusted setups, post-quantum assumptions, and long-term maintenance risks.

Nullifier state growth also became a major concern since shielded systems require tracking spent commitments to prevent double spends. Some developers argued Ethereum should instead focus on smaller privacy primitives, such as Poseidon precompiles, rather than fully enshrining a global privacy pool.

Despite the divided opinions, the proposal still moved forward as a PFI candidate, showing continued interest in exploring native privacy solutions. The final major discussion focused on EIP-4758, which proposes deactivating SELFDESTRUCT.

SELFDESTRUCT has long been considered one of Ethereum’s most problematic opcodes. Under EIP-4758, account deletion behavior would be removed while preserving sendAll functionality, allowing contracts to transfer balances without fully erasing themselves from state.

Developers argued that simplifying SELFDESTRUCT would reduce protocol complexity and make future upgrades easier to implement. However, researchers identified around 162 contracts that could potentially break under the change. Some contributors argued the number remains acceptable given the long-term benefits, while others warned that even limited breakage could create reputational risks for Ethereum.

Privacy, state management, execution simplicity, and storage economics are becoming central themes shaping Ethereum’s next phase. As Glamsterdam Devnet-4 progresses and Hegota proposals continue evolving, these discussions will likely play a major role in defining Ethereum’s future roadmap.

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.