Ethereum narrows upgrades to meet 2029 quantum deadline
Developers are prioritizing FOCIL and Frame Transactions and limiting other consensus-layer work to meet the Ethereum Foundation’s December 2029 quantum-resistance deadline.
Ethereum developers are narrowing the scope of upcoming upgrades to meet a December 2029 target for post-quantum security. Engineering work that hardens execution, consensus and data layers is being prioritized over optional features, the Protocol cluster wrote.
The Protocol cluster and the Ethereum Foundation have protected two features for Hegotá, the upgrade being scoped after Glamsterdam: FOCIL, which strengthens transaction-inclusion guarantees, and Frame Transactions, a new account transaction model intended to allow accounts to adopt alternative signature schemes without repeated hard forks. The Foundation wrote its appetite for additional consensus-layer work beyond FOCIL is “close to zero” unless it supports the post-quantum roadmap.
Developers are weighing a schedule change that would move post-quantum attestations from the L* release to K* while pushing mandatory execution proofs from K* to L*. The proposal has not been approved. Advancing attestations earlier would speed a major quantum-security change but could delay the zkEVM timeline.
The Foundation set December 2029 as a firm target for quantum resistance across execution, consensus and data. It is not predicting a cryptographically relevant quantum computer by 2030, but it is planning from a possible “Q-day” when widely used public-key schemes could be broken.
Under current planning, if Glamsterdam reaches mainnet in December 2026, Ethereum would need to deliver the remaining forks at an average interval of about 7.2 months to reach post-quantum readiness by December 2029. The Foundation described that cadence as aggressive and vulnerable to delays.
The Protocol cluster wrote that “Hegotá is not the PQ fork; it is the fork that decides whether the PQ forks happen on time.” To limit risk, the roadmap includes a minimum viable post-quantum milestone, MV-PQ, planned for J*. MV-PQ would add a post-quantum consensus heartbeat, leanDA sampling and leanSPHINCS transactions after a public-key registry appears one fork earlier. The Foundation described MV-PQ as a temporary safeguard that would let the network operate through a quantum threat without delivering full economic finality; post-quantum attestations needed for full finality would still be outstanding.
The Protocol cluster reviewed 62 proposals and sorted them into S, A and B tiers. S-tier items define the fork and are protected even if schedules slip. A-tier features are expected to ship but can be cut. B-tier proposals must wait until higher-priority items are stable and then compete for remaining capacity.
Examples in the tiers include Quick Slots in B tier; developers require a full specification, a prototype and an analysis of downstream effects before advancing it. Hash-Chain RANDAO remains in B tier because developers want the wider quantum-resistant architecture settled before locking in that component. A proposal to add ML-DSA verification precompiles ranks lower on the list.
Frame Transactions is among the protected headliners because it makes account validation programmable and reduces the need for repeated hard forks to change signature schemes. Related proposals Keyed Nonces and Recent Roots received A grades. Keyed Nonces would let users share a sender while maintaining separate transaction sequences. Recent Roots would let private transactions reference recent on-chain state in a form compatible with FOCIL. Optional Execution Proofs also remain A-tier, allowing continued work on stateless execution and zkVM infrastructure even if mandatory proofs move back one fork.
Implementation of Hegotá would run alongside specifications for I* and research for later releases, increasing demand for cryptographers, client developers, security reviewers and testing capacity across multiple workstreams. The next decision is whether to move post-quantum attestations to K* and push mandatory execution proofs to L*. If attestations move earlier, teams building mandatory execution proofs will face another fork delay; if they do not, developers will need a faster release cadence or rely on MV-PQ protections.








