Lido contributors’ ranking of EL EIPs proposed for Hegota
The Hegotá scoping process has surfaced a large set of execution-layer EIPs at the Proposed-for-Inclusion stage. Below is our position on the subset we have views on, along with the reasoning behind each. This is not a comprehensive review of every PFI’d EIP; it reflects the items where we think it is worth the ecosystem hearing from us. We remain open to updating our position as specs, testing, and client-team discussions evolve.
Our ranking system
-
S — Must ship. We believe Hegotá is incomplete without it and are prepared to advocate for its inclusion up to the fork lock.
-
A — Strongly support. We want it in the fork and expect to commit review and testing resources to help it land.
-
B — Support if the timeline allows. Small or low-coordination items that should not be permitted to delay the fork, but that we would like to see when they fit.
-
C — Conditional support. We are open to inclusion under specific conditions or with additional data we would want to see first; we spell out the condition per EIP.
-
D — Decline for inclusion. We do not think this should ship in Hegotá, either because the timing is wrong, the design tradeoff is wrong, or the problem is better solved elsewhere.
Ranks reflect our current best judgement. The actual inclusion decisions rest with client teams and All Core Devs rough consensus; we offer this list as one input among many.
Rank A
-
EIP-8250 — Keyed Nonces for Frame Transactions: Frame Transactions is a headliner of Hegotá and 8250 is one of its two natural companions: shipping Frames without it forecloses shared-sender designs and worsens mempool concurrency for the entire class of paymaster-based and privacy-preserving applications that Frames is meant to enable. The two should ship together.
-
EIP-8272 — Recent Roots for Frame Transactions: The other Frames-core companion, and the primitive that lets non-trivial frame transactions remain force-includable via FOCIL — omitting it leaves a real design gap in the mempool rules and weakens censorship resistance for the applications Frames is designed to support. Belongs in the fork.
Rank B
-
EIP-7709 — Read BLOCKHASH from storage and update cost: Small, uncontroversial step on the stateless-execution roadmap with no meaningful downside. EIP-7807 — SSZ Execution Blocks: Long-overdue structural cleanup that unifies block representation across CL and EL, simplifies the Engine API, and improves proof ergonomics for light clients and zk-EVMs. Client-team coordination is heavy and the payoff is downstream rather than immediate.
-
EIP-8219 — Checked Arithmetic Opcodes: A clean gas and bytecode improvement for essentially every Solidity contract that uses checked arithmetic, with no meaningful downside beyond compiler and toolchain adoption lag. Nice-to-have.
Rank D (DFI)
- EIP-8182 — Private ETH and ERC-20 Transfers: Enshrining a specific privacy scheme at protocol level forecloses design competition, adds permanent protocol surface for a fast-moving area of cryptography, and concentrates regulatory attention on a single primitive. Frame Transactions (combined with 8250 and 8272) already give the ecosystem a substrate to build privacy in application space where multiple designs can compete, upgrade, and coexist; the protocol should stay neutral and let that play out.