Ethereum developers confirmed EIP-8141: Frame Transactions as Hegotá’s execution-layer headliner during All Core Developers Execution Call #245. Developers also rejected a late attempt to add EIP-8253 to Glamsterdam, declined 12 proposals from Hegotá’s current scope and gave four other candidates two more weeks to build support.

EIP-8141 Confirmed as Hegotá’s Execution Headliner

Ethereum developers formally selected EIP-8141 as Hegotá’s execution-layer headliner and moved the proposal to Scheduled for Inclusion. The proposal may also allow users to pay transaction fees using stablecoins or other tokens, provided the required payment logic is built around the new transaction structure.

EtherWorld explored this possibility in Ethereum’s 2027 Upgrade Plans Stablecoin Gas Payments. The confirmation follows several weeks of debate over Ethereum’s preferred account abstraction design.

Developers were also considering how Frames would interact with EIP-8130, an account abstraction design being explored within the Layer 2 ecosystem. Supporting significantly different transaction systems across Ethereum L1 and its rollups could increase complexity for wallets, explorers, SDKs, paymasters and infrastructure providers.

The preferred direction is therefore greater compatibility between the two approaches. Even if L1 and Layer 2 networks eventually use different transaction formats, developers want users to retain the same account and address across both environments.

The Ethereum Foundation Protocol Cluster’s recent evaluation of 62 Hegotá proposals strengthened the case for Frames. As covered in Ethereum Foundation Ranks 62 EIPs for Hegotá, EIP-8141 and FOCIL were the only proposals placed in the highest-priority tier.

The decision does not mean the EIP-8141 specification is complete. Developers are still refining important parts of the design. However, headliner status gives client teams a shared direction around which implementation, testing and supporting proposals can be organised.

EIP-8173, Foundations of EVM Control Flow, will serve as a meta proposal around the broader Frames architecture and will not require a separate inclusion decision. EtherWorld’s Hegotá upgrade resource hub tracks the upgrade’s headliners, governance process and changing list of candidate EIPs.

The Besu teams ranking of the proposed EIPs for Hegota: pic.twitter.com/KYBkgoGvWH

— Besu, an LF Decentralized Trust project (@Besu_eth) September 10, 2026

EIP-8253 Will Not Be Added to Glamsterdam

Ethereum developers decided not to add EIP-8253 to Glamsterdam because the upgrade is too far into development and testing to safely accept another feature. The proposal would increase the nonce of 28 inactive accounts that contain non-zero storage.

These unusual accounts are remnants of earlier Ethereum behaviour and complicate assumptions used by newer state-management mechanisms. EIP-8253 was proposed as a replacement for EIP-7610, which had already been Declined for Inclusion.

Supporters argued that the new approach offered a narrowly targeted solution and could complement EIP-7928, the Block-Level Access Lists proposal included in Glamsterdam. Client teams generally agreed that cleaning up these accounts would be useful.

The disagreement was not about the problem itself, but whether solving it justified changing Glamsterdam at such a late stage. The upgrade has already passed through several dedicated development networks and entered broader, more production-like testing.

EtherWorld’s coverage of the Platåberget testnet explains how developers are now testing interactions between ePBS, Block-Level Access Lists, gas repricing and builder infrastructure. Adding EIP-8253 would require more than inserting a small specification change.

Execution clients would need to update their implementations, test interoperability and confirm that the new behaviour does not create unexpected interactions with existing Glamsterdam features. That additional work could disrupt the fork’s stabilisation process. Developers therefore chose to protect Glamsterdam’s current scope.

EIP-8253 has not been permanently rejected. Developers also considered a request to schedule it for Hegotá, but deferred that decision. It may return during a later scoping discussion once client teams have more time to evaluate its priority against other candidates.

Twelve Proposals Removed from Hegotá’s Current Scope

Marking a proposal Declined for Inclusion, or DFI, does not declare the underlying idea permanently invalid. It means developers do not believe the proposal should consume Hegotá’s limited implementation and testing capacity in its present form.

Two account-delegation proposals were declined:

• EIP-7819, introducing a set-delegate instruction
• EIP-7851, enabling code-controlled EOA delegation

With Frames now confirmed as the headliner, these decisions indicate that developers want account-related improvements to converge around a more coherent architecture instead of introducing several overlapping mechanisms.

Four opcode and transaction proposals were also declined:

• EIP-2488, deprecating CALLCODE
• EIP-8219, adding checked arithmetic opcodes
• EIP-8182, supporting private ETH and ERC-20 transfers
• EIP-7645, aliasing ORIGIN to the sender

Developers also removed EIP-7923, which proposed linear page-based EVM memory costing. Three proposals covering state accounting and fee mechanics received the same decision: EIP-8188, EIP-8358 and EIP-8115.

EIP-8200, which proposes moving precompile functionality into the EVM, was considered promising but premature. Developers want better benchmarks for precompile replacements before committing the change to an upgrade.

EIP-7862, delayed state roots, may return after Glamsterdam or alongside future binary-trie work. EIP-7807, which would introduce SSZ execution blocks, was considered too disruptive compared with its immediate benefits.

Finally, EIP-8094, an ETH/VHash blob-aware mempool proposal, was declined because its main features have already been incorporated into sparse blob-pool work.

These decisions significantly reduce the number of proposals competing for Hegotá. They also show that client teams are evaluating candidates based on more than technical usefulness.

A similar distinction appeared when the Protocol Cluster declined EIP-8363 for Hegotá. EtherWorld’s analysis of Ethereum’s issuance debate explains why an important idea may require a broader process instead of being resolved within one fork.

Follow all Ethereum protocol calls and updates here.

Four EIPs Receive Two More Weeks

Ethereum developers delayed final decisions on four Hegotá proposals for two weeks, giving their champions time to gather evidence and address client concerns. The delayed proposals are EIP-7979, EIP-8163, EIP-8372 and EIP-8304.

Each remains under consideration, but none currently has enough support for inclusion. EIP-7979 proposes dedicated call and return opcodes for the EVM.

Before deciding its future, developers want the Solidity and Vyper compiler teams to explain whether they would integrate and use the new instructions. Compiler adoption is central to the proposal’s value.

Adding opcodes that major languages do not use would increase protocol complexity without delivering meaningful benefits to application developers. The compiler teams will therefore be invited to the next ACDE. Without stronger support, the default result is expected to be DFI.

EIP-8163, which would reserve an EXTENSION opcode, must demonstrate demand beyond Ethereum L1. Its champion has been asked to collect explicit support from Layer 2 networks and alternative Layer 1 chains before the next call.

EIP-8372, the normalized state gas limit proposal, will be evaluated alongside EIP-8368, which recalibrates calldata cost per state byte. The proposals concern the relationship between execution capacity and state growth.

Developers may need data from Glamsterdam before determining whether Ethereum should separate its state limit from the ordinary gas limit. The decision could therefore remain open until the effects of Glamsterdam’s new cost model become visible.

EIP-8304, a trustless log and transaction index, also remains undecided. Besu and Reth teams expressed interest in further discussion, giving the proposal’s champion an opportunity to resolve concerns asynchronously.

Two other candidates remain open without being part of this delayed group. EIP-8360, introducing a TCREATE opcode for ephemeral contracts, now has a confirmed champion and will enter the next Forkcast ranking pass.

EIP-8411, Fast Payload Broadcast, proposes dividing execution payloads into chunks and broadcasting them through a dedicated gossipsub topic. Because the proposal primarily affects Ethereum’s consensus layer, its inclusion request will be considered during the next ACDC call.

The result is a more disciplined Hegotá roadmap. Each candidate must now prove that it is mature, implementable and important enough to justify its place beside the fork’s headliners.

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.