Countdown to 2029: Ethereum's Quantum Resistance Marathon Starts with Hegotá

Original author: KarenZ, Foresight News

Quantum computers have not yet knocked on blockchain's door, but the Ethereum Foundation has already circled a date on the calendar: December 2029.

It is the engineering deadline the Ethereum Foundation's protocol team has set for itself: prepare for scenarios where the quantum threat may arrive earlier, and strive to complete the quantum-resistant transformation of Ethereum's Layer 1 before the risk truly approaches.

The Hegotá upgrade being planned, while it will not directly transform Ethereum into a fully quantum-resistant blockchain, will determine whether subsequent plans can proceed on schedule.

EF Sets a 2029 Deadline Ahead of 'Q-day'

'Q-day' typically refers to a hypothetical point in time: when quantum computers with practical attack capabilities emerge, rendering existing public-key cryptographic systems substantially threatened.

No one can accurately predict when it will arrive. The Ethereum Foundation also explicitly acknowledges that most credible predictions place Q-day after 2030, possibly much later, and there is also a possibility it may never arrive.

The Ethereum Foundation protocol team adopts a conservative engineering assumption: Ethereum Layer 1 should prepare in advance for the possibility that Q-day could arrive as early as 2030.

To this end, the protocol team has set a goal—to achieve complete quantum resistance across Ethereum Layer 1's execution, consensus, and data components by December 2029.

This goal is not set in stone. The protocol team plans to reassess quantum computing developments in January 2027, incorporating external expert opinions. Until then, the 2029 deadline will be treated as a working target that cannot be easily conceded.

The reason quantum-resistant transformation requires years of advance preparation is that Ethereum does not rely on a single cryptographic technique, nor can migration be completed 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 modification must go through specification design, client implementation, security audits, devnet testing, and mainnet coordination—it cannot wait until the threat has already emerged.

Hegotá Is Not a 'Quantum-Resistant Upgrade,' but It Is the First Test of the Entire Plan

According to the baseline roadmap currently published by the Ethereum Foundation protocol team, the Glamsterdam network upgrade is planned for mainnet launch in December 2026, while full quantum resistance is scheduled for the fifth hard fork after Glamsterdam, L*, with a target date of December 2029. From Glamsterdam to L* is only three years, and to complete Hegotá, I*, J*, K*, and L* in sequence, the average interval between upgrades is only about 7.2 months.

This is a fairly aggressive timeline. Currently, the Ethereum Foundation has not announced specific mainnet launch dates for Hegotá, I*, J*, and K*. What is certain is that client teams are expected to begin implementing Hegotá as early as late Q4 2026, and research, specifications, and testing for multiple subsequent versions must proceed in parallel.

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

• Hegotá: The starting point of this roadmap. The official positioning is very 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 quantum-resistant public key registry, establishing the protocol foundation for account registration and use of quantum-resistant public keys; at the same time, decoupling consensus is the leading core candidate direction for this version, and larger-scale state structure design and migration work is also expected to begin with I*.
• J*: Establish a 'minimum viable quantum-resistant' Layer 1, i.e., MV-PQ. Its key components include a quantum-resistant heartbeat mechanism at the consensus layer, post-quantum leanDA sampling at the data layer, and post-quantum leanSPHINCS transactions at the execution layer.
• K*: According to the current baseline ordering, introduce enforced execution proofs. At that point, validators will evolve toward verifying succinct execution proofs rather than every validator re-executing full blocks.
• L*: According to the current baseline ordering, add the quantum-resistant proof messages needed to achieve full quantum-resistant consensus, i.e., post-quantum attestations, and reach the full quantum resistance goal for the execution, consensus, and data layers by December 2029.

However, the task ordering for K* and L* has not been finalized. The protocol team is evaluating a swap: moving post-quantum attestations from L* to K*, enabling full quantum resistance to be achieved earlier; while moving enforced execution proofs from K* to L*. If this option is adopted, the specific responsibilities and upgrade cadence of K* and L* will change accordingly. Therefore, the most accurate statement at this stage is: December 2026 is the current mainnet target for Glamsterdam, and December 2029 is the target for L* and full quantum resistance in the baseline roadmap; the internal ordering of K* and L* may still be adjusted.

Researchers, client developers, security auditors, and testing teams must not only complete Hegotá but also prepare specifications and prototypes for I*, J*, K*, and L* in advance. If Hegotá incorporates too many interdependent features, it could not only delay its own launch but also occupy teams needed for subsequent quantum-resistant work.

Therefore, the Ethereum Foundation protocol team has classified Hegotá candidate proposals into S (2 items), A (15 items), B (8 items), C (7 items), DFI (28 items), and TBD (2 items) tiers, totaling 62 candidate proposals. S-tier means must-deliver; A-tier means high priority and expected delivery; B-tier still requires conditions such as specification, prototype, or owner confirmation; C-tier is temporarily below the inclusion line; DFI means not recommended for this upgrade; TBD means to be determined.

Hegotá's Two S-Tier Items: FOCIL and Frames

In the Hegotá classification published by the protocol team, only two EIPs made it to S-tier: EIP-7805 FOCIL at the consensus layer, and EIP-8141 Frame transactions at the execution layer.

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

FOCIL (EIP-7805) stands for 'Fork-choice enforced Inclusion Lists.' Its goal is to improve Ethereum's transaction inclusion guarantees.

Currently, specialized block builders dominate block production. This division of labor helps improve block building efficiency, but if block production remains concentrated among a few builders over the long term, they could gain strong transaction filtering capabilities. FOCIL therefore adds a layer of inclusion constraints from validators outside the normal block building process.

Under FOCIL's design, each slot selects a group of validators to form an 'inclusion list committee' (IL committee). Committee members create and broadcast inclusion lists based on the pending transactions they see. The block builder for the next slot collects these lists and includes transactions that meet execution conditions when building the block. Validators responsible for attesting to the new block also save the inclusion lists they received in time and check whether the block meets the corresponding requirements.

If a block omits transactions from a validator's saved list without valid reason, attesters will not vote for that block. Such a block, even if still valid at the execution layer, cannot obtain the consensus support needed to enter the canonical chain. This is the significance of FOCIL: it does not let committee members directly modify blocks, but constrains block builders' choices through whether validators vote.

The companion EIP-8369 further describes which transactions are suitable for FOCIL's mandatory inclusion guarantees. Omission reasons for ordinary transactions are relatively easy to verify; Frames transactions allow programmable verification, making judgment more costly, so additional limits on readable state scope and verification budget are needed.

In plain terms, FOCIL does not let validators take over block builders' work, but adds a consensus-layer rule for builders: you can still arrange most transactions in a block, but you cannot persistently ignore eligible transactions listed by the committee without reasonable cause.

Frame Transactions (EIP-8141) address the account layer. It plans to make transaction verification, transaction execution, and gas payment more programmable at the protocol layer, providing a foundation for native account abstraction. Vitalik is one of the co-authors of EIP-8141.

Currently, most ordinary Ethereum accounts rely on fixed types of private key signatures. Frames aims to allow accounts to use more flexible verification logic, such as adopting new signature schemes, combining multiple authorization conditions, or letting other accounts pay transaction fees. It can also support signature aggregation and allow new signature schemes to be introduced in the future without requiring a separate hard fork for each scheme.

But Frames itself is not a complete quantum-resistant signature scheme, nor will it immediately retire existing keys after Hegotá goes live. It provides 'cryptographic agility': if signature schemes need to be replaced in the future, accounts can complete migration through programmable verification rather than being permanently locked into one key system.

Frames also requires two A-tier proposals as core companions. EIP-8250 Keyed Nonces allows the same sender to use mutually independent nonce channels, so different transactions do not block each other by sharing a strict order; EIP-8272 allows transactions to use recent on-chain state that validators can check, so that related private transactions can also receive FOCIL's inclusion guarantees.

Therefore, FOCIL and Frames are not two unrelated features. The former changes which eligible transactions a block must include, while the latter changes the verification structure of transactions themselves. Whether the two can work together safely is one of Hegotá's most important test tasks.

Besides S-Tier, Which Other EIPs Are Worth Watching?

S-tier proposals define Hegotá's main line, but several A-tier proposals will also affect Ethereum's future account security, quantum-resistant migration, execution proofs, and resource pricing.

First is EIP-8365. It plans to initiate a gradual phase-out of some BLS withdrawal credentials, because these credentials still rely on cryptographic techniques that may lose security against sufficiently strong quantum attacks. The protocol team believes this migration can begin early without waiting for the complete quantum-resistant consensus design to be finalized.

On account security, EIP-7906, EIP-8298, and EIP-8151 are considered an expansion suite for Frames.

EIP-7906 introduces a Transaction Assertions mechanism, allowing transactions to check whether specified outcomes occur before final submission. This mechanism aims to reduce losses from malicious contracts draining wallet assets and some MEV behaviors. However, the proposal's specific read scope is still under research and narrowing, so the current design should not be written as a locked final specification.

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

Only when these two proposals are combined can accounts truly stop using old secp256k1 keys as the highest control credential, establishing a complete path for eventually retiring the old key system.

EIP-8025 (optional execution proofs) is related to the future zkEVM roadmap. It plans to incorporate changes needed for optional execution proofs into a unified execution specification, reducing the problem of different zkVM projects maintaining divergent forks over the long term.

EIP-8279 (block access list byte layer) and EIP-8131 (unified transaction content layer) are a set of execution security proposals. The two respectively set minimum pricing standards for block access lists and transaction content, aiming to limit attackers from exploiting underpriced content to create extreme resource burdens. They first address worst-case block processing costs, rather than directly announcing increased network capacity. Whether to use the resulting safety margin to expand capacity requires a separate decision later.

EIP-3298 plans to completely remove the gas refund mechanism, reducing special cases in metering, implementation, and testing; EIP-5920 (PAY Opcode) allows contracts to transfer ETH without executing recipient contract code, clearly separating 'value transfer' from 'contract calls.'

Meanwhile, some proposals that have drawn attention remain at B-tier.

For example, EIP-8198 (Quick Slots) hopes to shorten slot times, but the protocol team requires it to first complete a specification covering core protocol changes, a full prototype, downstream impact assessment, and proof that it will not interfere with subsequent decoupled consensus design. The reason is that slot time affects 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 involve gas limits and state resource pricing, and the protocol team decided to wait for mainnet data after Glamsterdam launches in December 2026 before judging whether recalibration is needed.

How many EIPs Hegotá ultimately includes is not the sole measure of whether this upgrade is successful.

More importantly, it must deliver FOCIL, Frames, and their core companions without sacrificing security and testing quality, while leaving sufficient R&D resources for I*'s public key registry and decoupled consensus, J*'s minimum viable quantum resistance, and K* and L*'s execution proofs and full quantum-resistant consensus.

According to current targets, Glamsterdam will kick off this tight upgrade cycle in December 2026, and L* in the baseline roadmap will reach the finish line in December 2029. Each upgrade in between cannot only focus on completing its own features but must also ensure the next phase can continue to advance.

Whether the quantum threat will materialize before 2030, no one can give a definitive answer. But Ethereum's current choice is already clear: first set a deadline for the risk, then let each proposal prove through specifications, prototypes, and testing that it meets the conditions to enter the mainnet.

Article references:

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