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
EIPNameTierAvg (total)CategoryNotes7805FOCILS4 (7)HeadlinerLocked-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.8369VOPS Profiles for FOCIL EligibilityA3.5 (4)Frames coreDefines which transactions are eligible for FOCIL and what validators must verify, extending its inclusion guarantees to Frames.8015Remove Deposit and eth1data FieldsA3.14 (7)Cleanup & deprecationsRemoves dead deposit and eth1data fields with no downstream dependency. Near-unanimous.8365BLS Withdrawal Credential RetirementA3 (8)Staking featuresStarts retiring withdrawal credentials tied to vulnerable cryptography now; nothing downstream depends on waiting. The one PQ item that belongs in Hegotá.8383Reduce CL Block Retention WindowA3 (2)History and logsA 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.8334Bundled Attestation PropagationA2.43 (7)AttestationsBundling attestation propagation cuts gossip load with a small surface. No grade below B; bundling mechanics are settled in specification.8025Optional Execution ProofsA2.38 (8)DA & proofsUpstreams stateless-execution changes into the canonical execution specs so zkVM work stops living on divergent branches.8146Block Access List SidecarsB2.13 (8)Block propagation & validationThe 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.8237Independent CL/EL SyncB2 (6)Sync & history retentionThe 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.8198Quick SlotsB2 (6)Consensus & fork choiceS/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.8321Hash-Chain RANDAOB1.57 (7)Consensus & fork choiceSound 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.8371RowDAS: Distributed Blob ReconstructionC2.11 (9)DA & proofsPriority, not principle: whether operators feel reconstruction pain today versus investing in headroom.8379Top-up SyncDFI1 (2)Sync & history retention-7716Anti-Correlation Attestation PenaltiesDFI0.83 (6)Rewards & penaltiesAdds 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.8367Balance Sunset for Retired BLS ValidatorsDFI0.71 (7)Staking featuresReads as validator convenience to some and PQ hygiene to others; either way it waits for the complete PQ consensus design.8243Batching Attestations at SourceDFI0.67 (9)AttestationsNo S or A grade. Attestation batching belongs with the slot-structure work decoupled consensus will redo.8333Align Checkpoint with Epoch Boundary BlockDFI0.5 (6)Consensus & fork choiceEarly support collapsed once its interaction with decoupled consensus was examined; unclear if behavior under the consensus redesign it would have to survive.8142Block-in-Blobs (BiB)DFI0 (7)DA & proofsDeepens dependence on KZG structures against the path to J*. Unanimous.8148Custom Sweep Threshold for ValidatorsDFI0 (6)Staking featuresOperational convenience primarily serving large staking operations; fails the necessity bar. Unanimous.8205Withdrawal Credentials PreregistrationDFI0 (6)Staking featuresSame rationale as EIP-8148. Unanimous.8359Beacon Block Reporting FieldDFI0 (6)Beacon block dataGraffiti watermarking and node scraping is sufficient for right now; fails the necessity bar. Unanimous.8375ePBS Mandatory Burn of Execution RewardsDFI0 (6)Rewards & penaltiesReward policy belongs to a broader ecosystem process than a fork scoping exercise. Unanimous. See EIP-8363 and the closing note.8341Partial Execution Payload CommitmentsDFI0 (4)Beacon block dataA payload-commitment change with no delivery owner and unclear interaction with the consensus redesign. Unanimous.8363Tapered Issuance BurnDFI0 (4)Rewards & penaltiesIssuance 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
EIPNameTierAvg (total)CategoryNotes8141Frame TransactionsS3.89 (9)HeadlinerLocked-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.3298Removal of RefundsA3.17 (6)RepricingDeletes an entire class of metering edge cases that the last fork paid for dearly.8250Keyed Nonces for Frame TransactionsA3.12 (8)Frames coreFrames core. Keyed nonces let many users share one sender for better anonymity while using separate nonces, so their transactions do not block one another.5920PAY OpcodeA3 (6)EVM featureA small new feature that closes a long-standing issue: value transfer without invoking recipient code. Low surface, high leverage.8272Recent Roots for Frame TransactionsA2.86 (7)Frames coreFrames 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.8279Block Access List Byte FloorA2.71 (7)RepricingBounds 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.8131Unified Transaction Content FloorA2.67 (6)RepricingThe 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.7906Transaction Assertions via State Diff OpcodeA2.43 (7)Frames extensionsLets 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.8298SETCODEFROM Code Reuse InstructionA2.17 (6)AA & delegationHalf 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.8151Account Code Restricted ecRecoverA2 (6)AA & delegationThe 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.4758Deactivate SELFDESTRUCTA1.5 (6)Cleanup & deprecationsRemoves 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.8253Bump Nonce of Zero-Nonce Storage AccountsB2.29 (7)State transitionThe 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.8077eth/XX: Announce Transactions with NonceB2 (5)Mempool & tx propagationMany 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.8374Persist Warm Access Sets Across RevertsB1.67 (6)RepricingCoupled with EIP-8358: the two net-metering repricings make little sense apart and belong at one grade.7709Read BLOCKHASH from Storage and Update CostB1.67 (6)RepricingReal 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.7668Remove Bloom FiltersC1.5 (6)Cleanup & deprecationsInternally rated w/ a three-tier spread; a receipt and filter change best sequenced with the broader history and logs work.8200EVMificationC1.43 (7)Precompiled & cryptographyEvery 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.8358Net Gas Metering for Account ChangesC1 (6)RepricingCoupled with EIP-8374 and currently a tier apart.7666EVM-ify the Identity PrecompileC1 (7)Precompiled & cryptographyExists to support EIP-8200 and was not defended independently.8116Replace Cumulative Receipt FieldsC1 (6)Block & state dataSame family as EIP-7668: a receipt-format change best sequenced with history and logs.8355ML-DSA Verification PrecompilesC1 (9)Precompiled & cryptographyEnshrines a specific PQ verification scheme ahead of a dedicated cryptographic adjudication: premature standardization.8163Reserve EXTENSION (0xae) OpcodeDFI2.33 (6)EVM cleanupNo 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.7979Call and Return Opcodes for the EVMDFI1.33 (6)EVM cleanupAdds control-flow surface to a fork already carrying two headliners and their interaction testing.7851Code-Controlled EOA DelegationDFI1 (5)AA & delegationAn alternative account-abstraction mechanic; loses to the Frames approach on the permissionless-innovation test.7923Linear, Page-Based Memory CostingDFI0.83 (6)RepricingRepricing family: no further metering churn before Glamsterdam’s repricing produces mainnet evidence.7973Warm Account Write MeteringDFI0.83 (6)RepricingSee EIP-7923 note8304Trustless Log and Transaction IndexDFI0.83 (6)Block & state dataAn index-format change with a large testing surface; belongs with the history and logs work.8094eth/vhash: Blob-Aware MempoolDFI0.8 (5)Mempool & tx propagationA mempool change with unclear interaction with the blob-scaling path.8115Batch Priority Fees at End of BlockDFI0.5 (6)Block & state dataSee EIP-7923 note8219Checked Arithmetic OpcodesDFI0.5 (6)Gas repricingSee EIP-7923 note7819SETDELEGATE InstructionDFI0.29 (7)AA & delegationAn alternative account-abstraction mechanic; loses to the Frames approach on the permissionless-innovation test.8188Last-Written Block for Accounts and SlotsDFI0.29 (7)Block & state dataState-repricing family; waits for the I* trie-migration design.2488Deprecate the CALLCODE OpcodeDFI0.17 (6)Cleanup & deprecationsA deprecation with no Hegotá urgency and app-layer breakage risk. Near-unanimous.7862Delayed State RootDFI0.17 (6)State transitionProving-preparation set; deferred, not disliked.8182Private ETH and ERC-20 TransfersDFI0.17 (6)PrivacyEnshrines a specific privacy mechanism; the Frames-based path delivers the same goal with less protocol surface and keeps schemes competing.7645Alias ORIGIN to SENDERDFI0 (6)AA & delegationBreaks assumptions in deployed contracts for no security gain. Unanimous.7807SSZ Execution BlocksDFI0 (6)Block & state dataA formatting migration with a wide blast radius and no Hegotá dependency. Unanimous.8368CPSB Recalibration for New Gas LimitTBD2.29 (7)RepricingWaiting 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;8372Normalized State Gas LimitTBD1.14 (7)RepricingWaiting 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.
GIPHY App Key not set. Please check settings