Ethereum core developers continued refining the network’s next upgrade cycle during recent coordination discussions focused on Glamsterdam devnets, builder deposits, SSZ Engine API standardization, committee scaling, and zkEVM-oriented execution proof systems. The conversations revealed Ethereum’s broader direction toward scalability, improved validator coordination, execution-layer efficiency, and future-proof networking infrastructure.

While Glamsterdam remains heavily focused on execution-layer mechanics, proposer-builder workflows, and devnet readiness, Hegota discussions are beginning to introduce larger architectural ideas around committee scaling and optional execution proofs. Together, both upgrade tracks reflect Ethereum’s continued effort to scale safely without compromising decentralization or client diversity.

Ethereum client teams also aligned on several implementation targets, including devnet schedules, gas-limit handling improvements, and additional specification reviews required before the next testing phases can move forward.

• Glamsterdam Updates
• Hegotá Updates

Glamsterdam Updates

The Glamsterdam discussions primarily revolved around devnet scoping, builder deposit mechanics, gas-limit coordination, and SSZ Engine API experimentation. Developers confirmed that ETH/70 and ETH/71 are now officially included in Glamsterdam devnet-4, while ETH/72 has been deferred to future blob-focused devnets until specifications stabilize further.

One of the most important architectural changes discussed involves how Ethereum clients communicate target gas limits. Instead of relying on execution-layer flags, the target gas limit field is now moving toward a consensus-layer supplied payload attribute. This change is being coordinated through consensus-specs #5235 and execution-apis #796, with execution-layer teams asked to review the proposal before the next coordination deadline.

The shift may appear subtle, but it represents an important improvement in how Ethereum synchronizes execution and consensus behavior. By allowing the consensus layer to directly supply payload attributes, developers can reduce ambiguity between client implementations while improving coordination for future proposer-builder separation systems and advanced block construction mechanisms.

Additional consensus-specification changes were also identified as mandatory requirements for Glamsterdam devnet-4. These include consensus-specs #5223, which introduces a withdrawability delay for builder deposits, and consensus-specs #5236, which validates bids against target gas limits. Both are now considered essential for the next testing stage.

Ethereum developers also continued discussions around “dual-deadline” proposals, specifically PRs #5212 and #5210. The proposals are expected to merge with matching deadline values, although reorg enforcement has been postponed until all clients implement the required logic consistently.

The delay reflects Ethereum’s increasingly cautious approach toward consensus-critical modifications. Rather than forcing incomplete implementations into production testing, client teams are prioritizing synchronization and interoperability before enabling stricter enforcement behavior.

Builder deposits became another major topic during the meeting. Prysm shared benchmark results showing that 8,192 deposits can currently be batch-verified in roughly 800 milliseconds under normal conditions. However, worst-case scenarios where all deposits are invalid can still take nearly six seconds to process.

To address these edge cases, developers proposed introducing a pre-processing cache designed to reduce repeated verification overhead. The discussion highlighted the growing importance of deposit scalability as Ethereum continues exploring more advanced proposer-builder separation designs and higher throughput systems.

Another issue emerged around deposit overflow constraints tied to gas-limit scaling. Developers agreed to temporarily cap the gas limit at 190 million for Glamsterdam devnet-4 to avoid an 8,193 overflow issue. The long-term solution is expected to rely on EIP-7688, which is planned for integration into a later devnet release.

Rather than deploying a completely new deposit contract, Ethereum client teams agreed that targeted client-side optimizations remain the preferred path forward for improving builder deposit processing efficiency.

The decision demonstrates Ethereum’s broader preference for incremental improvements over disruptive architectural redesigns whenever possible. Maintaining compatibility across multiple independent clients remains one of Ethereum’s strongest decentralization advantages, and developers continue prioritizing solutions that minimize unnecessary fragmentation.

Another technically significant discussion focused on the future of the SSZ Engine API. Two competing proposals were presented during the call.

The first proposal, referred to as the Barnabas approach, keeps the current naming structure intact while introducing REST transport improvements only. The second proposal, led by Marius, introduces a much larger naming refactor across the Engine API stack.

Nethermind reported that it has already implemented the Barnabas approach internally and observed performance improvements ranging between five and ten times faster than existing JSON workflows.

Despite these promising benchmarks, developers decided to defer a final decision to future ACDE and ACDT discussions. Importantly, the SSZ Engine API remains optional and is not currently tied to any hard fork activation timeline.

This cautious rollout strategy aligns with Ethereum’s long-standing philosophy of testing major infrastructure changes gradually before integrating them into mandatory consensus pathways.

Several important decisions were finalized for Glamsterdam devnet-4. Ethereum developers confirmed the inclusion of EIP-7928 alongside EIP-7732.

The meeting also confirmed that all gas-limit and dual-deadline specification updates, including consensus-specs #5223, #5235, #5236, #5212, and #5210, are now officially targeting Glamsterdam devnet-4.

To mitigate overflow issues, the temporary 190M gas-limit cap will remain active until future devnets integrate EIP-7688-based solutions.

Action items were distributed across both execution and consensus-layer teams. Execution-layer developers were instructed to review execution-apis #796 before the upcoming deadline, while Lighthouse developers were asked to share benchmark branches aligned with Prysm’s deposit-processing experiments.

All consensus and execution-layer teams were additionally asked to review the latest implementation updates for EIP-8025 using the updated pull request rather than older merged versions.

Developers also outlined near-term rollout targets. bal-devnet-7 is expected to launch first, followed shortly afterward by Glamsterdam devnet-4. Meanwhile, the Glamsterdam alpha-8 specification release is being prioritized to accelerate broader testing coordination.

Hegotá Updates

While Glamsterdam discussions concentrated on execution-layer infrastructure and devnet readiness, Hegota conversations focused more heavily on scaling Ethereum’s networking and committee coordination systems.

One of the most notable proposals came from Sukun, who presented a committee attestation broadcast specification under ethp2p #5. The proposal introduces signature batching, reduced gossip overhead, and a lower mesh D parameter set to four. Together, these changes aim to significantly improve networking efficiency across validator committees.

The proposal specifically targets a fourfold increase in committee sizes while enabling support for future eight-slot epoch structures.

Committee scaling has become increasingly important as Ethereum continues exploring long-term scalability pathways. Larger committees can improve network security and validator participation distribution, but they also introduce substantial networking overhead. The Hegota proposal attempts to reduce that overhead through more efficient attestation propagation mechanisms.

Reducing gossip complexity is particularly important because Ethereum’s consensus system relies heavily on timely validator communication. As validator counts continue growing, network efficiency becomes increasingly critical for maintaining finality guarantees and minimizing propagation delays across geographically distributed nodes.

Another major Hegota discussion centered around EIP-8025, presented by the Ethereum Foundation zkEVM team.

The proposal introduces optional execution proofs designed to support zkEVM-oriented validation systems without imposing mandatory consensus requirements on the broader network. Developers emphasized that the proposal remains fully opt-in and does not introduce consensus gating mechanisms.

Both Lighthouse and Prysm reportedly already have working implementations for the proposal, demonstrating growing client-side experimentation around zk-based execution verification.

Although still early in development, optional execution proofs could eventually play an important role in Ethereum’s broader modular scaling ecosystem. Rather than forcing every validator to execute identical workloads directly, proof-based systems may allow parts of execution validation to become more efficient while preserving network trust assumptions.

Importantly, developers repeatedly clarified that EIP-8025 is not attempting to replace Ethereum’s existing execution model. Instead, the proposal is designed as an optional enhancement layer that clients may adopt incrementally over time.

This gradual approach reflects Ethereum’s increasingly modular roadmap philosophy. Instead of forcing abrupt protocol transformations, developers are introducing optional pathways that can mature independently before receiving broader adoption.

Not every proposal reached resolution during the meeting. Discussions around returning deposits for distinct credentials and introducing custom suite thresholds were ultimately deferred to a future ACDC meeting due to time limitations.

Even so, the broader direction of Hegota is becoming clearer. The upgrade track appears increasingly focused on networking scalability, validator coordination efficiency, zk-compatible infrastructure, and future-proof consensus communication systems.

Together, the Glamsterdam and Hegota discussions illustrate Ethereum’s evolving strategy for scaling the protocol across multiple layers simultaneously. Rather than relying on a single breakthrough upgrade, Ethereum developers continue building a series of interconnected improvements spanning consensus coordination, execution efficiency, validator communication, and modular proof systems.

As additional devnets launch over the coming weeks, many of these proposals will begin transitioning from specification discussions into real-world interoperability testing. The results of those devnets will likely shape the next phase of Ethereum’s roadmap heading into future hard fork planning cycles.

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.