EF Protocol: The Hegotá EIP Opinion Post and Tier List

This is the EF Protocol cluster’s tier list for Hegotá. We evaluated the 62 EIPs proposed for inclusion, each with a tier and a short note on the grade.

It is the first time the cluster has published one unified view rather than per-team opinions. Geth, of course, being an EL client will still ship their own standalone tier list. However, they and the rest of the Protocol cluster (about 60 people in total) across research and engineering worked together to include their feedback in this post as a datapoint along with that of every other team and individual contributor that decided to participate.

The priorities that produced these grades are in the companion post, EF Protocol: Current and Emerging Priorities.

I. How we tiered

All nine teams plus several individual domain experts across the cluster filled out contribution templates, 16 in total. Twelve provided tier grades, and several of those graded only EIPs where they had deep expertise. The result is 397 tier grades across 62 EIPs, an average of 6.4 grades per EIP with the most-discussed proposals drawing 9 grades.

Two retrospectives on Glamsterdam supplied several lessons (size an EIP by its integration depth; complexity compounds; testing surface is the scarce resource; champions often underestimate complexity). Half a dozen group calls and a 90-minute working session covered the contested items. The August 28 process post provides a bit more detail.

The scoring

Each contributor tiered each EIP independently: S = 4, A = 3, B = 2, C = 1, D/DFI = 0. Averages count cast grades only; an abstention never counts against a proposal. The published tier is a steelman. It started from the grades and was argued EIP-by-EIP in the working session, with movements in both directions. Per-team grades are not published.

Each level of the tiered scoring ladder commits the cluster to delivery expectations:

• S - Must ship. Defines the fork. If an S item is at risk, the schedule adjusts before the scope does.

S - Must ship. Defines the fork. If an S item is at risk, the schedule adjusts before the scope does.

• A - High priority, expected to ship. Committed alongside S-tier unless delivery reality forces a cut, and only cut before any S item is touched. Everything below S and A-tier must be evaluated once devnets with all S and A-tier EIPs are functional and stable.

A - High priority, expected to ship. Committed alongside S-tier unless delivery reality forces a cut, and only cut before any S item is touched. Everything below S and A-tier must be evaluated once devnets with all S and A-tier EIPs are functional and stable.

• B - On the bubble, included individually. Never admitted in bulk. Each EIP to be considered for inclusion one at a time once devnets with all S and A-tier EIPs are functional and stable and time remains before moving to I*. Important to note, most B-tiered EIPs carry 3 explicit requirements: a prototype, a sign-off, and a settled specification.

B - On the bubble, included individually. Never admitted in bulk. Each EIP to be considered for inclusion one at a time once devnets with all S and A-tier EIPs are functional and stable and time remains before moving to I*. Important to note, most B-tiered EIPs carry 3 explicit requirements: a prototype, a sign-off, and a settled specification.

• C - Below the line, not disqualified. First candidates for reconsideration if devnets containing S-, A-, and B-tier EIPs ship cleanly and time remains before moving to I*.

C - Below the line, not disqualified. First candidates for reconsideration if devnets containing S-, A-, and B-tier EIPs ship cleanly and time remains before moving to I*.

• DFI - Declined for inclusion. Every DFI carries a structural rationale, like that the EIP is antithetical to CROPS, a security risk, too prescriptive, introduces an intermediary or chokepoint, breaks backward compatibility, or endangers the path to J*.

DFI - Declined for inclusion. Every DFI carries a structural rationale, like that the EIP is antithetical to CROPS, a security risk, too prescriptive, introduces an intermediary or chokepoint, breaks backward compatibility, or endangers the path to J*.

• TBD - Deliberately unranked. Held back until mainnet data provides answers to questions we cannot answer today.

TBD - Deliberately unranked. Held back until mainnet data provides answers to questions we cannot answer today.

The note in the notes column of the table for each EIP below should adhere to the following pattern: For anything we expect to ship, the note provides the merits. For anything on the bubble, it names the specific requirements that would move it up a tier. For anything below the line or declined, it gives the concerns and nothing else.

II. The tier list

The full list as a single visual is on Forkcast. The tables below are sorted by tier, then by average within each tier. Read the grade count beside every average.

Consensus layer

Execution layer

A few notes on the A tier

• Headliner packages: EIP-7805 (FOCIL) ships with EIP-8369 (VOPS Profiles for FOCIL Eligibility). EIP-8141 (Frame Transactions) ships with EIP-8250 (Keyed Nonces for Frame Transactions) and EIP-8272 (Recent Roots for Frame Transactions) as the Frames core. Delivering both headliners safely, and testing the interaction between them, is the fork’s core engineering commitment.

Headliner packages: EIP-7805 (FOCIL) ships with EIP-8369 (VOPS Profiles for FOCIL Eligibility). EIP-8141 (Frame Transactions) ships with EIP-8250 (Keyed Nonces for Frame Transactions) and EIP-8272 (Recent Roots for Frame Transactions) as the Frames core. Delivering both headliners safely, and testing the interaction between them, is the fork’s core engineering commitment.

• Extension package: EIP-7906 (Transaction Assertions via State Diff Opcode), EIP-8298 (SETCODEFROM Code Reuse Instruction), and EIP-8151 (Account Code Restricted ecRecover). The first hardens transactions directly; the other two give an account a complete route away from k1 keys.

Extension package: EIP-7906 (Transaction Assertions via State Diff Opcode), EIP-8298 (SETCODEFROM Code Reuse Instruction), and EIP-8151 (Account Code Restricted ecRecover). The first hardens transactions directly; the other two give an account a complete route away from k1 keys.

A few notes on the B and C tiers

• Consensus layer EIPs blocked by additional requirements: EIP-8198 (Quick Slots) has the most demanding requirements on the list, including specifications covering all expected changes to the core protocol, a prototype implementing the full specification, an in-depth assessment of downstream effects across the ecosystem, and sign-off that it does not complicate decoupled consensus, which cannot be determined until that specification exists. The bar is set where it is because while the diff is small, the change is not; slot time is load-bearing for timing assumptions across the protocol and the ecosystem, and discovering breakage late is how forks get delayed. EIP-8321 (Hash-Chain RANDAO) needs the complete PQ consensus design. EIP-8146 (Block Access List Sidecars) needs its observation deadline settled in specification. EIP-8237 (Independent CL/EL Sync) needs a cost comparison against simpler alternatives and a delivery owner.

Consensus layer EIPs blocked by additional requirements: EIP-8198 (Quick Slots) has the most demanding requirements on the list, including specifications covering all expected changes to the core protocol, a prototype implementing the full specification, an in-depth assessment of downstream effects across the ecosystem, and sign-off that it does not complicate decoupled consensus, which cannot be determined until that specification exists. The bar is set where it is because while the diff is small, the change is not; slot time is load-bearing for timing assumptions across the protocol and the ecosystem, and discovering breakage late is how forks get delayed. EIP-8321 (Hash-Chain RANDAO) needs the complete PQ consensus design. EIP-8146 (Block Access List Sidecars) needs its observation deadline settled in specification. EIP-8237 (Independent CL/EL Sync) needs a cost comparison against simpler alternatives and a delivery owner.

• Execution layer EIPs blocked by additional requirements: EIP-8253 (Bump Nonce of Zero-Nonce Storage Accounts) is under consideration to move to A-tier. It is not strictly required for the trie migration, and it simplifies the migration significantly, and the review will decide how much that simplification is worth. EIP-8077 needs a settled wire format. EIP-8374 (Persist Warm Access Sets Across Reverts) and EIP-8358 (Net Gas Metering for Account Changes) are one net-metering package and cannot carry different grades; resolving that is an open review item.

Execution layer EIPs blocked by additional requirements: EIP-8253 (Bump Nonce of Zero-Nonce Storage Accounts) is under consideration to move to A-tier. It is not strictly required for the trie migration, and it simplifies the migration significantly, and the review will decide how much that simplification is worth. EIP-8077 needs a settled wire format. EIP-8374 (Persist Warm Access Sets Across Reverts) and EIP-8358 (Net Gas Metering for Account Changes) are one net-metering package and cannot carry different grades; resolving that is an open review item.

• TBD EIPs: EIP-8368 (CPSB Recalibration for New Gas Limit) and EIP-8372 (Normalized State Gas Limit) shall be evaluated together once Glamsterdam hits mainnet and the impact of related state repricings can be evaluated.

TBD EIPs: EIP-8368 (CPSB Recalibration for New Gas Limit) and EIP-8372 (Normalized State Gas Limit) shall be evaluated together once Glamsterdam hits mainnet and the impact of related state repricings can be evaluated.

A few notes on the DFI block

• The unanimous CL DFI block: EIP-8363 (Tapered Issuance Burn) and EIP-8375 (ePBS Mandatory Burn of Execution Rewards) belong to a broader issuance process. EIP-8148, EIP-8205, and EIP-8359 are operational conveniences that primarily serve large staking operations and fail the necessity bar. EIP-8142 (Block-in-Blobs) deepens KZG dependence against the path to J*.

The unanimous CL DFI block: EIP-8363 (Tapered Issuance Burn) and EIP-8375 (ePBS Mandatory Burn of Execution Rewards) belong to a broader issuance process. EIP-8148, EIP-8205, and EIP-8359 are operational conveniences that primarily serve large staking operations and fail the necessity bar. EIP-8142 (Block-in-Blobs) deepens KZG dependence against the path to J*.

• One proposal deserves a direct note: EIP-8363 (Tapered Issuance Burn). The unanimous DFI is not a judgement on the merits of the proposal. Issuance policy touches every staker, every holder, and the network’s long-run security budget; at this stage, EF Protocol does not consider itself the right and sole body to give direction on it, and a fork scoping exercise is not the right venue to settle it. We would expect this to be carried forward via a multi-node ecosystem process with the technical rigour and breadth of engagement the question deserves, and we intend to participate in such a process.

One proposal deserves a direct note: EIP-8363 (Tapered Issuance Burn). The unanimous DFI is not a judgement on the merits of the proposal. Issuance policy touches every staker, every holder, and the network’s long-run security budget; at this stage, EF Protocol does not consider itself the right and sole body to give direction on it, and a fork scoping exercise is not the right venue to settle it. We would expect this to be carried forward via a multi-node ecosystem process with the technical rigour and breadth of engagement the question deserves, and we intend to participate in such a process.

III. In closing

Of the 62 proposals evaluated, 2 are must-ship, 15 are expected to ship, and 28 are declined with stated reasons. Of the 15 remaining, 8 are B-tier proposals with noted requirements for inclusion, 7 are C-tier proposals below the line, and 2 TBD proposals waiting on mainnet evidence. Success here is determined as much by what we decline as by what we ship.

If you read one thing beyond this post, please read the companion: EF Protocol: Current and Emerging Priorities, which includes the Protocol cluster’s north star, plan, and the commitments that produced every grade above.

And if a grade above deserves a challenge, we’d love to hear the pushback. We're hosting a Reddit AMA on r/ethereum on September 16 at 2pm UTC, and the tier list is exactly what we expect to be asked about. Submit questions ahead of time using the form here. Champions and supporters of non-A-tier EIPs and declined EIPs are especially welcome.

*Editor's note: This article was updated on Sep. 8 2026 to revise the tier list notes for EIP-7716, adding additional clarification on where further research and discussion is needed.