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.
-
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.
-
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*.
-
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
| EIP | Name | Tier | Avg (total) | Category | Notes |
|---|---|---|---|---|---|
| 7805 | FOCIL | S | 4 (7) | Headliner | Locked-in CL headliner. FOCIL gives any user a path to include an eligible transaction without relying on centralised builders. Unanimous S at full participation. Should ship with EIP-8369. |
| 8369 | VOPS Profiles for FOCIL Eligibility | A | 3.5 (4) | Frames core | Defines which transactions are eligible for FOCIL and what validators must verify, extending its inclusion guarantees to Frames. |
| 8015 | Remove Deposit and eth1data Fields | A | 3.14 (7) | Cleanup & deprecations | Removes dead deposit and eth1data fields with no downstream dependency. Near-unanimous. |
| 8365 | BLS Withdrawal Credential Retirement | A | 3 (8) | Staking features | Starts retiring withdrawal credentials tied to vulnerable cryptography now; nothing downstream depends on waiting. The one PQ item that belongs in Hegotá. |
| 8383 | Reduce CL Block Retention Window | A | 3 (2) | History and logs | A constant change, and the current safety-decay constant was the wrong choice. Two grades cast, both A. One of two write-ins evaluated alongside the Forkcast list. |
| 8334 | Bundled Attestation Propagation | A | 2.43 (7) | Attestations | Bundling attestation propagation cuts gossip load with a small surface. No grade below B; bundling mechanics are settled in specification. |
| 8025 | Optional Execution Proofs | A | 2.38 (8) | DA & proofs | Upstreams stateless-execution changes into the canonical execution specs so zkVM work stops living on divergent branches. |
| 8146 | Block Access List Sidecars | B | 2.13 (8) | Block propagation & validation | The payload stays independent of the BAL for execution, the deadline is observation-only and tunable across forks, and both objects must be available for validity, as with blobs. What remains is settling the observation deadline in specification; with that settled, the case for A-tier is strong. |
| 8237 | Independent CL/EL Sync | B | 2 (6) | Sync & history retention | The bandwidth saving is worth exploring: post-ePBS, payload bodies download on both layers, and skipping one roughly halves sync bandwidth. A simpler non-EIP alternative may capture the same win. A comparison between both options should determine which ships. |
| 8198 | Quick Slots | B | 2 (6) | Consensus & fork choice | S/A support came from R&D; the Engineering teams that focus on delivery rated it D, citing the retuning cascade behind any slot-time change. After debate, it was determined four things would be required before an A-tier could be considered: 1) specifications covering all expected changes to the core protocol 2) a prototype implementing that full specification 3) an in-depth assessment of downstream effects across the ecosystem 4) sign-off that it does not complicate decoupled consensus, which cannot be determined until that specification exists. |
| 8321 | Hash-Chain RANDAO | B | 1.57 (7) | Consensus & fork choice | Sound direction, wrong sequencing: hardening one consensus component ahead of the complete PQ consensus design risks rework. It moves when the complete design exists and either adopts or extends it. |
| 8371 | RowDAS: Distributed Blob Reconstruction | C | 2.11 (9) | DA & proofs | Priority, not principle: whether operators feel reconstruction pain today versus investing in headroom. |
| 8379 | Top-up Sync | DFI | 1 (2) | Sync & history retention | – |
| 7716 | Anti-Correlation Attestation Penalties | DFI | 0.83 (6) | Rewards & penalties | Adds slashing-logic surface for validator correlation with no CROPS or PQ contribution. Not a priority in a fork, we are trying to keep the CL scope light. |
| 8367 | Balance Sunset for Retired BLS Validators | DFI | 0.71 (7) | Staking features | Reads as validator convenience to some and PQ hygiene to others; either way it waits for the complete PQ consensus design. |
| 8243 | Batching Attestations at Source | DFI | 0.67 (9) | Attestations | No S or A grade. Attestation batching belongs with the slot-structure work decoupled consensus will redo. |
| 8333 | Align Checkpoint with Epoch Boundary Block | DFI | 0.5 (6) | Consensus & fork choice | Early support collapsed once its interaction with decoupled consensus was examined; unclear if behavior under the consensus redesign it would have to survive. |
| 8142 | Block-in-Blobs (BiB) | DFI | 0 (7) | DA & proofs | Deepens dependence on KZG structures against the path to J*. Unanimous. |
| 8148 | Custom Sweep Threshold for Validators | DFI | 0 (6) | Staking features | Operational convenience primarily serving large staking operations; fails the necessity bar. Unanimous. |
| 8205 | Withdrawal Credentials Preregistration | DFI | 0 (6) | Staking features | Same rationale as EIP-8148. Unanimous. |
| 8359 | Beacon Block Reporting Field | DFI | 0 (6) | Beacon block data | Graffiti watermarking and node scraping is sufficient for right now; fails the necessity bar. Unanimous. |
| 8375 | ePBS Mandatory Burn of Execution Rewards | DFI | 0 (6) | Rewards & penalties | Reward policy belongs to a broader ecosystem process than a fork scoping exercise. Unanimous. See EIP-8363 and the closing note. |
| 8341 | Partial Execution Payload Commitments | DFI | 0 (4) | Beacon block data | A payload-commitment change with no delivery owner and unclear interaction with the consensus redesign. Unanimous. |
| 8363 | Tapered Issuance Burn | DFI | 0 (4) | Rewards & penalties | Issuance policy belongs to a broader ecosystem process than a fork scoping exercise. Unanimous, and not a judgment on the merits; see the closing note. |
Execution layer
| EIP | Name | Tier | Avg (total) | Category | Notes |
|---|---|---|---|---|---|
| 8141 | Frame Transactions | S | 3.89 (9) | Headliner | Locked-in EL headliner. Native account abstraction on security grounds: a path to PQ signature schemes without a fork per scheme, aggregation so PQ verification can be priced, and a route to retiring k1 keys. Ships with EIP-8250 and EIP-8272. |
| 3298 | Removal of Refunds | A | 3.17 (6) | Repricing | Deletes an entire class of metering edge cases that the last fork paid for dearly. |
| 8250 | Keyed Nonces for Frame Transactions | A | 3.12 (8) | Frames core | Frames core. Keyed nonces let many users share one sender for better anonymity while using separate nonces, so their transactions do not block one another. |
| 5920 | PAY Opcode | A | 3 (6) | EVM feature | A small new feature that closes a long-standing issue: value transfer without invoking recipient code. Low surface, high leverage. |
| 8272 | Recent Roots for Frame Transactions | A | 2.86 (7) | Frames core | Frames core. Recent roots let private transactions use recent onchain state in a form attesters can verify, allowing them to benefit from FOCIL’s inclusion guarantees. |
| 8279 | Block Access List Byte Floor | A | 2.71 (7) | Repricing | Bounds worst-case block construction: floors adversarial BAL pricing so the worst case becomes gas_limit divided by the floor cost. Security work, graded with EIP-8131. Spending any headroom is a separate, later decision. |
| 8131 | Unified Transaction Content Floor | A | 2.67 (6) | Repricing | The other half of the bounding pair with EIP-8279, applied to calldata content. Graded as security work. Whether it counts as bounding or repricing is a live definitional question; the grade does not depend on the answer. |
| 7906 | Transaction Assertions via State Diff Opcode | A | 2.43 (7) | Frames extensions | Lets a transaction verify what happened before it commits, preventing wallet drains and classes of MEV extraction; currently running with Frames on a public devnet. Proposed narrowing pending further research: arbitrary storage reads removed, assertions over emitted events and BAL-touched slots deliver the value. Graded as part of the Frames extension package, alongside EIP-8298 and EIP-8151. |
| 8298 | SETCODEFROM Code Reuse Instruction | A | 2.17 (6) | AA & delegation | Half of the k1-retirement package with EIP-8151: a 7702-delegated account becomes a true smart-contract account and drops k1 as its master key. Also cuts deployment cost after Glamsterdam’s CREATE repricing. |
| 8151 | Account Code Restricted ecRecover | A | 2 (6) | AA & delegation | The other half of the k1 exit with EIP-8298: once real code lives at an address, ecRecover-based authentication is rejected and a retired key stops being dangerous. One package, one grade. |
| 4758 | Deactivate SELFDESTRUCT | A | 1.5 (6) | Cleanup & deprecations | Removes the last SELFDESTRUCT path, a testing hazard every future EIP must otherwise define its interaction with; Frames is simpler without it. The 1.5 average sits well below A. The override rests on the Engineering seats that maintain the EVM and would carry the opcode’s cost indefinitely. |
| 8253 | Bump Nonce of Zero-Nonce Storage Accounts | B | 2.29 (7) | State transition | The trie migration can technically proceed without it, and it simplifies every migration step significantly. Whether that simplification earns A-tier now or B-tier until devnet sequencing proves there is room is the one question left on it. |
| 8077 | eth/XX: Announce Transactions with Nonce | B | 2 (5) | Mempool & tx propagation | Many want richer announcements for the Frames-era mempool; nothing forces the shape into Hegotá before the wire format is written into the EIP. A settled format could move this EIP to A-tier. |
| 8374 | Persist Warm Access Sets Across Reverts | B | 1.67 (6) | Repricing | Coupled with EIP-8358: the two net-metering repricings make little sense apart and belong at one grade. |
| 7709 | Read BLOCKHASH from Storage and Update Cost | B | 1.67 (6) | Repricing | Real value for the history-expiry direction; grades span three tiers. This EIP could move up to A-tier if devnet sequencing moves smoothly and allows for it to be added without delaying schedules. |
| 7668 | Remove Bloom Filters | C | 1.5 (6) | Cleanup & deprecations | Internally rated w/ a three-tier spread; a receipt and filter change best sequenced with the broader history and logs work. |
| 8200 | EVMification | C | 1.43 (7) | Precompiled & cryptography | Every replacement bytecode must be audited to match precompile behavior exactly, and the bytecodes are not yet in the EIP. There is no hybrid: all clients run the bytecode or gas cannot be computed consistently. Graded with EIP-7666. |
| 8358 | Net Gas Metering for Account Changes | C | 1 (6) | Repricing | Coupled with EIP-8374 and currently a tier apart. |
| 7666 | EVM-ify the Identity Precompile | C | 1 (7) | Precompiled & cryptography | Exists to support EIP-8200 and was not defended independently. |
| 8116 | Replace Cumulative Receipt Fields | C | 1 (6) | Block & state data | Same family as EIP-7668: a receipt-format change best sequenced with history and logs. |
| 8355 | ML-DSA Verification Precompiles | C | 1 (9) | Precompiled & cryptography | Enshrines a specific PQ verification scheme ahead of a dedicated cryptographic adjudication: premature standardization. |
| 8163 | Reserve EXTENSION (0xae) Opcode | DFI | 2.33 (6) | EVM cleanup | No committed consumer of the reserved opcode ships this fork, and a reservation can ride any future fork at the moment an object-format design commits. |
| 7979 | Call and Return Opcodes for the EVM | DFI | 1.33 (6) | EVM cleanup | Adds control-flow surface to a fork already carrying two headliners and their interaction testing. |
| 7851 | Code-Controlled EOA Delegation | DFI | 1 (5) | AA & delegation | An alternative account-abstraction mechanic; loses to the Frames approach on the permissionless-innovation test. |
| 7923 | Linear, Page-Based Memory Costing | DFI | 0.83 (6) | Repricing | Repricing family: no further metering churn before Glamsterdam’s repricing produces mainnet evidence. |
| 7973 | Warm Account Write Metering | DFI | 0.83 (6) | Repricing | See EIP-7923 note |
| 8304 | Trustless Log and Transaction Index | DFI | 0.83 (6) | Block & state data | An index-format change with a large testing surface; belongs with the history and logs work. |
| 8094 | eth/vhash: Blob-Aware Mempool | DFI | 0.8 (5) | Mempool & tx propagation | A mempool change with unclear interaction with the blob-scaling path. |
| 8115 | Batch Priority Fees at End of Block | DFI | 0.5 (6) | Block & state data | See EIP-7923 note |
| 8219 | Checked Arithmetic Opcodes | DFI | 0.5 (6) | Gas repricing | See EIP-7923 note |
| 7819 | SETDELEGATE Instruction | DFI | 0.29 (7) | AA & delegation | An alternative account-abstraction mechanic; loses to the Frames approach on the permissionless-innovation test. |
| 8188 | Last-Written Block for Accounts and Slots | DFI | 0.29 (7) | Block & state data | State-repricing family; waits for the I* trie-migration design. |
| 2488 | Deprecate the CALLCODE Opcode | DFI | 0.17 (6) | Cleanup & deprecations | A deprecation with no Hegotá urgency and app-layer breakage risk. Near-unanimous. |
| 7862 | Delayed State Root | DFI | 0.17 (6) | State transition | Proving-preparation set; deferred, not disliked. |
| 8182 | Private ETH and ERC-20 Transfers | DFI | 0.17 (6) | Privacy | Enshrines a specific privacy mechanism; the Frames-based path delivers the same goal with less protocol surface and keeps schemes competing. |
| 7645 | Alias ORIGIN to SENDER | DFI | 0 (6) | AA & delegation | Breaks assumptions in deployed contracts for no security gain. Unanimous. |
| 7807 | SSZ Execution Blocks | DFI | 0 (6) | Block & state data | A formatting migration with a wide blast radius and no Hegotá dependency. Unanimous. |
| 8368 | CPSB Recalibration for New Gas Limit | TBD | 2.29 (7) | Repricing | Waiting on post-Glamsterdam mainnet data. One decision with EIP-8372 (recalibrate, normalize, or neither), unknowable until Glamsterdam’s repricing produces evidence. This proposal drew majority S/A support; |
| 8372 | Normalized State Gas Limit | TBD | 1.14 (7) | Repricing | Waiting on the same post-Glamsterdam mainnet data as EIP-8368. |
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.
-
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.
-
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.
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*.
-
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.
Leave a Reply