Ethereum core developers have moved Glamsterdam closer to its next major testing milestone while beginning to define Hegota’s first meaningful components. All EIPs included in Glamsterdam Devnet 7 were ratified as Scheduled for Inclusion, shifting the focus from deciding the upgrade’s scope to proving that its selected features can operate reliably across clients, validators and builder infrastructure.

For Hegota, four proposals advanced to Proposed status, while EIP-8334, Bundled Attestation Propagation, was selected as Proposed for Inclusion. The coming weeks will be critical, with Glamsterdam Devnet 8 targeted for early August 2026, broader devnet testing planned during August, the first public testnet expected in September, and the Hegota non-headliner submission deadline set for August 6.

All Devnet 7 EIPs Are Now Scheduled for Inclusion

The clearest Glamsterdam decision was the ratification of every EIP currently included in Devnet 7 as Scheduled for Inclusion. This means developers are no longer treating the Devnet 7 feature set as an experimental collection of proposals.

The testing team, EthPandaOps and execution-layer client teams agreed that the included EIPs are sufficiently mature to move forward. Pull requests will now be opened to update their official statuses. The decision is important because it marks a transition in the upgrade cycle. Glamsterdam is moving away from feature selection and toward implementation hardening, interoperability testing and operational readiness.

Earlier phases of the upgrade focused on identifying the right combination of execution-layer and consensus-layer changes. EtherWorld has followed that progression through Upgrade Watch #1, Upgrade Watch #3 and the latest All Core Developers Execution coverage.

Ratification does not mean every issue has been resolved. It means the remaining problems are now being treated as implementation and testing challenges rather than reasons to reconsider the upgrade’s scope. Devnet 7 has already surfaced several such issues.

One concerns Payload Timeliness Committee blob votes. During testing, developers observed that PTC blob votes are not counted when the execution payload is absent. That behaviour is being investigated because the votes are expected to function as an independent liveness signal.

If PTC blob votes stop contributing whenever the payload is missing, the mechanism may provide less information during the exact conditions in which an independent liveness check becomes most valuable. Client teams now need to determine whether the issue comes from the specification, a particular implementation or an interaction with fork-choice logic.

Prysm also encountered a Beacon API performance issue that delayed payload propagation by approximately two seconds. The issue affected Builder 0, even though the payload was released on time. The root cause has been identified, giving developers a clearer path toward validating the fix in later testing.

These delays matter because Glamsterdam’s builder-related architecture depends on tightly coordinated communication between validators, builders, consensus clients and execution clients. EtherWorld previously examined the development of this architecture in its coverage of Glamsterdam’s early ePBS devnet planning.

The broader implication of the SFI decision is that Glamsterdam now has a more stable foundation. The next phase is not about adding more features. It is about demonstrating that the existing feature set can perform under larger, more realistic and more adversarial network conditions.

Glamsterdam Devnet 8 Will Focus on Readiness

The next major Glamsterdam milestone is Devnet 8, targeted for early August 2026. Its purpose will be different from earlier devnets. Rather than testing whether specific proposals belong in the upgrade, Devnet 8 will focus on whether clients, APIs and infrastructure are ready to support them consistently.

One key area is SSZ stable-container performance. Teku previously reported slower performance, but Devnet 7 currently has only around 3,000 active validators. Developers concluded that the environment is too small to provide a reliable benchmark for mainnet-like conditions.

Prysm is capturing performance profiles, while Devnet 8 is expected to include a much larger validator set. This should provide stronger data on serialization costs, memory usage, processing overhead and whether the observed slowdown remains within acceptable limits. Circuit-breaker support is another readiness gap.

Teku has merged its implementation, while Prysm is targeting Devnet 8. Lighthouse has not yet implemented the required functionality, and Grandine currently has only a Fusaka-oriented version.

The circuit breaker is meant to provide safer fallback behaviour when external builder infrastructure fails, responds too slowly or returns invalid data. Inconsistent support across clients would limit the value of failure testing and could produce different validator behaviour depending on the client being used.

API coordination remains equally important. Beacon API PRs #625 and #630 require rough consensus before Devnet 8. PR #625 concerns the ProduceBlock V4 flow, including authentication and configuration. PR #630 introduces an ahead-of-time builder-preferences endpoint.

These changes affect more than consensus clients. Staking pools, builders, DVT providers, validator tooling teams, Key Manager API users and Web3Signer integrations all depend on predictable behaviour. The significance of these PRs is therefore not in the individual endpoint details. Their importance lies in whether the wider validator ecosystem can support the same builder workflow without creating incompatible assumptions across tools.

EtherWorld’s Beacon Chain API overview explains why standardization is central to multi-client interoperability. Similar concerns have also appeared throughout recent ACDC discussions. Execution-layer clients are also working to align Block Access List JSON-RPC methods. Differences in method names, parameters or responses could lead to inconsistent tooling behaviour across clients. Earlier BAL development was covered in ACDE Call #241 and Ethereum ACD Monitor #1.

The roadmap now points toward Devnet 8 in early August, followed by a public devnet and a non-finality devnet later in the month. The first Glamsterdam public testnet is targeting September. That schedule is achievable only if developers convert the current implementation gaps into resolved cross-client behaviour. Glamsterdam’s scope is becoming stable. Its delivery timeline now depends on readiness.

Follow all Ethereum protocol calls and updates here.

EIP-8334 Becomes Hegota’s First Clear Non-Headliner

The most important Hegota decision was the selection of EIP-8334, Bundled Attestation Propagation, as Proposed for Inclusion. The proposal targets one of Ethereum’s persistent consensus-layer networking costs: duplicated attestation data.

Validators regularly broadcast attestations containing repeated information across subnets. EIP-8334 would bundle this data and propagate partial messages more efficiently through gossipsub. According to the proposal, this could reduce attestation bandwidth usage by as much as 50%.

That potential reduction is significant because attestation traffic is a continuous part of Ethereum’s consensus process. Lowering duplicated network traffic could improve validator efficiency, reduce bandwidth pressure and make participation more accessible for operators with limited infrastructure.

The proposal already has a draft Prysm implementation and related consensus-specification work, making it more mature than a purely theoretical idea. Another reason it advanced quickly is its backwards-compatible design. EIP-8334 does not technically require a fork. However, aligning it with Hegota gives client teams a common implementation and testing window.

This reflects a broader shift in how Ethereum upgrades are organized. Not every proposal needs a hard fork at the protocol level, but upgrade cycles still provide useful coordination points for implementation, deployment and ecosystem readiness. EIP-8334 also gives Hegota a practical networking-efficiency component alongside its larger strategic themes.

FOCIL has already emerged as the upgrade’s major censorship-resistance direction. EtherWorld previously explored the implications of that choice in Hegotá Should Complete the Holy Trinity of Censorship Resistance and its coverage of ACDC Call #175. With EIP-8334 now selected as PFI, Hegota is beginning to combine high-level protocol goals with operational improvements that directly affect validator networking.

Three More Hegota Proposals Advance to PFI

Developers also moved EIP-8341, EIP-8321 and EIP-8015 to Proposed status. These decisions do not guarantee inclusion. They indicate that the proposals are considered serious enough for continued evaluation within the Hegota process.

EIP-8341, Partial Execution Payload Commitments, was introduced as an alternative to EIP-7862, Delayed State Root. Under the proposal, a builder bid would commit to every execution-layer block-header field except the state root. The state root would keep its current meaning on the execution layer: the post-state produced after executing the block.

This approach avoids redefining the state root itself. Instead, the consensus layer would delay committing to it during the builder-bid stage. The proposal could have limited consensus-layer impact, but two major implementation questions remain. Developers still need a clear Engine API solution for block-hash handling and for distinguishing between full and empty payloads.

These details are critical under ePBS because the protocol must know precisely what the builder has committed to before the full payload is revealed. EIP-8321, Hash-Chain RANDAO, raised a different type of question.

The proposal would replace BLS-based RANDAO reveals with hash-chain pre-images to improve post-quantum safety. The design introduces a possible path toward reducing dependence on cryptography that may eventually become vulnerable to quantum attacks.

However, participants questioned whether changing RANDAO alone would provide meaningful protection while BLS remains widely used elsewhere in Ethereum. EIP-8015 is more straightforward. It would remove deposit-related and ETH1 data fields that became obsolete following Electra.

EIP-8334 addresses networking efficiency. EIP-8341 explores ePBS-related execution commitments. EIP-8321 introduces long-term cryptographic preparation. EIP-8015 removes obsolete protocol structure. EtherWorld previously outlined the early upgrade direction in State of Upgrade – Hegota Edition #1 and ACDC Call #182.

The August 6 submission deadline will determine whether additional non-headliner proposals enter consideration. After that, developers will need to narrow the scope based on implementation maturity, client capacity, security value and testing complexity.

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 from the All Core Developers Consensus (ACDC) Call #179
2. Highlights from the All Core Developers Consensus (ACDC) Call #178
3. Highlights from the All Core Developers Consensus (ACDC) Call #177
4. Highlights from the All Core Developers Consensus (ACDC) Call #176
5. Highlights from the All Core Developers Consensus (ACDC) Call #175

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

Join the EtherWorld & Avarch Internship Program and build your career in blockchain, content, social media, video, podcast editing, or operations. Send your resume and brief introduction to contact@etherworld.co.