clet.xyz

The Ethereum Protocol cluster has officially published its highly anticipated tier list for Hegotà¡¡, a pivotal release that meticulously ranks 62 Ethereum Improvement Proposals (EIPs) based on their proposed inclusion and strategic importance. This marks a significant milestone as it represents the first time the entire Protocol cluster, encompassing approximately 60 research and engineering professionals from various teams, has presented a unified view of these critical proposals, moving beyond individual team opinions. The detailed evaluation, which assigns a tier and a concise rationale to each EIP, offers unparalleled clarity on the priorities guiding the Ethereum network’s future development.

This consolidated approach signifies a maturing process within the Ethereum development community, emphasizing collaborative decision-making and transparency. While Geth, a leading execution layer client, will continue to publish its own standalone tier list, its feedback, along with that of all other Protocol cluster members and individual contributors, has been thoroughly integrated into this comprehensive assessment. The underlying priorities that informed these grades are further elaborated in a companion post titled "EF Protocol: Current and Emerging Priorities," providing essential context for the decisions made.

I. The Rigorous Tiering Process: A Collaborative Endeavor

The creation of the Hegotà¡¡ tier list was a multifaceted and rigorous process, designed to capture the collective expertise and diverse perspectives within the Ethereum Protocol cluster. A total of nine distinct teams, alongside several individual domain experts, contributed to the evaluation. Each participant completed contribution templates, resulting in 16 submissions that collectively generated 397 tier grades across the 62 EIPs under consideration. On average, each EIP received 6.4 grades, with the most contentious proposals attracting up to nine distinct evaluations.

Key lessons learned from previous retrospectives, particularly those held during the "Glamsterdam" event, heavily influenced the methodology. These lessons underscored the importance of sizing EIPs by their integration depth, recognizing how complexity compounds, acknowledging that testing surface is a scarce resource, and understanding that champions often underestimate the inherent complexity of proposed changes. To address points of contention and refine the evaluations, the cluster convened several group calls and a dedicated 90-minute working session. A detailed account of the process, including the August 28th procedural post, offers further insights into the meticulous steps taken.

The Scoring Mechanism: A Nuanced Approach to Prioritization

The scoring system employed for the Hegotà¡¡ tier list was designed for nuance and clarity. Each contributor independently assigned a tier to each EIP using a point system: S (4 points), A (3 points), B (2 points), C (1 point), and D/DFI (0 points). The average score was calculated based on the grades cast, with abstentions intentionally excluded from the calculation to avoid penalizing proposals that may not have garnered broad consensus or direct feedback. The "steelman" tier assigned to each EIP in the publication began with these average grades and was subsequently debated and refined EIP-by-EIP during the working sessions, allowing for adjustments in both directions. Crucially, individual per-team grades were not publicly disclosed, maintaining the focus on the collective consensus.

Each tier level signifies distinct delivery expectations for the cluster:

• S Tier: These are considered "headliners" or "must-ship" proposals, indicating a strong consensus for immediate implementation.
• A Tier: Proposals in this tier are strongly recommended for inclusion and are expected to ship, often with minor conditions or clarifications.
• B Tier: These EIPs are on the "bubble." Their inclusion is contingent upon meeting specific, clearly defined requirements that would elevate them to the A tier.
• C Tier: Proposals in this tier face significant concerns and are generally not expected to ship in the current iteration. The notes accompanying these EIPs detail the specific issues that would need to be addressed.
• DFI (Declined/Further Investigation): These EIPs are declined for various reasons, with the accompanying notes outlining the concerns that led to this decision.

The structure of the notes column in the published tier list table is deliberately patterned to provide immediate clarity. For proposals expected to ship (S and A tiers), the notes highlight their merits and strategic importance. For proposals on the bubble (B tier), they specify the precise requirements needed for an upgrade. For proposals below the line (C and DFI tiers), the notes focus solely on the concerns that led to their classification.

II. The Hegotà¡¡ Tier List: A Detailed Breakdown

The full tier list, presented visually for comprehensive understanding, is available on Forkcast. The tables below are meticulously sorted by tier, and then by average score within each tier, offering a clear hierarchical view of the proposed improvements. The grade count, indicating the number of evaluations received for each EIP, is displayed alongside the average score.

Consensus Layer: Strengthening the Network’s Foundation

The consensus layer proposals are crucial for the fundamental operation and security of the Ethereum network. This section of the tier list reveals a focus on enhancing inclusion guarantees, refining staking functionalities, and optimizing network performance.

• EIP-7805 (FOCIL): This EIP is designated as an "S" tier "headliner," unanimously recognized for its critical role in providing users with a direct path to include eligible transactions without relying on centralized builders. Its inclusion is tightly coupled with EIP-8369.
• EIP-8369 (VOPS Profiles for FOCIL Eligibility): Ranked "A" tier, this proposal defines the eligibility criteria for FOCIL and the verification requirements for validators, effectively extending inclusion guarantees to the Frames ecosystem.
• EIP-8015 (Remove Deposit and eth1data Fields): This "A" tier EIP addresses cleanup by removing obsolete fields with no downstream dependencies, reflecting a drive towards code efficiency and maintainability.
• EIP-8365 (BLS Withdrawal Credential Retirement): Also in the "A" tier, this proposal begins the process of retiring withdrawal credentials tied to vulnerable cryptography, addressing a significant security concern.
• EIP-8383 (Reduce CL Block Retention Window): This "A" tier EIP proposes an adjustment to the block retention window, reflecting a necessary correction to an earlier constant choice.
• EIP-8334 (Bundled Attestation Propagation): Rated "A" tier, this EIP aims to reduce gossip load by bundling attestation propagation, with minimal impact on the network.
• EIP-8025 (Optional Execution Proofs): Another "A" tier EIP, it integrates stateless-execution changes into canonical execution specifications, aiming to streamline zkVM development.
• EIP-8146 (Block Access List Sidecars): Classified as "B" tier, this proposal focuses on block propagation and validation. While the payload remains independent, the deadline is observation-only. The note indicates that settling the observation deadline in the specification would strengthen its case for an "A" tier.
• EIP-8237 (Independent CL/EL Sync): This "B" tier EIP explores bandwidth savings in synchronization by allowing independent CL/EL sync. A simpler alternative might achieve similar gains, requiring a comparative analysis.
• EIP-8198 (Quick Slots): Rated "B" tier, this proposal addresses consensus and fork choice. Engineering teams expressed concerns about retuning cascades, and an "A" tier rating would require significant specification work, prototyping, downstream impact assessment, and sign-off regarding decoupled consensus.
• EIP-8321 (Hash-Chain RANDAO): This "B" tier EIP is recognized for its sound direction but is currently out of sequence, with concerns about potential rework if implemented before a complete post-quantum (PQ) consensus design.
• EIP-8371 (RowDAS: Distributed Blob Reconstruction): Classified as "C" tier, this EIP focuses on data availability and proofs, with its priority being debated based on current operator pain points versus future headroom investment.
• DFI Tier Proposals: A significant number of EIPs fall into the DFI tier, indicating they are declined for current inclusion or require further investigation. These include EIP-7716 (Anti-Correlation Attestation Penalties), EIP-8367 (Balance Sunset for Retired BLS Validators), EIP-8243 (Batching Attestations at Source), 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). The notes accompanying these proposals detail specific concerns related to ecosystem impact, sequencing with other development efforts, or a lack of immediate necessity.

Execution Layer: Enhancing Functionality and Security

The execution layer proposals are focused on improving smart contract capabilities, transaction processing, and overall network security, with a strong emphasis on account abstraction and repricing mechanisms.

• EIP-8141 (Frame Transactions): This "S" tier "headliner" is a cornerstone of the execution layer roadmap, introducing native account abstraction for enhanced security and paving the way for post-quantum signature schemes. Its implementation is linked with EIP-8250 and EIP-8272.
• EIP-3298 (Removal of Refunds): Ranked "A" tier, this EIP addresses the critical need to eliminate refunds, a source of significant complexity and potential issues in past forks.
• EIP-8250 (Keyed Nonces for Frame Transactions): Another "A" tier EIP, this proposal is a core component of the Frames framework, enabling better anonymity and preventing transaction blocking by allowing multiple users to share a sender with unique nonces.
• EIP-5920 (PAY Opcode): This "A" tier EIP introduces a new opcode for value transfer without invoking recipient code, offering a low-surface, high-leverage improvement.
• EIP-8272 (Recent Roots for Frame Transactions): Classified as "A" tier, this EIP allows private transactions to leverage recent on-chain state within the Frames ecosystem, thereby benefiting from FOCIL’s inclusion guarantees.
• EIP-8279 (Block Access List Byte Floor): Rated "A" tier, this proposal aims to bound worst-case block construction by establishing a floor cost for Block Access List (BAL) pricing.
• EIP-8131 (Unified Transaction Content Floor): This "A" tier EIP complements EIP-8279 by applying a similar floor to calldata content, with its classification as security work or repricing remaining a subject of discussion.
• EIP-7906 (Transaction Assertions via State Diff Opcode): An "A" tier EIP, it allows transactions to verify prior state changes, preventing security vulnerabilities. Research is ongoing to narrow its scope to emitted events and BAL-touched slots.
• EIP-8298 (SETCODEFROM Code Reuse Instruction): This "A" tier EIP is part of the post-quantum cryptography retirement strategy, enabling delegated accounts to become true smart contract accounts and reducing deployment costs.
• EIP-8151 (Account Code Restricted ecRecover): Paired with EIP-8298, this "A" tier EIP restricts ecRecover-based authentication once real code is established at an address, contributing to the retirement of vulnerable keys.
• EIP-4758 (Deactivate SELFDESTRUCT): While rated "A" tier with an average score below the threshold, the Engineering teams responsible for EVM maintenance have advocated for its inclusion due to its role in simplifying testing and future EIP development.
• EIP-8253 (Bump Nonce of Zero-Nonce Storage Accounts): This "B" tier EIP significantly simplifies trie migration. Its upgrade to "A" tier hinges on devnet sequencing proving ample room for its inclusion.
• EIP-8077 (eth/XX: Announce Transactions with Nonce): A "B" tier proposal, this EIP addresses the need for richer transaction announcements in the Frames era. A finalized wire format could elevate it to "A" tier.
• EIP-8374 (Persist Warm Access Sets Across Reverts): This "B" tier EIP, coupled with EIP-8358, aims to implement sensible net-metering repricings.
• EIP-7709 (Read BLOCKHASH from Storage and Update Cost): A "B" tier EIP, its move to "A" tier depends on smooth devnet sequencing and the availability of space.
• EIP-7668 (Remove Bloom Filters): Classified as "C" tier, this proposal is considered a receipt and filter format change that would be best sequenced with broader history and logs work.
• EIP-8200 (EVMification): Another "C" tier proposal, it requires meticulous auditing of replacement bytecodes to ensure exact precompile behavior, with its inclusion tied to EIP-7666.
• EIP-8358 (Net Gas Metering for Account Changes): A "C" tier EIP, it is coupled with EIP-8374.
• 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 proposal is a receipt format change best sequenced with history and logs work.
• EIP-8355 (ML-DSA Verification Precompiles): Rated "C" tier, this EIP is seen as a premature standardization of a specific post-quantum verification scheme.
• DFI Tier Proposals: Several EIPs are in the DFI tier, including EIP-8163 (Reserve EXTENSION (0xae) Opcode), EIP-7979 (Call and Return Opcodes for the EVM), EIP-7851 (Code-Controlled EOA Delegation), EIP-7923 (Linear, Page-Based Memory Costing), EIP-7973 (Warm Account Write Metering), EIP-8304 (Trustless Log and Transaction Index), EIP-8094 (eth/vhash: Blob-Aware Mempool), EIP-8115 (Batch Priority Fees at End of Block), EIP-8219 (Checked Arithmetic Opcodes), EIP-7819 (SETDELEGATE Instruction), EIP-8188 (Last-Written Block for Accounts and Slots), EIP-2488 (Deprecate the CALLCODE Opcode), EIP-7862 (Delayed State Root), and EIP-8182 (Private ETH and ERC-20 Transfers). Concerns range from lack of immediate need and potential breakage to being alternative mechanics that lose out to preferred approaches or requiring further data from post-Glamsterdam mainnet.
• TBD Tier Proposals: EIP-8368 (CPSB Recalibration for New Gas Limit) and EIP-8372 (Normalized State Gas Limit) are marked "TBD," indicating they are awaiting post-Glamsterdam mainnet data for a final decision on recalibration, normalization, or inaction.

III. Closing Thoughts: A Strategic Vision for Ethereum’s Future

The Hegotà¡¡ tier list represents a significant achievement in transparent and collaborative development for the Ethereum network. Of the 62 proposals evaluated, 2 are designated as "must-ship" (S tier), 15 are expected to ship (A tier), and 28 are declined with clear reasoning provided. The remaining proposals are distributed among B-tier (8 proposals requiring specific conditions), C-tier (7 proposals below the line), and TBD (2 proposals awaiting further data). This meticulous categorization highlights not only what the Protocol cluster intends to implement but also, crucially, what it has chosen to decline and why.

The companion document, "EF Protocol: Current and Emerging Priorities," is essential reading for anyone seeking to understand the overarching strategy, plan, and commitments that underpin every grade assigned in this tier list. It serves as the "north star" guiding the Protocol cluster’s efforts.

The Ethereum Protocol cluster is actively encouraging community engagement and feedback. A Reddit AMA (Ask Me Anything) is scheduled for September 16th at 2 PM UTC on r/ethereum, specifically dedicated to discussing the tier list. Champions and supporters of EIPs that were not ranked in the A tier or were declined are particularly encouraged to participate and voice their perspectives. Questions can be submitted in advance via a dedicated form.

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