clet.xyz

The Ethereum Protocol cluster has officially released its comprehensive tier list for the Hegotä upgrade, providing a unified and transparent assessment of 62 Ethereum Improvement Proposals (EIPs) under consideration. This marks a significant shift from previous per-team evaluations, offering a consolidated view of priorities and expected delivery timelines for the network’s core components. The detailed analysis, compiled through extensive collaboration across research and engineering teams, aims to guide the future development and implementation of key protocol enhancements.

The release of this unified tier list represents a pivotal moment in the consensus-building process for Ethereum’s next major network upgrade. For the first time, the Protocol cluster, comprising approximately 60 individuals from various teams, has converged on a single framework for evaluating the potential impact and feasibility of proposed changes. While Geth, a prominent Execution Layer (EL) client, will continue to publish its own client-specific tier list, this collective assessment reflects a broader consensus within the protocol development community. The priorities underpinning these classifications are further elaborated in a companion post, "EF Protocol: Current and Emerging Priorities," offering a deeper dive into the strategic direction guiding these decisions.

Understanding the Tiering Methodology

The process of categorizing these 62 EIPs involved a rigorous, multi-stage evaluation. Nine distinct teams, alongside several individual domain experts within the Protocol cluster, contributed to the assessment. A total of 16 contribution templates were filled out, with 12 participants providing definitive tier grades. Notably, some contributors focused their evaluations on EIPs within their areas of deep expertise, resulting in 397 tier grades distributed across the 62 proposals. This equates to an average of 6.4 grades per EIP, with the most debated proposals attracting up to nine distinct assessments.

Lessons learned from previous development cycles, particularly from retrospectives held during the "Glamsterdam" phase, heavily influenced the methodology. Key takeaways included 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 proposed changes. To address contested items and refine the evaluations, the cluster convened several group calls and dedicated a substantial 90-minute working session. Further details on the development and implementation of this evaluation process were outlined in a post on August 28th, providing transparency into the procedural framework.

The Scoring Mechanism

Each contributor independently assigned a tier to every EIP, utilizing a standardized scoring system: S (Superior) = 4 points, A (Advanced) = 3 points, B (Baseline) = 2 points, C (Consider) = 1 point, and D/DFI (Deferred/Declined) = 0 points. The final tier displayed for each EIP is derived from the average of these scores, with only cast grades contributing to the calculation. Abstentions were explicitly excluded from impacting a proposal’s standing. The published tier represents a "steeldog" approach, meaning it began with the aggregated grades and was then subject to EIP-by-EIP deliberation during working sessions, allowing for adjustments in either direction. Individual team grades were not made public to maintain the focus on collective consensus.

Each tier signifies distinct commitment levels from the cluster regarding delivery expectations:

• S-Tier (Must-Ship): These are critical proposals deemed essential for the upcoming Hegotä upgrade. They represent foundational improvements or indispensable features with broad consensus and minimal outstanding concerns. The cluster commits to their inclusion and delivery.
• A-Tier (Expected to Ship): Proposals in this tier are highly favored for inclusion. They offer significant benefits and have a strong case for implementation, though minor requirements or refinements might be necessary. The cluster anticipates their delivery.
• B-Tier (Conditional Inclusion): EIPs in this tier are on the cusp of inclusion. They present valuable enhancements but require specific conditions to be met or further research to be conducted before a definitive commitment can be made. The notes column details these requirements.
• C-Tier (Below the Line): These proposals are considered but face significant concerns or are deemed lower priority for the current upgrade cycle. They may be revisited in future upgrades.
• DFI-Tier (Deferred/Declined): Proposals in this DFI (Deferred/Declined) tier are not slated for inclusion in Hegotä. The notes provide specific reasons for their deferral or rejection, focusing on concerns or a lack of necessity for the current upgrade.

The commentary provided in the "Notes" column for each EIP adheres to a specific pattern. For proposals expected to ship, the notes highlight their merits and contributions. For those on the bubble (B-tier), they outline the precise requirements that would facilitate their advancement to a higher tier. For proposals deemed below the line or declined, the notes focus solely on the identified concerns.

Navigating the Hegotä Tier List

The full tier list, presented in a visually accessible format, is available on Forkcast. The tables within this article are organized by tier, and then by average score within each tier, providing a clear hierarchy of proposed improvements. The grade count alongside each average offers insight into the level of consensus achieved for each EIP.

Consensus Layer Enhancements

The Consensus Layer (CL) is undergoing significant evolution with Hegotä, focusing on critical upgrades to ensure network security, efficiency, and scalability.

• EIP-7805 (FOCIL): This proposal has been designated an "S-Tier" headliner, signifying its paramount importance for the Hegotä upgrade. FOCIL (Fulfilling On-chain Inclusion for Liveness) aims to provide users with a direct path to include eligible transactions without relying on centralized builders. This is a fundamental step towards a more decentralized and censorship-resistant network. The proposal received unanimous S-tier ratings across all participating members, underscoring its critical role. Its planned integration alongside EIP-8369 further solidifies its impact.
• EIP-8369 (VOPS Profiles for FOCIL Eligibility): Rated "A-Tier," this EIP complements FOCIL by defining the specific transactions eligible for inclusion and the verification requirements for validators. It extends the inclusion guarantees provided by FOCIL to Frame-compatible transactions, enhancing the usability and security of the network.
• EIP-8015 (Remove Deposit and eth1data Fields): This "A-Tier" proposal focuses on cleanup and deprecation, removing obsolete fields from the consensus layer. Its near-unanimous approval reflects a commitment to streamlining the protocol and reducing technical debt.
• EIP-8365 (BLS Withdrawal Credential Retirement): Also an "A-Tier" proposal, this EIP addresses the retirement of withdrawal credentials tied to cryptography that is currently considered vulnerable. It is recognized as a crucial Post-Quantum (PQ) cryptography-related item that warrants inclusion in Hegotä.
• EIP-8383 (Reduce CL Block Retention Window): This "A-Tier" EIP proposes a reduction in the Consensus Layer’s block retention window. It is viewed as a necessary adjustment to a constant that was previously identified as suboptimal, with the current safety decay constant deemed incorrect.
• EIP-8334 (Bundled Attestation Propagation): Rated "A-Tier," this proposal aims to reduce gossip load by bundling attestation propagation. With no grades below B, its mechanics are considered settled in the specification, making it a strong candidate for inclusion.
• EIP-8025 (Optional Execution Proofs): This "A-Tier" EIP integrates stateless execution changes into the canonical execution specifications. This integration is crucial for preventing work on divergent branches of the codebase, particularly in the context of zkVM development.
• EIP-8146 (Block Access List Sidecars): Classified as "B-Tier," this EIP addresses block propagation and validation. The core payload remains independent of the Block Access List (BAL) for execution, and the deadline for observation is tunable. The primary remaining task is settling the observation deadline within the specification, after which it could potentially be elevated to A-tier.
• EIP-8237 (Independent CL/EL Sync): This "B-Tier" proposal explores bandwidth savings during synchronization. Post-ePBS, payload bodies are downloaded on both layers, and skipping one could halve sync bandwidth. A simpler, non-EIP alternative is being considered, and a comparison will determine which approach is adopted.
• EIP-8198 (Quick Slots): Rated "B-Tier," this EIP has generated a split in opinions. While R&D teams supported it, Engineering teams focused on delivery rated it D, citing concerns about a cascade of retuning required for any slot-time change. To achieve A-tier status, significant work is needed, including comprehensive specifications, a prototype implementation, an in-depth assessment of downstream effects, and sign-off regarding decoupled consensus compatibility.
• EIP-8321 (Hash-Chain RANDAO): This "B-Tier" proposal is considered a sound direction but is currently sequenced incorrectly. Hardening one consensus component before the complete PQ consensus design is finalized risks rework. It will be reconsidered once the complete design is established and either adopts or extends this approach.
• EIP-8371 (RowDAS: Distributed Blob Reconstruction): This "C-Tier" proposal addresses distributed blob reconstruction. Its placement reflects a prioritization decision, weighing the immediate pain operators might feel against investing in future headroom.
• EIP-8379 (Top-up Sync): Classified as "DFI" (Deferred/Declined), this EIP related to sync and history retention has been deferred.
• EIP-7716 (Anti-Correlation Attestation Penalties): This "DFI" proposal, aimed at increasing penalties for correlated missed attestations, requires further research and community discussion. Concerns include its impact on the staker landscape, its effectiveness in reducing centralization, and edge cases in multi-client setups. It is not considered a high priority for the current fork.
• EIP-8367 (Balance Sunset for Retired BLS Validators): Another "DFI" proposal, this EIP is considered a matter of validator convenience or PQ hygiene, pending the finalization of the complete PQ consensus design.
• EIP-8243 (Batching Attestations at Source): This "DFI" EIP, related to attestation batching, is seen as aligning with the slot-structure work that decoupled consensus will undertake.
• EIP-8333 (Align Checkpoint with Epoch Boundary Block): This "DFI" proposal faced challenges when its interaction with decoupled consensus was examined, and its behavior under a consensus redesign remains unclear.
• EIP-8142 (Block-in-Blobs (BiB)): This "DFI" proposal deepens dependence on KZG structures, which is seen as counter to the path towards sharding (J*). It received unanimous negative grading.
• EIP-8148 (Custom Sweep Threshold for Validators): Primarily serving large staking operations, this "DFI" proposal is considered an operational convenience that fails to meet the necessity bar for inclusion.
• EIP-8205 (Withdrawal Credentials Preregistration): Similar to EIP-8148, this "DFI" proposal is deemed an operational convenience rather than a necessity.
• EIP-8359 (Beacon Block Reporting Field): This "DFI" proposal is considered unnecessary, as existing graffiti watermarking and node scraping suffice for current needs.
• EIP-8375 (ePBS Mandatory Burn of Execution Rewards): Reward policy is considered outside the scope of a fork-specific exercise, making this "DFI" proposal ineligible.
• EIP-8341 (Partial Execution Payload Commitments): This "DFI" proposal involves a payload commitment change with no clear ownership and unclear interaction with the ongoing consensus redesign.
• EIP-8363 (Tapered Issuance Burn): Issuance policy is also considered outside the scope of a fork-specific exercise, leading to this "DFI" classification.

Execution Layer Innovations

The Execution Layer (EL) is poised for significant advancements with Hegotä, particularly in the realm of account abstraction and transaction efficiency.

• EIP-8141 (Frame Transactions): This "S-Tier" headliner is a cornerstone of the EL enhancements for Hegotä. Frame Transactions introduce native account abstraction on security grounds, providing a pathway to Post-Quantum (PQ) signature schemes without requiring a fork for each scheme. It also enables signature aggregation for PQ verification pricing and offers a route for retiring the vulnerable k1 keys. Its integration with EIP-8250 and EIP-8272 is critical.
• EIP-3298 (Removal of Refunds): Rated "A-Tier," this proposal addresses the removal of refunds, a class of metering edge cases that proved problematic in previous forks. This cleanup aims to simplify gas accounting and prevent future complications.
• EIP-8250 (Keyed Nonces for Frame Transactions): This "A-Tier" EIP is a core component of the Frame Transactions ecosystem. Keyed nonces allow multiple users to share a single sender address for enhanced anonymity while utilizing distinct nonces, preventing transaction conflicts.
• EIP-5920 (PAY Opcode): Classified as "A-Tier," the PAY Opcode is a small but impactful addition that closes a long-standing issue: enabling value transfer without invoking recipient code. Its low surface area and high leverage make it a valuable addition.
• EIP-8272 (Recent Roots for Frame Transactions): Another "A-Tier" EIP crucial for Frames, this proposal allows private transactions to leverage recent on-chain state. This verification capability enables Frame transactions to benefit from FOCIL’s inclusion guarantees.
• EIP-8279 (Block Access List Byte Floor): This "A-Tier" EIP aims to bound worst-case block construction by establishing a floor cost for adversarial BAL pricing. Its security implications are considered alongside EIP-8131.
• EIP-8131 (Unified Transaction Content Floor): Rated "A-Tier," this EIP complements EIP-8279 by applying a floor to calldata content. It is categorized as security work, with ongoing discussion about whether it constitutes bounding or repricing.
• EIP-7906 (Transaction Assertions via State Diff Opcode): This "A-Tier" proposal allows transactions to verify outcomes before committing, mitigating risks like wallet drains and certain MEV extraction methods. It is currently in public devnet testing with Frames. Proposed narrowing is under research, focusing on arbitrary storage reads and assertions over emitted events.
• EIP-8298 (SETCODEFROM Code Reuse Instruction): As part of the k1-retirement package with EIP-8151, this "A-Tier" EIP enables a 7702-delegated account to function as a true smart-contract account, facilitating the retirement of k1 keys. It also reduces deployment costs.
• EIP-8151 (Account Code Restricted ecRecover): The counterpart to EIP-8298, this "A-Tier" EIP restricts ecRecover-based authentication once actual code resides at an address, effectively preventing retired keys from being used maliciously.
• EIP-4758 (Deactivate SELFDESTRUCT): This "A-Tier" proposal removes the final path for SELFDESTRUCT, a significant testing hazard for future EIPs. While its average score is below A, the override is based on the consensus of EVM maintenance teams who would bear the ongoing cost of the opcode.
• EIP-8253 (Bump Nonce of Zero-Nonce Storage Accounts): Rated "B-Tier," this EIP significantly simplifies the trie migration process. The question remains whether this simplification warrants an A-tier rating now or if it should be a B-tier item pending devnet sequencing.
• EIP-8077 (eth/XX: Announce Transactions with Nonce): This "B-Tier" proposal addresses the need for richer transaction announcements in the Frames-era mempool. The wire format needs to be finalized in the EIP before it can move to A-tier.
• EIP-8374 (Persist Warm Access Sets Across Reverts): Classified as "B-Tier," this EIP, coupled with EIP-8358, represents net-metering repricings that are best considered together.
• EIP-7709 (Read BLOCKHASH from Storage and Update Cost): This "B-Tier" proposal offers significant value for history-expiry initiatives. It could move to A-tier if devnet sequencing proceeds smoothly and allows for its inclusion without delays.
• EIP-7668 (Remove Bloom Filters): This "C-Tier" proposal is considered a receipt and filter change best sequenced with broader history and logs work.
• EIP-8200 (EVMification): Rated "C-Tier," this EIP requires all replacement bytecode to be audited for exact precompile behavior equivalence. Its inclusion hinges on consistent client execution of the bytecode.
• EIP-8358 (Net Gas Metering for Account Changes): This "C-Tier" proposal is coupled with EIP-8374 and currently sits a tier apart.
• EIP-7666 (EVM-ify the Identity Precompile): This "C-Tier" EIP exists to support EIP-8200 and was not independently defended.
• EIP-8116 (Replace Cumulative Receipt Fields): Similar to EIP-7668, this "C-Tier" EIP is a receipt format change best sequenced with history and logs work.
• EIP-8355 (ML-DSA Verification Precompiles): Classified as "C-Tier," this proposal enshrines a specific PQ verification scheme prematurely, ahead of dedicated cryptographic adjudication.
• EIP-8163 (Reserve EXTENSION (0xae) Opcode): This "DFI" proposal involves a reserved opcode for which no committed consumer is shipping with this fork. A reservation can be accommodated in future forks.
• EIP-7979 (Call and Return Opcodes for the EVM): This "DFI" proposal adds control-flow surface to a fork already managing significant headliners and their interaction testing.
• EIP-7851 (Code-Controlled EOA Delegation): An alternative account abstraction mechanic, this "DFI" proposal loses to the Frames approach on the permissionless innovation test.
• EIP-7923 (Linear, Page-Based Memory Costing): This "DFI" proposal, part of the repricing family, waits for mainnet evidence from Glamsterdam’s repricing before further metering churn.
• EIP-7973 (Warm Account Write Metering): Similar to EIP-7923, this "DFI" proposal is deferred pending further data.
• EIP-8304 (Trustless Log and Transaction Index): This "DFI" proposal is an index format change with a broad testing surface, best addressed with history and logs work.
• EIP-8094 (eth/vhash: Blob-Aware Mempool): A mempool change with unclear interaction with the blob-scaling path, this "DFI" proposal has been deferred.
• EIP-8115 (Batch Priority Fees at End of Block): This "DFI" proposal falls under the state-repricing family and is deferred.
• EIP-8219 (Checked Arithmetic Opcodes): Similar to EIP-7923, this "DFI" proposal is deferred pending further data.
• EIP-7819 (SETDELEGATE Instruction): Another alternative account abstraction mechanic, this "DFI" proposal is superseded by the Frames approach.
• EIP-8188 (Last-Written Block for Accounts and Slots): This "DFI" proposal, part of the state-repricing family, awaits the I* trie-migration design.
• EIP-2488 (Deprecate the CALLCODE Opcode): A deprecation with no immediate urgency and potential for app-layer breakage, this "DFI" proposal received near-unanimous negative grading.
• EIP-7862 (Delayed State Root): This "DFI" proposal is considered deferred rather than disliked, as it relates to proving preparation sets.
• EIP-8182 (Private ETH and ERC-20 Transfers): This "DFI" proposal enshrines a specific privacy mechanism, whereas the Frames-based path is seen as delivering the same goal with less protocol surface.
• EIP-7645 (Alias ORIGIN to SENDER): This "DFI" proposal breaks assumptions in deployed contracts for no security gain and received unanimous negative grading.
• EIP-7807 (SSZ Execution Blocks): A formatting migration with a wide blast radius and no Hegotä dependency, this "DFI" proposal has been deferred.
• EIP-8368 (CPSB Recalibration for New Gas Limit) and EIP-8372 (Normalized State Gas Limit): These two "TBD" proposals are awaiting post-Glamsterdam mainnet data. A decision on recalibrating, normalizing, or neither will be made once this evidence is available. EIP-8368 received majority S/A support, while EIP-8372 received moderate support.

Conclusion and Future Outlook

Out of the 62 proposals evaluated for the Hegotä upgrade, two have been classified as "must-ship" (S-Tier), 15 are expected to ship (A-Tier), and 28 have been declined with clearly stated reasons. The remaining proposals fall into categories of conditional inclusion (B-Tier, with noted requirements), proposals below the line (C-Tier), and two "TBD" proposals contingent on further mainnet data. This rigorous evaluation process emphasizes not only what will be included but also what is consciously deferred or declined, highlighting a commitment to pragmatic and focused development.

For those seeking a deeper understanding of the strategic imperatives behind these classifications, the companion post, "EF Protocol: Current and Emerging Priorities," is essential reading. It outlines the Protocol cluster’s overarching vision, strategic plan, and the commitments that informed every grade assigned.

The Ethereum Protocol cluster encourages community engagement and feedback on this tier list. An upcoming Reddit AMA on r/ethereum on September 16th at 2 PM UTC will provide a platform for discussion, with a particular focus on the tier list. Champions and supporters of EIPs that were not placed in the A-tier or were declined are especially encouraged to participate and present their arguments.

Editor’s note: This article was updated on September 8, 2026, to incorporate revised tier list notes for EIP-7716, offering further clarification on areas requiring additional research and discussion.