Ethereum developers kept Glamsterdam's October 26 Hoodi activation on schedule, rejected a late builder-onboarding fix, and declined four Consensus Layer proposals for Hegotá during All Core Developers Consensus Call #189 on October 15, 2026.

The meeting brought sharper decisions to Hegotá's scope. Optional execution proofs, RowDAS, client diversity reporting, and anti-correlation attestation penalties were all moved to Declined for Inclusion (DFI). Meanwhile, changes to legacy validator deposits remain under review, and a decision on withdrawal credentials pre-registration was postponed.

Glamsterdam Stays on Track for Hoodi

Ethereum developers maintained October 26, 2026, as the activation date for Glamsterdam on Hoodi, following the successful Sepolia fork on October 6.

The decision keeps the upgrade's public testnet rollout moving without another schedule adjustment. Client teams reported that Sepolia's transition had generally gone well, providing confidence to proceed with the next deployment.

As previously reported in Ethereum Sepolia Glamsterdam Upgrade Goes Live, the activation brought enshrined proposer-builder separation (ePBS), Block-Level Access Lists, and other protocol changes into public-testnet testing. Hoodi now becomes the next checkpoint for client interoperability, validator readiness, and builder operations before mainnet deployment can be considered.

Client release availability remains an immediate dependency. At the time of the call, Lodestar and ethrex had published compatible releases. Teku expected to release on October 16, while Lighthouse and Grandine were preparing releases for the following days.

The Ethereum Foundation plans to publish its Hoodi upgrade announcement once a sufficient set of client releases is available. Developers emphasized the need to publish releases quickly because Hoodi's distributed operators require time to upgrade.

Hoodi will also test whether builders can participate immediately after the fork transition. Barnabas proposed preparing builder deposits and top-up transactions before activation, with the objective of having a registered builder propose one of the first two post-fork slots.

The October 26 target was established during ACDE #247, while ACDC #188 had maintained the earlier Sepolia deployment plan. The successful Sepolia activation represents progress from the compatibility and adversarial-testing challenges documented in ACDC #187.

Developers Reject Late Builder Onboarding Fix

Core developers decided not to modify Glamsterdam's one-time builder onboarding mechanism, despite concerns that it could interfere with existing validator deposit protections used by staking protocols.

The issue was raised by representatives from Lido, who described an edge case involving deposits sharing a validator public key. Under Ethereum's existing validator deposit rules, the first relevant deposit establishes withdrawal credentials. Staking protocols use this behavior to protect deposits against credential manipulation.

A common approach involves making a smaller initial deposit, waiting for the validator to appear with the expected credentials, and only then depositing the remaining ETH. Glamsterdam introduces a special onboarding mechanism for builders. During the fork transition, a builder deposit can affect how subsequent pending deposits sharing the same public key are interpreted.

Lido argued that this creates a third possible outcome for staking protocols, i.e., instead of a validator appearing with correct or incorrect withdrawal credentials, no validator appears, and the deposited ETH is credited to a builder. The proposed fix would preserve the distinction between validator and builder deposits during the one-time onboarding process.

Supporters argued that the change was relatively small and would prevent multiple staking protocols from having to implement and audit separate application-layer workarounds. However, developers rejected the modification primarily because of its timing.

Sepolia had already activated with the existing specification, and Hoodi client releases were being prepared. Changing the behavior now could require another Sepolia deployment and additional testing before moving to Hoodi and mainnet.

Several client developers argued that introducing an untested change this late could create greater protocol-level risk than retaining the existing behavior. The issue affects the fork-transition onboarding process rather than an ongoing deposit-processing rule, but its consequences could extend to deposits waiting in a lengthy entry queue.

Follow all Ethereum protocol calls and updates here.

Four Consensus Layer Proposals Declined for Hegotá

Developers moved four additional proposals to Declined for Inclusion (DFI) for Hegotá, narrowing the Consensus Layer scope while leaving room for the underlying research to continue.

The decisions were guided by client-team rankings, implementation priorities, and whether the proposed changes justified inclusion alongside Hegotá's existing commitments.

1. EIP-8025: Optional Execution Proofs was declined after developers failed to reach sufficient Consensus Layer agreement. The proposal would allow participating nodes to exchange and evaluate optional execution proofs while continuing to use ordinary execution for validator attestations. Its supporters argued that EIP-8025 could establish practical experience with execution proofs before Ethereum considers more extensive zkEVM-based verification. However, several developers questioned whether improving the coordination of experimental work justified moving the proposal into Hegotá's canonical specification.
2. RowDAS was also declined. The proposal seeks to improve data reconstruction by distributing computational workloads and reducing reliance on particular network participants. Its champion presented a smaller alternative focused on duty allocation, intended to address excessive CPU usage without adopting the proposal's full design. However, most client teams did not consider the change sufficiently urgent, particularly given current blob demand and the limited deployment of the infrastructure it targets.
3. EIP-8359: BeaconBlock Reporting Field received DFI status after failing to attract sufficient client support. The proposal would add a dedicated field for reporting client combinations used by validators, improving client-diversity measurements beyond the existing graffiti field. Developers acknowledged the importance of understanding client concentration but did not consider the additional protocol field a priority for Hegotá.
4. EIP-7716: Anti-Correlation Attestation Penalties was declined following a longer discussion about staking infrastructure concentration. The proposal would increase inactivity penalties during correlated outages, creating stronger financial incentives for validators to diversify their client software and infrastructure. Supporters argued that existing penalties are often too small to meaningfully discourage concentration. However, developers raised concerns about modifying Beacon State, adding fork complexity, and potentially connecting the proposal to broader validator-economic changes.

These decisions build on the filtering process outlined in Ethereum Foundation Ranks 62 EIPs for Hegotá.

Validator Deposit Changes Remain Under Review

Developers deferred further decisions on two validator deposit proposals, leaving important questions about legacy withdrawal credentials and delegated staking protections unresolved.

For EIP-8365, developers agreed to continue reviewing proposed modifications rather than immediately finalizing its implementation. The proposal targets new validators using legacy 0x00 withdrawal credentials.

As currently described, depositing with unsupported credentials after the fork could result in ETH being burned. Barnabas proposed a different approach: allow such validators to enter without performing validator duties or earning rewards.

Operators would retain the ability to change withdrawal credentials or exit, avoiding automatic losses from certain deposit mistakes. A separate concern involves deposits submitted before Hegotá but processed afterward because of the validator entry queue.

Developers discussed moving the credential restriction to the deposit-request stage rather than applying it when pending deposits are processed. This would allow deposits submitted under the earlier rules to be treated accordingly, even when the queue extends beyond the fork.

Currently, staking protocols often rely on pre-deposits or off-chain monitoring systems to protect against this behavior. EIP-8205 proposes registering a signed commitment linking a validator public key to withdrawal credentials before any ETH is deposited.

Supporters argued that this could remove the need for duplicated protection mechanisms across staking protocols and reduce reliance on trusted off-chain infrastructure. EIP-8205 will return at the beginning of the next ACDC scoping session, with its inclusion still uncertain.

ACDC #189 leaves Ethereum with a clearer distinction between immediate deployment commitments and longer-term protocol research. Glamsterdam's existing specification remains unchanged, while Hegotá continues to shed proposals that lack sufficient agreement.

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.

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

• Ethereum Protocol Update: ACDE #245
• Ethereum Protocol Update: ACDC #187
• State of Upgrade: Hegotá Edition #1
• All You Need to Know About Ethereum Hegotá Upgrade
• Hegotá Should Complete the Holy Trinity of Censorship Resistance

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.