Ethereum core developers have made several decisions that clarify the next phase of both Glamsterdam and Hegota. Glamsterdam will likely receive one more coordinated devnet before moving to public testnets, while Devnet-7 will temporarily serve as an early testing environment for application developers. For Hegota, FOCIL remains the confirmed headliner, native account abstraction will not automatically delay the upgrade, and August 6 has been set as the deadline for non-headliner execution-layer proposals.

Glamsterdam Will Likely Move Through Devnet-8 Before Public Testnets

Core developers expect Glamsterdam to receive another coordinated devnet before progressing to established public testnets.

The decision reflects the current condition of Devnet-7. Although the network is now functioning with strong participation, its launch revealed enough instability to justify one more testing cycle. Devnet-8 would give client teams an opportunity to validate fixes, confirm final specifications and test the upgrade under cleaner conditions before Sepolia and Hoodi are involved.

Devnet-7 was intentionally configured as a demanding testing environment. It launched with approximately half a million execution-layer validators to increase the state size and place greater pressure on client implementations. The configuration exposed several bugs and created a difficult start, but most issues were resolved quickly.

The network currently includes around 3,000 validators with balances of 1,024 ETH each. Because activating validators of that size through the standard deposit queue would have taken too long, the validator distribution had to be reorganized. The objective was to give participating clients approximately equal weight, with roughly 100 validators assigned to each implementation.

Most client teams have now joined the network, while the remaining integrations were close to completion during the call. Participation has improved to approximately 80–90%, and Devnet-7 is now being used for regular transaction-spam and blob-related stress scenarios.

The stronger participation rate suggests that the upgrade has moved beyond basic implementation testing. However, it does not mean Glamsterdam is ready for public testnets. Final execution-layer repricing values remain unresolved, several specifications still require wording and cleanup changes, and benchmark work is progressing more slowly than the devnets themselves.

A separate Devnet-6 environment is being prepared specifically for repricing benchmarks. These measurements are important because Glamsterdam includes changes intended to bring operation costs closer to their real execution and state impact. Incorrect pricing can allow resource-intensive operations to remain too cheap or make legitimate activity unnecessarily expensive.

EtherWorld previously examined the upgrade’s broader development path in State of Upgrade – Glamsterdam Edition #1 and the Glamsterdam upgrade resource hub. The proposal-selection and implementation process can also be followed through Tracking the Glamsterdam Upgrade on EIPsInsight.

Even after that transition, mainnet activation will not be immediate. Developers still expect a security and audit-review period, preparation windows before testnet forks and a wider ecosystem notice period. From the point discussed during the call, Glamsterdam was still estimated to be at least several months away from activation.

Devnet-7 Will Temporarily Support Application Testing

Devnet-7 will be promoted as a short-lived environment where application developers can test Glamsterdam-related changes before they reach public testnets.

This decision addresses a recurring problem in Ethereum upgrades: application developers, infrastructure providers and Layer 2 teams often begin testing later than client developers. By the time protocol changes reach Sepolia or Hoodi, many services already have active deployments on those networks, making experimentation more disruptive.

Devnet-7 provides an earlier and lower-risk venue. It includes a faucet and can support contract deployment, transaction testing and infrastructure experiments. Teams can use it to identify whether Glamsterdam changes affect contract assumptions, RPC behaviour, gas calculations, block processing or Layer 2 integrations.

The need for earlier application testing became particularly visible during previous upgrade cycles. Protocol changes can appear stable from a client perspective while still creating unexpected problems for rollups, tooling providers and application infrastructure. EtherWorld discussed similar ecosystem concerns in Effect of Ethereum’s Fusaka Upgrade on Layer 2.

Developers considered whether Ethereum should create a dedicated temporary public testnet similar to Mekong, which gave applications an environment to prepare for Electra. The group ultimately leaned toward using Devnet-7 instead of introducing another network.

Development networks usually pin a specific version of the protocol specification. Client teams may need to shut them down or replace them quickly when specifications change. Encouraging broad application use can create an expectation that the network will remain available, even when it no longer represents the version expected to reach mainnet.

There is also a risk that developers test against obsolete behaviour. If Devnet-7 continues running after Glamsterdam specifications change, applications may receive misleading compatibility results. Long-lived testing is therefore better suited to Sepolia, Hoodi and other established public networks once the specification is close to final.

The practical compromise is to publicize Devnet-7 as an optional, temporary venue for early testing while making its short lifespan clear. Application teams that need a stable long-term environment will still need to retest once Glamsterdam reaches public testnets.

This approach also requires active ecosystem outreach. During the discussion, developers noted that few external builders were currently using the network. Simply making a devnet available does not guarantee adoption. Documentation, faucet information and direct communication will be needed to bring wallets, Layer 2s, smart-contract teams and infrastructure providers into the testing process.

Recent client and testing progress can be compared with Ethereum ACD Monitor #1 and Highlights from ACDC Call #180, which covered earlier stages of Glamsterdam implementation and coordination.

FOCIL Remains Hegota’s Headliner While Account Abstraction Stays Optional

FOCIL remains the confirmed headliner for Hegota, while native account abstraction is included only as a candidate and will not automatically delay the upgrade.

This distinction gives Hegota one firm objective while preserving flexibility around more complex execution-layer work.

Fork Choice Enforced Inclusion Lists, or FOCIL, are intended to strengthen Ethereum’s censorship resistance by making it harder for block builders to repeatedly exclude valid transactions. Under the proposed model, selected validators would publish lists of transactions that should be included, with Ethereum’s fork-choice rules helping enforce compliance.

FOCIL is particularly relevant as Ethereum’s block-building market becomes more specialized. Proposer-builder separation can improve block construction and validator revenue, but it also concentrates transaction-selection power among a smaller set of builders. Inclusion lists seek to preserve open transaction access without removing the efficiency benefits of specialized block production.

EtherWorld previously explored this relationship in How Solo Stakers and FOCIL Strengthen Censorship Resistance on Ethereum and Hegotá Should Complete the Holy Trinity of Censorship Resistance.

FOCIL also complements, rather than replaces, other transaction-protection mechanisms. Encrypted mempools aim to reduce premature transaction visibility, while inclusion lists address whether transactions eventually enter the chain. Their interaction is examined in Ethereum Encrypted Mempool: Progress, Challenges and the Road to Hegota.

Native account abstraction has a less certain position.

Developers previously selected frame transactions as a placeholder while researchers working on different account-abstraction designs attempted to converge on a common approach. Native account abstraction is therefore considered for inclusion, but it is not currently a headliner.

The implication is that Hegota would not necessarily wait for it. A headliner normally defines the upgrade’s identity and can influence its scheduling. A non-headliner must fit within the available implementation and testing window. Unless account-abstraction teams reach sufficient consensus and demonstrate readiness, the feature could be deferred without blocking Hegota.

Developers will revisit the question after non-headliner proposals close. Earlier execution-layer discussions around frame transactions and account abstraction were covered in Highlights from ACDE Call #234 and Highlights from ACDE Call #238.

The August 6 Deadline Will Begin Freezing Hegota’s Scope

Execution-layer proposals must be submitted against Hegota Meta EIP-8081 by August 6, after which developers will begin narrowing the upgrade’s non-headliner scope.

The deadline gives proposal authors a clear final window. An EIP submitted before August 6 may still be presented during the following ACDE meeting and remain eligible for consideration. Proposals that miss the window are unlikely to enter the current upgrade unless developers make an explicit exception.

One newly highlighted candidate is EIP-8268, which proposes adding storage roots to Block Access Lists. The proposal was acknowledged during the call, but a detailed presentation did not take place because its author was unavailable.

The proposal now requires a fuller assessment of its execution-layer benefits, implementation complexity and interaction with other state-access changes. Block Access Lists are designed to make the portions of Ethereum state touched by a block more explicit. Adding storage roots could support verification or execution workflows, but the exact implications will need to be examined by client teams.

The call also raised a related protocol-maintenance question around REST-SSZ and non-Engine API methods exposed through the engine port. Lighthouse reportedly still uses eth_syncing, eth_getBlockByNumber, eth_getBlockByHash and eth_chainId.

Additional methods remain connected to the legacy Eth1 deposit path, including eth_blockNumber, eth_call and eth_getLogs. Lodestar has already removed deposit tracking and now uses only the authenticated Engine API.

No immediate removal decision was made. Instead, client teams must determine which methods remain necessary and whether the older deposit workflow can be retired safely. Reducing unused methods would simplify client interfaces, but removing them too early could break implementations that still depend on legacy behaviour.

For a broader view of the emerging upgrade, readers can explore State of Upgrade – Hegota Edition #1 and EtherWorld’s Hegota upgrade resource hub.

The combined outcome of the call is a clearer division of priorities. Glamsterdam is approaching its final stabilization and ecosystem-testing phase. Hegota is moving toward scope discipline, with FOCIL fixed as its central feature and other proposals required to demonstrate that they can fit around it.

That's all from ACD meeting today. You can follow notes from earlier meetings here.

If you find any issues in this article or notice missing information, please feel free to reach out at team@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.

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.