Ethereum core developers advanced five proposals for Hegotá, deferred two validator deposit-related decisions, and left Glamsterdam's execution payload bid gossip rules unresolved during All Core Developers Consensus (ACDC) Call #190, held on October 29, 2026.

The most significant outcome was the unanimous selection of EIP-8015 for Scheduled for Inclusion (SFI), while four networking and validator improvements moved to Considered for Inclusion (CFI). Developers also outlined a phased Hegotá testing strategy centered on FOCIL and Frame Transactions. The decisions continue the scope-narrowing process seen in ACDC #188 and ACDC #189, with greater emphasis on implementation readiness and client support.

Five Hegotá EIPs Advance, With EIP-8015 Reaching SFI

Developers unanimously moved EIP-8015 (Beacon State Cleanup) to Scheduled for Inclusion for Hegotá, while EIP-8334, EIP-8383, EIP-8148, and EIP-8411 advanced to Considered for Inclusion. The decisions expand Hegotá's candidate set with relatively contained improvements targeting Beacon Chain state management, networking efficiency, validator operations, and execution payload propagation.

EIP-8015 emerged as the most mature proposal. Its specification changes have already been merged into the Hegotá development specifications and tested on a devnet, giving developers sufficient confidence to move beyond preliminary consideration. Four additional proposals received CFI status:

• EIP-8334 - Bundled Attestation Propagation: Proposes bundling attestations to reduce networking overhead. Simulations suggest approximately 50% bandwidth savings for home nodes under decoupled consensus workloads. The proposal primarily affects networking behavior rather than core consensus logic.
• EIP-8383 - Reduce CL Block Retention Window: Adjusts a configuration value to better align consensus-layer block retention with blob and historical data retention windows. Lighthouse and Lodestar expressed support.
• EIP-8148 - Custom Sweep Thresholds: Introduces configurable validator sweep thresholds within the 32–2048 ETH range. A proof of concept exists in Prysm and DORA, while Lido is funding an audit.
• EIP-8411 - Fast Execution Payload Broadcast: Proposes chunked payload propagation through gossipsub. Simulations indicate approximately threefold faster propagation. Potuz suggested advancing the proposal directly to SFI, but developers selected CFI.

Importantly, CFI does not guarantee eventual inclusion. Each proposal must still demonstrate sufficient client support, implementation maturity, and testing confidence before receiving SFI status.

Validator Deposit Changes Deferred as Developers Favor Long-Term Solutions

Developers deferred the remaining decision on EIP-8365, while moving EIP-8205 to Deferred for Inclusion (DFI), favoring a future post-quantum deposit contract redesign to address deposit front-running. Both discussions concern validator deposit handling, but they address different problems.

EIP-8365 seeks to prevent new validators from entering through legacy 0x00 withdrawal credentials. Its scope had already been reduced during ACDC #188, when the forced-exit component was separated into EIP-8433 for consideration in a later upgrade.

The remaining disagreement concerns how valid post-fork 0x00 deposits should be handled. One approach would burn the deposited ETH, providing a comparatively straightforward enforcement mechanism.

Barnabas presented an alternative that would preserve the deposit balance without allowing immediate activation under legacy credentials. Developers did not reach agreement and postponed the decision for two weeks, allowing further discussion around Devcon before reconsidering the issue at the next ACDC.

EIP-8205, meanwhile, addresses deposit front-running through withdrawal credential preregistration. Instead of including a separate mitigation in Hegotá, developers favored incorporating the requirement into Ethereum's future post-quantum deposit contract architecture.

Follow all Ethereum protocol calls and updates here.

Hegotá to Prioritize FOCIL & Frames Before Quick Slots Integration

Developers outlined a staged implementation strategy for Hegotá, prioritizing stable development networks for FOCIL and Frame Transactions before integrating smaller EIPs and eventually Quick Slots. The proposed sequence begins with establishing a stable Hegotá devnet containing the two headliner features.

Less complex CFI proposals would follow, potentially in batches. Quick Slots would initially progress through separate development branches and parallel devnets, allowing its proponents to address engineering and application-layer requirements without blocking other Hegotá work.

This approach reflects the different implementation risks associated with Hegotá's major features. FOCIL, introduced through EIP-7805, aims to strengthen Ethereum's censorship resistance through fork-choice-enforced transaction inclusion lists.

Frames, introduced through EIP-8141, provide a new execution-layer transaction structure. Frames was formally selected as Hegotá's execution-layer headliner during ACDE #245.

Quick Slots, proposed through EIP-8198, meanwhile, aims to reduce Ethereum's slot duration from 12 seconds to 10 seconds, requiring careful evaluation of propagation timing and client performance. The proposed staged approach would allow these features to advance independently before integration.

FOCIL's execution-layer implementation also requires clarification. Developers identified an Engine API ambiguity in which some execution clients discard an existing payload and rebuild it when updated inclusion lists arrive late in the slot.

Rebuilding the entire payload can contribute to missed or delayed blocks, particularly when blocks are already full. Barnabas raised the issue through execution-apis PR #964, with further execution-layer input expected at the next ACDE.

Glamsterdam Bid Gossip Rules Remain Open Ahead of Further Devnet Testing

Developers did not finalize the execution payload bid gossip rules for Glamsterdam. Two competing specification proposals remain under review, while the next consensus-specifications release and additional devnet testing continue to shape the upgrade's readiness.

The disagreement centers on how updated builder bids should propagate through Ethereum's peer-to-peer network under enshrined proposer-builder separation (ePBS), introduced through EIP-7732. PR #5774, associated with Potuz and Justin, would allow proposers to accept higher bids from the same builder without enforcing a protocol-level minimum increment.

PR #5776, proposed by Nico, introduces a 3% minimum bid increase intended to reduce spam and denial-of-service risks. Potuz opposed specifying this restriction at the protocol level, arguing that gossip filtering should remain an implementation choice for individual clients.

Prysm is unlikely to enforce the stricter approach. The decision remains open pending additional client feedback. Separately, PR #5770 adds missing fork-choice checks to Gloas execution payload gossip validation.

Lodestar expressed support, although additional client sign-offs are needed before merging. These questions continue the ePBS implementation discussions previously covered in ACDC #176.

The immediate Glamsterdam targets remain:

• October 30, 2026: Planned consensus-specifications release.
• November 16–20, 2026: Earliest estimated devnet window incorporating the consensus-breaking Lido-related changes.

The Lido pull request requires explicit devnet testing before developers can confidently integrate the changes. Testing remains particularly important given the interoperability and stability concerns observed during earlier Glamsterdam development, as documented in ACDC #187.

The call also confirmed a moderation transition. Alex Stokes will step down as ACDC moderator, with Ben Edgington assuming the lead role and Will Corcoran serving as deputy beginning with the next call.

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. Ethereum Protocol Update: ACDC #189
2. Ethereum Protocol Update: ACDC #188
3. Ethereum Protocol Update: ACDC #187
4. Ethereum Protocol Update: ACDC #186
5. Ethereum Protocol Update: ACDC #185

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.