Ethereum’s All Core Developers Execution Call #243 delivered several decisions that could shape the network’s next two upgrades. For Glamsterdam, developers confirmed that the latest gas repricing figures are final and can support a substantially higher gas limit.

For Hegotá, developers introduced a stricter selection process. Proposals without an active champion will not advance, while execution clients must submit preference lists by September 10.

Glamsterdam’s Gas Repricing Is Now Final

Ethereum developers approved the latest Glamsterdam gas repricing figures as final, removing one of the upgrade’s most important sources of technical uncertainty. The approved numbers cover repricing work associated with EIP-2780, EIP-8037 and EIP-8038. Developers confirmed that the figures included in the latest gas-testing release are correct and remain within the intended safety limits.

This means client teams do not need to wait for another specification revision or rewrite their implementations around new gas values. A few targeted benchmarks will still be forwarded to clients for additional review, but these results are not expected to change the specifications.

The decision arrived alongside the launch of Glamsterdam Devnet-8, also known as Platåberget. Unlike earlier internal networks, Devnet-8 is publicly accessible and provides developers with infrastructure, documentation and a faucet for testing.

Its launch marks an important transition. EtherWorld previously reported that Glamsterdam Devnet-7 was expected to be the final dedicated devnet before a mild specification freeze. Devnet-8 can now test a more mature combination of execution-layer features under wider participation.

Increasing the block gas limit without adjusting underpriced operations could allow attackers to build blocks that are valid according to gas accounting but excessively expensive for nodes to execute. Such blocks could increase processing times, create client instability or expose the network to denial-of-service attacks.

The repricing process therefore examined how much CPU time, memory, state access and other client resources different EVM operations consume. The goal was to ensure that the gas charged for an operation accurately reflects its worst-case execution cost.

Developers must still demonstrate that all major clients can process high-capacity blocks consistently. However, the decision moves Glamsterdam closer to a specification that can eventually progress toward public testnets and mainnet deployment.

Follow all Ethereum protocol calls and updates here.

Ethereum Will Use a Configurable Path Toward 200M Gas

Ethereum developers backed an optional consensus-layer configuration that could coordinate a staged increase toward a 200 million gas limit. The decision does not immediately raise Ethereum’s gas limit to 200 million. Instead, it establishes a mechanism through which clients could follow a predefined gas-limit schedule after Glamsterdam activates.

EIP-8261 proposes adding a configuration parameter to the consensus-layer specification. Clients supporting it could receive future default gas-limit targets without requiring every operator to manually coordinate each increase.

A schedule could begin near Ethereum’s current 60 million default and increase capacity through several stages before reaching 200 million. Node operators would still be able to override the default locally, and clients could choose whether to support the optional parameter.

Representatives from Prysm, Lighthouse, Lodestar and Teku supported the direction. Nethermind also signalled approval, giving the proposal backing across both consensus and execution implementations.

Nimbus expressed more cautious support. Its representative questioned whether the configuration would produce major safety benefits compared with existing fleet-management systems, especially because large staking providers can already coordinate client settings across their infrastructure.

Nevertheless, developers agreed that the optional configuration is useful enough to move forward. The decision matters because Ethereum’s path toward 200 million gas cannot depend only on theoretical execution benchmarks. The network also needs a predictable operational process that gives client teams and node operators time to observe performance before each increase.

EtherWorld previously covered the 200 million gas target and its surrounding execution bottlenecks. The latest decision provides a more controlled route toward that objective instead of assuming the network should make the entire jump at once.

Execution clients currently use different history-retention strategies. Erigon retains approximately one month of recent history by default, while other clients discussed retaining around five months, expiring data from before the previous fork or maintaining a rolling block window.

A consistent standard is important because nodes must still be able to discover and synchronize historical data even when individual clients delete older block bodies and receipts. EtherWorld’s guide to Partial History Expiry on Geth, Besu and Nethermind explains how reducing historical storage can make Ethereum nodes easier to operate.

Hegotá Candidates Must Secure a Champion and Client Support

Ethereum developers decided that a Hegotá proposal will not advance without an identifiable champion capable of presenting and defending it during core developer calls. Execution-layer clients must also submit their proposal preference lists by September 10, giving teams approximately four weeks to evaluate the current field.

These requirements introduce a practical filter after 17 EIPs were submitted for Proposed for Inclusion status. The August 6 submission deadline determined which proposals could enter the process, but submission alone does not guarantee meaningful consideration.

A champion is expected to explain the proposal, answer implementation questions, coordinate specification changes and remain available as clients evaluate its risks. If an EIP has no one available to speak for it, developers will not merge it into Hegotá’s Meta EIP-8081.

This immediately affected five proposals:

• EIP-7971: Hard Limits for Transient Storage
• EIP-8058: Contract Bytecode Deduplication Discount
• EIP-7609: Decrease Base Cost of TLOAD and TSTORE
• EIP-7973: Warm Account Write Metering
• EIP-8360: TCREATE Opcode

Their author was unavailable during ACDE #243. Developers may offer another opportunity at the next call, but the proposals could be removed from consideration if nobody actively champions them. The remaining candidates span several major areas.

EIP-7923 would replace the EVM’s quadratic memory pricing with linear, page-based costing. The proposal argues that EIP-7825’s transaction gas ceiling now provides a safety boundary that did not exist when quadratic memory pricing was introduced.

EIP-3298 proposes removing gas refunds, while EIP-5920 adds a PAY opcode that could transfer ETH without executing the recipient’s code. Other candidates address account-change metering, access sets, blob-aware transaction propagation, checked arithmetic and normalized state gas limits.

EIP-8355 proposes precompiles for verifying ML-DSA signatures under the FIPS 204 standard. It could provide Ethereum applications and account systems with a more efficient route toward post-quantum authentication. EtherWorld previously covered the trade-offs surrounding ML-DSA precompiles during ACDE #228.

EIP-8375, known as eMBER, proposes burning part of protocol-visible execution rewards. Its goal is to reduce the security impact of unusually large payments while preserving enough reward for builders to continue selecting valuable bids.

The preference-list deadline means clients must now compare proposals based on more than their individual benefits. They must consider implementation complexity, security risks, interaction with other EIPs and the total testing burden placed on Hegotá.

Ethereum Delays Its Native Account Abstraction Decision

Ethereum developers delayed the choice of a native account abstraction design until dedicated breakout discussions compare Frame Transactions with competing approaches. The decision means EIP-8141, commonly known as Frames, has not yet been confirmed as Hegotá’s execution-layer headliner.

Support for Frames has nevertheless increased. Nethermind now supports the proposal and indicated that it could back Frames as a headliner. Geth contributors also described Frames as increasingly important for moving Ethereum toward post-quantum readiness, while Besu expressed no opposition to continuing the work.

Frames would restructure transactions into separate components for validation, execution and fee payment. This could support fee sponsorship, programmable authentication, alternative signature schemes and more flexible transaction flows.

EtherWorld has previously examined how Frame Transactions could enable native account abstraction and why post-quantum security is increasing pressure for account-level changes. However, Layer 2 teams and ecosystem builders raised concerns about adopting EIP-8141 before the wider EVM ecosystem reaches technical convergence.

One concern is fragmentation. If Ethereum Layer 1 adopts Frames while major Layer 2 networks implement a different model, wallets and applications may need to support incompatible account standards.

EIP-8130 was presented as an alternative. Its supporters argue that it offers programmable accounts, key rotation and cross-chain account synchronization without requiring new EVM opcodes. Base has already implemented parts of this approach.

Frames supporters responded that EIP-8141 provides greater control over transaction execution, including the ability to validate conditions at different stages. They also argued that denial-of-service risks could be mitigated through transaction-admission rules and further specification improvements.

Breakout calls will restart on August 25 to compare the proposals and address concerns from clients, Layer 2 teams, wallet developers and other ecosystem participants. Developers will aim to select the preferred implementation during ACDE on August 27, when they may also decide whether it should become a Hegotá headliner.

That distinction matters. A headliner receives greater coordination priority and may influence the upgrade’s schedule. A non-headliner can be deferred if it is not ready without necessarily delaying the wider fork.

For now, Ethereum is prioritizing convergence over speed. As EtherWorld’s overview of Ethereum’s changing roadmap explains, Hegotá is increasingly tied to account architecture, censorship resistance and post-quantum preparation.

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. All You Need to Know About Ethereum Glamsterdam Upgrade
2. All You Need to Know About Ethereum Hegotá Upgrade
3. Upgrade Watch #3: Glamsterdam Devnet-7 Nears Final Launch
4. Highlights From the All Core Developers Execution Call #241
5. Ethereum’s Roadmap Just Changed: Here’s What’s Next

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.