The Ethereum Foundation’s Protocol cluster has unveiled its comprehensive tier list for the upcoming Hegotλ hard fork, offering a unified perspective on the 62 Ethereum Improvement Proposals (EIPs) under consideration. This marks a significant shift from previous per-team evaluations, presenting a consolidated view derived from the collective expertise of approximately 60 researchers and engineers. The companion post, "EF Protocol: Current and Emerging Priorities," details the strategic underpinnings that guided these tiered assessments.
This initiative represents a concerted effort to bring clarity and consensus to the complex process of EIP prioritization for future network upgrades. The Protocol cluster, comprising nine distinct teams and several individual domain experts, collectively contributed to this evaluation. A total of 16 contribution templates were submitted, with 12 providing explicit tier grades for various EIPs, often focusing on areas of their deepest expertise. This rigorous process resulted in 397 tier grades distributed across the 62 EIPs, averaging over six grades per proposal, with the most debated EIPs attracting as many as nine individual assessments.
The methodology behind this tiered ranking system was refined through two retrospectives held in Glamsterdam. Key lessons emerged, emphasizing the importance of sizing EIPs by their integration depth, understanding how complexity compounds, recognizing testing surface as a scarce resource, and acknowledging that champions often underestimate the inherent complexity of their proposals. Further refinement occurred through several group calls and a dedicated 90-minute working session aimed at resolving contentious items. Details of this structured process were previously outlined in an August 28 post.
The Scoring Mechanism and Tiered Expectations
The scoring system employed a straightforward yet effective method: S (Superior) was assigned 4 points, A (Advanced) 3 points, B (Basic) 2 points, C (Core) 1 point, and D/DFI (Deferred/Declined for Inclusion) 0 points. The final tier for each EIP is based on the average of the cast grades, with abstentions having no bearing on the outcome. The published tier represents a "steelman" – the strongest possible interpretation of the graded assessments – which was then further debated and refined EIP-by-EIP during the working sessions, allowing for adjustments in both directions. Individual team grades remain private.
Each tier carries specific delivery expectations for the Protocol cluster:
- S-Tier: These are considered "must-ship" proposals, forming the foundational elements of the Hegotλ hard fork.
- A-Tier: These are "expected to ship" proposals, representing significant advancements and improvements.
- B-Tier: These proposals are on the "bubble" and require specific conditions or further development to be elevated to A-tier. The notes accompanying these EIPs clearly outline the necessary requirements for such an upgrade.
- C-Tier: These proposals are "below the line" and are not prioritized for inclusion in the current fork.
- DFI-Tier: These are "declined for inclusion" proposals, with specific concerns or reasons for their rejection detailed in the accompanying notes.
The notes column for each EIP adheres to a strict pattern: for proposals expected to ship, it highlights their merits. For those on the bubble, it specifies the exact requirements for a tier upgrade. For declined proposals, it solely enumerates the concerns.
II. The Tier List: A Deep Dive into Hegotλ’s Proposed Upgrades
The full, dynamic tier list, offering an interactive visualization of the EIPs and their assessments, is available on Forkcast. The following tables, categorized by layer, present the EIPs sorted by their assigned tier and then by their average score within each tier. The grade count for each EIP is provided alongside its average score.
Consensus Layer
The Consensus Layer (CL) proposals are critical for the foundational stability and advancement of the Ethereum network. Among the evaluated EIPs, EIP-7805 (FOCIL) has been designated as an S-tier "Headliner." FOCIL aims to provide users with a direct path to include eligible transactions without reliance on centralized builders, achieving unanimous S-tier support and slated for inclusion with EIP-8369.
EIP-8369 (VOPS Profiles for FOCIL Eligibility), an A-tier proposal, complements FOCIL by defining transaction eligibility and validator verification requirements, thereby extending inclusion guarantees to Frames. Similarly, EIP-8015 (Remove Deposit and eth1data Fields), another A-tier proposal, addresses cleanup by removing defunct fields with no downstream dependencies, garnering near-unanimous approval.
EIP-8365 (BLS Withdrawal Credential Retirement), also A-tier, proactively begins the retirement of withdrawal credentials tied to vulnerable cryptography, a crucial step for long-term security. EIP-8383 (Reduce CL Block Retention Window), an A-tier proposal with two grades cast, addresses a constant adjustment in the safety-decay constant. EIP-8334 (Bundled Attestation Propagation), an A-tier proposal, aims to reduce gossip load by bundling attestations, with no grades falling below B. EIP-8025 (Optional Execution Proofs), an A-tier proposal, upstream stateless-execution changes into canonical execution specifications, fostering more efficient zkVM development.
Several B-tier proposals require further refinement. EIP-8146 (Block Access List Sidecars), B-tier, focuses on ensuring payload independence from the Block Access List (BAL) and defines observation deadlines. EIP-8237 (Independent CL/EL Sync), B-tier, explores bandwidth savings by skipping payload body downloads on one layer post-ePBS, with a simpler alternative also being considered. EIP-8198 (Quick Slots), B-tier, faces significant hurdles, with engineering teams rating it D due to the cascading retuning required for any slot-time change. To achieve an A-tier, it necessitates comprehensive specifications, a prototype implementation, in-depth downstream effect assessments, and sign-off regarding decoupled consensus. EIP-8321 (Hash-Chain RANDAO), B-tier, is deemed to be in the wrong sequencing, risking rework by hardening one consensus component before the complete Post-Quantum (PQ) consensus design is finalized.
In the C-tier, EIP-8371 (RowDAS: Distributed Blob Reconstruction) is prioritized for its potential to address operator reconstruction pain, though its urgency is debated.
A substantial number of EIPs have been placed in the DFI-tier, indicating they are deferred or declined for inclusion in Hegotλ. These include EIP-8379 (Top-up Sync), EIP-7716 (Anti-Correlation Attestation Penalties), which requires further research on its impact on the staker landscape and centralization forces, EIP-8367 (Balance Sunset for Retired BLS Validators), which awaits the complete PQ consensus design, and EIP-8243 (Batching Attestations at Source), which is considered to belong with decoupled consensus work.
Proposals like EIP-8333 (Align Checkpoint with Epoch Boundary Block), EIP-8142 (Block-in-Blobs (BiB)), EIP-8148 (Custom Sweep Threshold for Validators), EIP-8205 (Withdrawal Credentials Preregistration), EIP-8359 (Beacon Block Reporting Field), EIP-8375 (ePBS Mandatory Burn of Execution Rewards), EIP-8341 (Partial Execution Payload Commitments), and EIP-8363 (Tapered Issuance Burn) have all been declined for various reasons, including unclear interactions with consensus redesign, operational convenience, belonging to broader ecosystem processes, or a lack of immediate necessity for the current fork.
Execution Layer
The Execution Layer (EL) proposals also present significant advancements for the Ethereum network. Leading the charge is EIP-8141 (Frame Transactions), an S-tier "Headliner" for the EL. Frame Transactions aim to introduce native account abstraction on security grounds, paving the way for PQ signature schemes without requiring a fork per scheme, enabling aggregation for PQ verification pricing, and providing a path to retire k1 keys. This EIP is slated to ship alongside EIP-8250 and EIP-8272.
Several A-tier proposals promise substantial improvements. EIP-3298 (Removal of Refunds) addresses critical metering edge cases that proved problematic in previous forks. EIP-8250 (Keyed Nonces for Frame Transactions) and EIP-8272 (Recent Roots for Frame Transactions) are core components of the Frame Transactions ecosystem, enhancing anonymity and enabling private transactions to leverage FOCIL’s inclusion guarantees.
EIP-5920 (PAY Opcode) introduces a new opcode for value transfer without invoking recipient code, offering a low-surface, high-leverage enhancement. EIP-8279 (Block Access List Byte Floor) and EIP-8131 (Unified Transaction Content Floor) are a pair of A-tier proposals focused on bounding worst-case block construction and transaction pricing, respectively, addressing security concerns.
EIP-7906 (Transaction Assertions via State Diff Opcode), an A-tier proposal, enables transactions to verify prior states, preventing wallet drains and certain MEV extractions. Currently in testing on a public devnet, proposed narrowing is under research to focus on arbitrary storage reads. EIP-8298 (SETCODEFROM Code Reuse Instruction) and EIP-8151 (Account Code Restricted ecRecover) form a crucial A-tier package aimed at retiring k1 keys by allowing delegated accounts to become true smart-contract accounts.
EIP-4758 (Deactivate SELFDESTRUCT), while averaging below A-tier, has been placed there due to engineering consensus on the importance of removing this testing hazard.
In the B-tier, EIP-8253 (Bump Nonce of Zero-Nonce Storage Accounts) significantly simplifies trie migration. EIP-8077 (eth/XX: Announce Transactions with Nonce) seeks to enrich mempool announcements for the Frame era, pending a finalized wire format. EIP-8374 (Persist Warm Access Sets Across Reverts) and EIP-7709 (Read BLOCKHASH from Storage and Update Cost) are coupled repricing proposals with potential for A-tier if devnet sequencing proves smooth.
C-tier proposals include EIP-7668 (Remove Bloom Filters), considered best sequenced with broader history and logs work, and EIP-8200 (EVMification) and EIP-7666 (EVM-ify the Identity Precompile), which require rigorous auditing to ensure bytecode matches precompile behavior. EIP-8358 (Net Gas Metering for Account Changes) is coupled with EIP-8374. EIP-8355 (ML-DSA Verification Precompiles) is considered premature standardization of a specific PQ verification scheme.
A significant portion of EL proposals fall into the DFI-tier, indicating they are deferred or declined. These include EIP-8163 (Reserve EXTENSION (0xae) Opcode), which lacks a committed consumer for the current fork, and EIP-7979 (Call and Return Opcodes for the EVM), which adds control-flow surface to an already feature-rich fork.
Alternative account abstraction mechanics like EIP-7851 (Code-Controlled EOA Delegation) and EIP-7819 (SETDELEGATE Instruction) are declined in favor of the Frame approach. Repricing proposals like EIP-7923 (Linear, Page-Based Memory Costing), EIP-7973 (Warm Account Write Metering), and EIP-8182 (Last-Written Block for Accounts and Slots) are deferred pending further mainnet data. Proposals related to block and state data, such as EIP-8304 (Trustless Log and Transaction Index) and EIP-8115 (Batch Priority Fees at End of Block), are considered best sequenced with broader history and logs work. EIP-8094 (eth/vhash: Blob-Aware Mempool) has unclear interactions with the blob-scaling path. EIP-8219 (Checked Arithmetic Opcodes) is also part of the repricing family awaiting mainnet data. EIP-2488 (Deprecate the CALLCODE Opcode), a deprecation with no immediate urgency, is near-unanimously declined. EIP-7862 (Delayed State Root) is deferred but not disliked. EIP-8182 (Private ETH and ERC-20 Transfers) is declined in favor of the Frame-based approach for privacy. Finally, EIP-7645 (Alias ORIGIN to SENDER) and EIP-7807 (SSZ Execution Blocks) are declined due to breaking assumptions in deployed contracts or lacking Hegotλ dependency, respectively.
Two proposals, EIP-8368 (CPSB Recalibration for New Gas Limit) and EIP-8372 (Normalized State Gas Limit), are marked as TBD, awaiting post-Glamsterdam mainnet data to inform decisions on recalibration, normalization, or other actions.
III. In Closing: A Path Forward for Ethereum
The comprehensive evaluation of 62 EIPs for the Hegotλ hard fork has resulted in a clear prioritization framework. Of the proposals assessed, two are designated as "must-ship" (S-tier), 15 are expected to ship (A-tier), and 28 have been declined with clearly articulated reasons. The remaining EIPs are categorized as B-tier (8 proposals requiring further conditions), C-tier (7 proposals below the line), and two TBD proposals awaiting crucial mainnet data. This rigorous process highlights the commitment to not only advancing the network but also to judiciously declining proposals that do not meet the defined criteria for inclusion.
The companion post, "EF Protocol: Current and Emerging Priorities," serves as an essential read, offering insight into the Protocol cluster’s strategic direction, overarching plan, and the foundational commitments that underpin every grade assigned. This document is crucial for understanding the rationale behind the prioritization decisions.
For those who believe a grade assigned to an EIP warrants challenge, the Protocol cluster encourages open discussion. A Reddit AMA is scheduled for r/ethereum on September 16 at 2 PM UTC, providing a direct forum for community engagement. Champions and supporters of EIPs that did not achieve A-tier status or were declined are particularly encouraged to participate and voice their perspectives.
Editor’s note: This article was updated on September 8, 2026, to revise the tier list notes for EIP-7716, providing additional clarity on the need for further research and discussion.
