The Ethereum Foundation Protocol cluster published its current and emerging priorities on September 7 alongside a unified assessment of 62 EIPs proposed for Hegotá.
Roughly 60 researchers and engineers contributed to the process. Sixteen contribution templates produced 397 individual grades across the candidate proposals before broader working sessions reconciled the results.
Two changes stand clearly above the rest: EIP-7805, Fork-choice enforced Inclusion Lists, on the consensus layer and EIP-8141, Frame Transactions, on the execution layer.
FOCIL tries to make transaction inclusion harder for builders to veto
FOCIL allows multiple validators to publish inclusion lists containing valid transactions that should appear in a block when sufficient space is available.
Attesters then check those constraints when deciding which block the fork-choice rule should accept.
It does not eliminate builders or determine the exact ordering of every transaction. Its narrower purpose is to stop a builder from having unilateral power to ignore an otherwise valid public-mempool transaction.
That is why the Foundation frames it as a censorship-resistance mechanism rather than another throughput upgrade.
Frame Transactions make account authentication programmable
EIP-8141 changes a different part of Ethereum: how a transaction is structured and validated.
Frame Transactions break operations into programmable components that can handle validation, gas payment and execution. Accounts could rotate authentication methods, use alternative signatures, aggregate operations and let another party sponsor fees.
The post-quantum angle follows directly from that flexibility.
Traditional externally owned accounts depend on secp256k1 keys. A native programmable validation path gives users a route away from that cryptography without requiring Ethereum to introduce a completely new account architecture every time a signature scheme changes.
Hegotá is not Ethereum's post-quantum fork
The Foundation explicitly makes that distinction.
Hegotá is meant to put enough infrastructure in place for later forks to hit a much more ambitious target: full post-quantum resistance across Ethereum's execution, consensus and data layers by December 2029.
The working assumption is deliberately aggressive. Protocol is planning as though a cryptographically relevant “Q-day” could arrive as early as 2030.
That is not a prediction that quantum computers will break Ethereum in 2030. The Foundation notes that most credible estimates put such a machine later, sometimes much later, and acknowledges that the date remains fundamentally uncertain.
December 2029 is a self-imposed migration deadline.
Ethereum wants a minimum viable quantum fallback before the complete design
The roadmap separates full post-quantum readiness from an intermediate milestone called MV-PQ, or Minimum Viable Post-Quantum.
MV-PQ is intended as a contingency mode capable of keeping Ethereum operating through an unexpectedly early quantum event, although with reduced guarantees that researchers are still defining.
The current Strawmap places a post-quantum public-key registry in I*. J* then combines a post-quantum consensus heartbeat, leanDA sampling on the data layer and leanSPHINCS transactions for execution.
Full post-quantum attestations remain later work and are required before the consensus layer can retain full economic finality under the new cryptography.
The schedule only works if several forks are developed in parallel
Protocol's planning uses a December 2026 Glamsterdam date and a December 2029 full-resistance target.
Reaching L* over that interval would require an average of roughly 7.2 months per fork. A slower twelve-month rhythm could still reach the intermediate MV-PQ milestone at J* by the same deadline.
Neither path leaves much room for a purely sequential development process.
Hegotá implementation has to happen while I* specifications mature and research for J*, K* and L* is already producing testable components.
Most of the 62 proposals will not make the cut
The published ranking reflects that capacity constraint.
Two proposals are classified as must-ship, fifteen are expected to ship and twenty-eight are declined with stated reasons. Other candidates remain conditional on additional research, implementation evidence or unresolved technical decisions.
One of the lessons drawn from Glamsterdam is that code size is a poor measure of integration risk.
A small EIP can still touch several clients, protocol layers and assumptions, creating a disproportionately large testing surface.
The Foundation describes the maturity path as Research, EIP, Prototype, Devnet, PFI, CFI, SFI and finally Mainnet. A proposal can move backward if testing exposes problems.
Privacy work is entering the same fork
Post-quantum preparation is only one of Hegotá's themes. The Protocol cluster also wants to introduce protocol support for trustless, censorship-resistant private activity on L1.
EIP-8250 Keyed Nonces would allow multiple users to share a sender while maintaining independent nonce spaces, preventing one user's transactions from blocking another's.
EIP-8272 Recent Roots gives privacy systems access to sufficiently recent onchain state in a form compatible with FOCIL's inclusion checks.
The Foundation treats those proposals as part of a package around Frames rather than unrelated conveniences.
Validator withdrawal credentials are already part of the quantum cleanup
EIP-8365 begins retiring BLS withdrawal credentials tied to cryptography that would be vulnerable to a sufficiently capable quantum machine.
That work can begin before Ethereum has finalized its complete post-quantum consensus design.
Consensus itself is less flexible. The Foundation argues that validator cryptography and aggregation schemes cannot rely on the same kind of account-level cryptographic agility that Frames provide. Those components need to be designed, battle-tested and activated together through hard forks.
Ethereum is increasingly planning forks around what it refuses to include
That may be the most revealing part of the new process.
Ethereum's roadmap has often looked like a long catalog of desired capabilities: account abstraction, better finality, privacy, state reduction, zkEVMs and post-quantum security.
Hegotá is being scoped more like an engineering budget.
FOCIL consumes most of the additional consensus-layer appetite. Frames carries much of the execution ambition. Everything else has to justify the implementation and testing capacity it takes away from the forks behind them.
Client teams could realistically begin Hegotá implementation in late Q4 2026. Final scope still depends on prototypes, devnets and AllCoreDevs decisions.
Sixty-two EIPs entered the process. The difficult part now is deciding which ones Ethereum can afford not to ship.