The Ethereum Foundation Sets 2029 Deadline for Quantum-Resistant Upgrades

Original author: KarenZ, Foresight News

Quantum computers have not yet knocked on the door of blockchain, but the Ethereum Foundation has already marked a date on its calendar: December 2029.

It is the engineering deadline set by the Ethereum Foundation’s protocol team: to prepare for the possibility that quantum threats may emerge sooner, and to complete the quantum-resistant upgrade of Ethereum’s layer-one network before the risk becomes imminent.

Hegotá, currently in planning, will not directly transform Ethereum into a fully quantum-resistant blockchain, but it will determine whether subsequent plans can proceed on schedule.

“Q-day” typically refers to a hypothetical point in time when a quantum computer with practical attack capabilities emerges, posing a substantial threat to existing public-key cryptographic systems.

No one can accurately predict when it will arrive. The Ethereum Foundation also explicitly acknowledges that most credible predictions suggest Q-day will be after 2030, possibly much later, or that it may never come at all.

The Ethereum Foundation Protocol Team adopts a conservative engineering assumption: Ethereum Layer 1 should be prepared in advance for the possibility that Q-day could occur as early as 2030.

To this end, the protocol team has set a goal: to achieve full quantum resistance in Ethereum Layer 1’s execution, consensus, and data components by December 2029.

This target is not set in stone. The protocol team plans to reassess the progress of quantum computing in January 2027, incorporating input from external experts. Until then, the 2029 deadline will serve as a firm, non-negotiable goal.

Quantum resistance requires years of preparation because Ethereum does not rely on just one cryptographic technology, and migrating cannot be accomplished by simply swapping a signature algorithm. How user accounts prove transaction authorization, how validators participate in consensus, and how data is verified all involve different cryptographic structures. Any changes must go through specification design, client implementation, security audits, testnet testing, and mainnet coordination—and cannot wait until the threat has already emerged.

According to the current roadmap published by the Ethereum Foundation protocol team, the Glamsterdam network upgrade is scheduled to go live on mainnet in December 2026, with full quantum resistance targeted for the fifth hard fork after Glamsterdam, designated L*, with a target date of December 2029. With only three years between Glamsterdam and L*, if the upgrades Hegotá, I*, J*, K*, and L* are to be completed sequentially, the average interval between each upgrade would be approximately 7.2 months.

This is a fairly aggressive timeline. Currently, the Ethereum Foundation has not announced definitive mainnet launch dates for Hegotá, I*, J*, and K*. It is certain that client teams anticipate beginning implementation of Hegotá no earlier than late Q4 2026, while research, specifications, and testing for multiple subsequent upgrades must proceed in parallel.

Under the current roadmap, the main arrangements for each phase are as follows:

• Hegotá: Located at the start of this roadmap. Its official purpose is clear: Hegotá itself is not a quantum-resistant upgrade, but it will determine whether subsequent quantum-resistant upgrades can proceed on schedule.
• I*: Deploy a post-quantum public key registry to establish a protocol foundation for account registration and the use of post-quantum public keys; simultaneously, decoupling consensus is currently the leading core direction for this release, and substantial state structure design and migration efforts are also expected to begin with I*.
• J*: Establish a "Minimum Viable Post-Quantum" layer, known as MV-PQ. Its key components include a post-quantum heartbeat mechanism at the consensus layer, post-quantum leanDA sampling at the data layer, and post-quantum leanSPHINCS transactions at the execution layer.
• K*: Introduce enforced proofs of execution, ranked by the current benchmark. At that point, validators will focus on verifying concise execution proofs rather than each validator re-executing entire blocks.
• L*: According to the current baseline, add post-quantum attestations required to achieve full quantum resistance in consensus, and reach full quantum resistance across the execution, consensus, and data layers by December 2029.

However, the order of K* and L* has not yet been finalized. The protocol team is evaluating a revised sequence: moving the post-quantum proof message from L* to K* to enable full post-quantum capability earlier, while delaying the enforcement proof from K* to L*. If this approach is adopted, the specific responsibilities and upgrade timelines for K* and L* will accordingly change. Therefore, the most accurate statement at this stage is: December 2026 is the current mainnet target for Glamsterdam, and December 2029 is the target in the baseline roadmap for L* and full post-quantum capability; the internal ordering of K and L* remains subject to adjustment.

Researchers, client developers, security reviewers, and testing teams must complete Hegotá while also preparing specifications and prototypes in advance for I*, J*, K*, and L*. If Hegotá incorporates too many interdependent features, it may not only delay its own launch but also consume the team resources needed for subsequent post-quantum work.

Therefore, the Ethereum Foundation Protocol Team categorized the 62 candidate proposals into the following tiers: S (2), A (15), B (8), C (7), DFI (28), and TBD (2). S-tier proposals are mandatory for delivery; A-tier proposals are high-priority and expected to be delivered; B-tier proposals require additional conditions such as finalized specifications, prototypes, or lead confirmation; C-tier proposals are currently below the inclusion threshold; DFI indicates proposals not recommended for this upgrade; and TBD denotes proposals pending further determination.

In the Hegotá grading released by the protocol team, only two EIPs reached S-tier: EIP-7805 FOCIL on the consensus layer and EIP-8141 Frame transactions on the execution layer.

They address two key issues in the transaction lifecycle: whether a qualifying transaction can be included in a block, and how an account can verify and execute transactions.

The full name of FOCIL (EIP-7805) is "Fork-choice Enforced Inclusion Lists." Its goal is to improve transaction inclusion guarantees on Ethereum.

Currently, professional block builders dominate block production. This division of labor enhances block construction efficiency, but if block production becomes concentrated in the hands of a few builders over the long term, they may gain significant transaction selection power. To address this, FOCIL adds an additional layer of inclusion constraints from validators outside the standard block construction process.

According to FOCIL's design, each slot selects a group of validators to form an Inclusion List (IL) committee. Committee members independently create and broadcast inclusion lists based on the pending transactions they observe. The block builder for the next slot collects these lists and includes transactions that meet execution criteria when constructing the block. Validators responsible for attesting to the new block also retain the inclusion lists they receive in a timely manner and verify that the block satisfies the corresponding requirements.

If a block omits transactions saved by validators without justification, attesters will not vote for that block. Even though such a block remains valid at the execution level, it will not gain the consensus support needed to enter the canonical chain. This is the purpose of FOCIL: rather than allowing committee members to directly modify blocks, it constrains block builders’ choices through whether validators cast their votes.

The accompanying EIP-8369 further specifies which transactions are eligible for mandatory inclusion under FOCIL. The reasons for omission of ordinary transactions are relatively easy to verify; however, Frames transactions allow programmable verification, which incurs higher costs, and thus require additional constraints on the range of state that can be read and the verification budget.

In simple terms, FOCIL doesn’t let validators take over the block builder’s job; instead, it adds a consensus-layer rule for builders: you can still arrange most of the transactions in a block, but you cannot consistently ignore qualified transactions listed by the committee without a valid reason.

Frame Transactions (EIP-8141) addresses account-layer issues. It aims to make transaction validation, transaction execution, and gas payment more programmable at the protocol level, laying the foundation for native account abstraction. Vitalik is one of the co-authors of EIP-8141.

Currently, most standard Ethereum accounts rely on fixed-type private key signatures. Frames aims to enable accounts to use more flexible validation logic, such as adopting new signing schemes, combining multiple authorization conditions, or allowing other accounts to pay transaction fees. It also supports signature aggregation and allows new signing schemes to be introduced in the future without requiring a separate hard fork for each one.

However, Frames itself is not a complete post-quantum signature scheme and will not immediately replace existing keys upon Hegotá’s launch. It provides "cryptographic agility": if a signature scheme needs to be replaced in the future, accounts can migrate via programmable verification, rather than being permanently locked into a single key system.

Frames requires two additional Level-A proposals as core配套设施. EIP-8250 Keyed Nonces enables the same sender to use mutually independent nonce channels, allowing different transactions to avoid blocking each other due to a strict shared ordering; EIP-8272 enables transactions to use recent on-chain state verifiable by validators, ensuring that related privacy transactions also benefit from the inclusion guarantees provided by FOCIL.

Therefore, FOCIL and Frames are not two unrelated features; the former determines which eligible transactions must be included in a block, while the latter alters the verification structure of the transactions themselves. Whether they can safely work together is one of Hegotá’s most critical test objectives.

The S-level proposal defines Hegotá's mainline, but multiple A-level proposals also impact Ethereum's future account security, quantum-resistant migration, execution proofs, and resource pricing.

First is EIP-8365. It plans to initiate a phased exit for certain BLS withdrawal credentials, as these credentials still rely on cryptographic techniques that may become insecure against sufficiently strong quantum attacks. The protocol team believes this migration can begin ahead of time, without waiting for a complete quantum-resistant consensus design to be finalized.

In terms of account security, EIP-7906, EIP-8298, and EIP-8151 are considered an extended combination for Frames.

EIP-7906 introduces the Transaction Assertions mechanism, enabling transactions to verify whether specified outcomes have occurred before final submission. This mechanism aims to reduce losses caused by malicious contracts draining wallet assets and certain MEV activities. However, the specific scope of read access for this proposal is still under research and refinement, so the current design cannot be considered a finalized, locked specification.

EIP-8298 allows accounts to reuse existing contract code, enabling delegated accounts to further evolve into fully coded smart contract accounts. EIP-8151 restricts addresses with existing contract code from continuing to rely on traditional ecRecover authentication.

Only when these two proposals are combined can accounts truly stop using the old secp256k1 key as the highest-level control credential, establishing a complete path for phasing out the old key system in the future.

EIP-8025 (Optional Execution Proofs) is related to the future zkEVM roadmap. It aims to incorporate the necessary changes for optional execution proofs into the unified execution specification, reducing the long-term maintenance burden of maintaining forked versions across different zkVM projects.

EIP-8279 (Byte Layer for Block Access Lists) and EIP-8131 (Unified Transaction Content Layer) are a set of execution safety proposals. Both establish minimum pricing standards for block access lists and transaction content, respectively, aiming to prevent attackers from exploiting underpriced content to impose extreme resource burdens. They first address the worst-case block processing costs rather than directly declaring increased network capacity. Whether to leverage the resulting safety margin to expand capacity will be decided separately in the future.

EIP-3298 aims to completely remove the gas refund mechanism to reduce special cases in measurement, implementation, and testing; EIP-5920 (PAY Opcode) allows contracts to transfer ETH without executing the recipient's code, clearly separating "value transfer" from "contract invocation."

Meanwhile, some notable proposals remain at Level B.

For example, EIP-8198 (Quick Slots) aims to reduce slot times, but the protocol team requires it to first deliver a complete specification, a full prototype, an assessment of downstream impacts, and evidence that it will not interfere with future decoupled consensus designs. This is because slot times affect not only block production speed, but also network propagation, consensus decisions, and applications’ assumptions about time.

Additionally, EIP-8368 and EIP-8372 are listed as "TBD" (to be determined). Both proposals relate to gas limits and state resource pricing; the protocol team has decided to wait for mainnet data after Glamsterdam launches in December 2026 before determining whether recalibration is necessary.

The number of EIPs ultimately included in Hegotá is not the only measure of the success of this upgrade.

More importantly, can it deliver FOCIL, Frames, and their core配套设施 without compromising security and testing quality, while reserving sufficient R&D resources for I*'s public key registration and decoupled consensus, J*'s minimum viable quantum resistance, and K*'s and L*'s execution proofs and full quantum-resistant consensus?

According to the current roadmap, Glamsterdam will initiate this condensed upgrade cycle in December 2026, while the L* in the baseline roadmap will reach its endpoint in December 2029. Each intermediate upgrade must not only fulfill its own objectives but also ensure the continuation of the next phase.

No one can say for certain whether quantum threats will become a reality before 2030. But Ethereum’s current stance is clear: set a timeline for the risk, and require each proposal to prove its readiness for mainnet deployment through specifications, prototypes, and testing.

Article reference:

https://blog.ethereum.org/2026/09/07/protocol-hegota-eips

https://blog.ethereum.org/2026/09/07/protocol-priorities

https://x.com/VitalikButerin/status/2073459000398463446