Ethereum developers made several consequential roadmap decisions during All Core Developers Consensus Call #187 on September 17, 2026. The immediate priority remains shipping Glamsterdam safely. Ethereum developers also are moving closer to defining what Hegotá will actually contain.

At the same time, developers decided not to make an inclusion decision on EIP-8363, the controversial proposal to taper Ethereum’s issuance. Instead, the discussion is expected to move toward a broader community process.

Sepolia Confirmed for October 6

Glamsterdam will activate on Sepolia on October 6, while Hoodi is tentatively scheduled for October 27. Consensus Layer client teams now have a September 29 hard deadline to publish Glamsterdam-compatible releases, although developers strongly prefer releases to arrive earlier so security researchers and bug bounty participants have more time to review them.

That timing follows encouraging results from Glamsterdam Devnet 11. The network activated cleanly earlier in the week, with both Lido and Optimism deploying and reporting no immediate problems. Developers plan to keep the devnet running for roughly another week before shutting it down.

Devnet 8 faced adversarial conditions including a JUMP-related attack that triggered out-of-memory problems in Besu. A separate t-store spam attack also pushed Besu block times toward roughly seven seconds under heavy execution load.

The adversarial-testing phase followed months of Glamsterdam devnet work. EtherWorld previously tracked the upgrade as developers advanced Glamsterdam toward Devnet 8 and later reported how Glamsterdam entered adversarial testing during ACDE #244.

Those issues were one reason developers wanted another stable devnet before moving into public testnets. The Sepolia date was subsequently moved to October 6 during ACDC #186, giving client teams additional time for a clean transition before the first major public testnet.

Developers specifically called for strong builder circuit breakers before testnet activation. On a public testnet, free ETH makes it cheap for a malicious builder to submit artificially high bids and then withhold the promised payload.

Without appropriate safeguards, that behavior could disrupt block production. Developers want that tested on Hoodi and, where possible, Sepolia.

The tentative October 27 Hoodi activation will therefore serve as another major checkpoint. A final go or no-go decision is expected during the October 8 ACD call after developers have observed Sepolia.

For readers following the wider rollout, EtherWorld’s Glamsterdam and Hegotá protocol coverage tracks how Ethereum moves from proposal selection through devnets, public testnets and eventual mainnet deployment.

QUIC Becomes the Default Networking Path

Consensus Layer clients will make QUIC their default transport path with Glamsterdam, while MPLEX will only begin deprecation after mainnet activation.

Ethereum is moving toward a newer networking stack, but developers rejected the idea of removing older transport options too aggressively. QUIC is expected to become the default dial path across Consensus Layer clients when Glamsterdam releases ship.

The protocol runs over UDP and is increasingly viewed by client teams as a better long-term transport for Ethereum’s peer-to-peer networking than the existing TCP-based path. MPLEX will remain available through Glamsterdam.

Once the upgrade has activated on mainnet, individual client teams can begin deprecating it, and the related consensus-specification change is expected to follow after the fork. The slower rollout came partly from concerns raised by the Teku team.

Teku already has full QUIC support, but not every Ethereum node operator currently has UDP enabled or properly configured. Some operators may run behind firewalls, cloud environments or infrastructure policies built around TCP connectivity.

Networking is becoming increasingly important to protocol scalability. Faster blocks, heavier payloads, data-availability work and more complex proposer-builder interactions all depend on data moving reliably between nodes.

That broader networking pressure has also appeared throughout Hegotá planning. EtherWorld’s ACDC #184 coverage tracked proposals involving faster slots, propagation changes and validator improvements as the Hegotá proposal window closed.

Glamsterdam’s move toward QUIC is therefore more than a networking implementation detail. It establishes infrastructure that future upgrades will increasingly depend on.

Follow all Ethereum protocol calls and updates here.

Hegotá Scope Narrows Around Fewer EIPs

EIP-8015 moved to CFI, EIP-8411 entered the Hegotá proposal pipeline, EIP-8365 will move forward only with reduced scope, and seven other Consensus Layer proposals were declined.

The Ethereum Foundation Protocol Cluster recently published its assessment of 62 Hegotá EIPs, while individual client teams have been producing their own rankings. Those rankings are now translating into fork decisions.

EtherWorld has been following that narrowing process since the first State of Upgrade: Hegotá Edition, when the fork was still dominated by early proposal evaluation and FOCIL was emerging as its clearest Consensus Layer direction.

1. EIP-8015 Moves to CFI: The proposal removes unused deposit and eth1data fields from Beacon Chain state and was moved to Considered for Inclusion. Client support was strong, and developers viewed the proposal as relatively straightforward protocol cleanup.
2. EIP-8411 Advances, But CFI Waits: EIP-8411, Fast Execution Payload Broadcast, advanced to the proposal stage but did not yet receive CFI status. The proposal would divide execution payloads into 64 chunks accompanied by Merkle proofs, allowing pieces of a payload to propagate independently across the network.
3. EIP-8365 Gets a Smaller Scope: EIP-8365 also moved toward Hegotá, but only after developers agreed that its scope should be reduced. The original proposal addressed the retirement of legacy 0x00 BLS withdrawal credentials, including forcing existing validators using those credentials to exit.

The revised direction is narrower. Hegotá would block new 0x00 deposits, while forcing existing 0x00 validators to exit would be postponed to a later upgrade, currently referred to as I-Star. The author agreed to revise the EIP before the next ACDC meeting.

Developers also moved EIP-8237, EIP-8341, EIP-8367, EIP-8321, EIP-8243, EIP-8146 and EIP-8375 to Declined for Inclusion.

EIP-8321, for example, relates to Ethereum’s longer-term post-quantum direction, and developers explicitly noted that quantum-resistance research can continue outside the immediate Hegotá fork.

That fits Ethereum’s broader roadmap shift. EtherWorld recently examined how Ethereum’s roadmap is moving toward quantum security, STARKs, privacy and formal verification. Earlier research efforts have also included Ethereum Foundation backing for ZKnox’s post-quantum work.

Hegotá cannot absorb every technically useful proposal. Developers are increasingly separating research worth continuing from changes that need to ship in this fork.

EIP-8363 Moves Beyond Normal Fork Scoping

Core developers did not make an inclusion decision on EIP-8363 and will instead explore a broader process for deciding Ethereum’s issuance policy.

This may be the most significant governance outcome of ACDC #187. EIP-8363, Tapered Issuance Burn, proposes reducing the rewards validators ultimately retain as the percentage of ETH staked rises.

During the call, three client teams favored declining EIP-8363 while three abstained. Rather than interpreting that split as an ordinary fork-scoping vote, participants questioned whether All Core Developers should be the group making the decision at all.

EtherWorld previously examined the proposal in depth in Ethereum’s Issuance Debate: Could Staking Rewards Fall to Zero?, including its tapered-burn mechanism, staking-ratio assumptions, validator economics and concerns around solo stakers. Changing issuance can affect validator economics, liquid staking protocols, ETH holders, DeFi collateral, solo stakers and Ethereum’s assumptions about economic security.

The Ethereum Foundation Protocol Cluster had already highlighted similar concerns when evaluating Hegotá proposals. In its ranking of all 62 Hegotá EIPs, EIP-8363 was placed outside the recommended fork scope, with the broader question of issuance described as something that should involve more than a normal upgrade-selection process.

The topic resurfaced again during the recent Ethereum Foundation Protocol AMA, where researchers discussed staking incentives, validator concentration and how major protocol-economic decisions should actually be coordinated.

Instead, Alex Stokes is expected to propose a process for gathering wider community input before a future call. That process could eventually involve researchers, client teams, validators, staking providers and other ecosystem participants beyond the normal PFI-CFI-SFI upgrade pipeline.

Meanwhile, ideas that require wider governance, additional research or heavier implementation work are being pushed into separate processes or future forks. You can follow EtherWorld’s continuously updated Hegotá upgrade tracker as the remaining proposals move from ranking and scoping toward implementation.

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. Platåberget Testnet Brings Glamsterdam Closer to Mainnet
2. Ethereum Protocol Update: ACDC #184
3. Ethereum Protocol Update: ACDC #183
4. Tracking the Glamsterdam Upgrade on EIPsInsight
5. All You Need to Know About Ethereum Hegotá Upgrade

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.