The Final Showdown in 2029: Ethereum's Most Urgent Quantum Resistance Marathon

Not a quantum resistance upgrade, but a determinant of quantum resistance success: Understanding Hegotá.

Written by: KarenZ, Foresight News

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

This is the engineering deadline set by the Ethereum Foundation's protocol team: to prepare for scenarios where quantum threats may emerge sooner, aiming to complete the quantum resistance transformation of Ethereum's layer one network before the risks truly approach.

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

EF has set a deadline of 2029 for "Q-day"

"Q-day" is typically used to refer to a hypothetical point in time: when quantum computers with real attack capabilities emerge, posing a substantial threat to existing public key cryptography systems.

When it will arrive is anyone's guess. The Ethereum Foundation also acknowledges that most credible predictions suggest Q-day will be later than 2030, and it may be much later, or it may never arrive.

The protocol team at the Ethereum Foundation adopts a somewhat conservative engineering assumption: Ethereum's layer one should prepare in advance for the earliest possible arrival of Q-day, which could be in 2030.

To this end, the protocol team has set a goal—to ensure that by December 2029, the execution, consensus, and data components of Ethereum's layer one will possess complete quantum resistance capabilities.

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

The need for years of preparation for quantum resistance transformation arises because Ethereum does not use just one cryptographic technology, and simply changing a signature algorithm will not suffice for migration. How user accounts prove transaction authorization, how validators participate in consensus, and how data is verified all involve different cryptographic structures. Any modifications must go through standardized design, client implementation, security audits, development network testing, and mainnet coordination; it is impossible to start addressing these issues only after the threat has emerged.

Hegotá is not a "quantum resistance upgrade," but the first test of the entire plan

According to the baseline roadmap currently published by the Ethereum Foundation's protocol team, the Glamsterdam network upgrade is scheduled to go live on the mainnet in December 2026, with complete quantum resistance capabilities planned for the fifth hard fork L* after Glamsterdam, targeted for December 2029. There are only three years from Glamsterdam to L*, and if Hegotá, I*, J*, K*, and L* are to be completed sequentially, there will be an average of about 7.2 months between each upgrade.

This is quite an aggressive timeline. Currently, the Ethereum Foundation has not announced specific mainnet launch dates for Hegotá, I*, J*, and K*. What is certain is that the client team expects to begin implementing Hegotá as early as late Q4 2026, while research, standardization, 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á: Positioned at the starting point of this roadmap. The official positioning is very clear: Hegotá itself is not a quantum resistance upgrade, but it will determine whether subsequent quantum resistance upgrades can proceed on time.
• I*: Deploying a quantum-resistant public key registry to establish a protocol foundation for account registration and use of quantum-resistant public keys; at the same time, decoupling consensus is currently the leading core candidate direction for this version, with large-scale state structure design and migration work expected to begin from I*.
• J*: Establishing a "minimum viable quantum resistance" layer, namely MV-PQ. Its key components include a quantum-resistant heartbeat mechanism for the consensus layer, post-quantum leanDA sampling for the data layer, and post-quantum leanSPHINCS transactions for the execution layer.
• K*: According to the current baseline ordering, introducing mandatory execution proofs. At that time, the development direction for validators will be to verify concise execution proofs, rather than having each validator re-execute the entire block.
• L*: According to the current baseline ordering, supplementing the quantum-resistant proof messages required to achieve complete quantum consensus, namely post-quantum attestations, and reaching the complete quantum resistance goals for the execution layer, consensus layer, and data layer by December 2029.

However, the task order for K* and L* has not yet been finalized. The protocol team is evaluating a swapping scheme: bringing the quantum-resistant proof messages from L* forward to K*, allowing for the earlier realization of complete quantum resistance capabilities; while postponing the mandatory execution proofs from K* to L*. If this scheme is adopted, the specific responsibilities and upgrade rhythm 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 complete quantum resistance capabilities in the baseline roadmap; the internal ordering of K and L* may still be adjusted.

Researchers, client developers, security auditors, and testing teams must complete Hegotá while also preparing standards and prototypes for I*, J*, K*, and L* in advance. If Hegotá incorporates too many interrelated functions, it may not only delay its own launch but also occupy the teams needed for subsequent quantum resistance work.

Thus, the Ethereum Foundation's protocol team has categorized the Hegotá candidate proposals into levels S (2 items), A (15 items), B (8 items), C (7 items), DFI (28 items), and TBD (2 items), totaling 62 candidate proposals. Level S represents must-deliver items; level A represents high priority, expected to be delivered; level B still needs to meet conditions such as standardization, prototyping, or confirmation from responsible parties; level C is temporarily below the inclusion line; DFI indicates not recommended for this upgrade; and TBD indicates pending.

Hegotá's two S-level proposals: FOCIL and Frames

In the Hegotá grading published by the protocol team, only two EIPs entered level S: EIP-7805 FOCIL from the consensus layer and EIP-8141 Frame transactions from the execution layer.

They address two critical issues in the transaction lifecycle: whether a qualifying 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 the assurance of transaction inclusion in Ethereum.

Currently, professional block builders dominate block generation. This division of labor helps improve block construction efficiency, but if block production is long-term concentrated in the hands of a few builders, they may also gain significant transaction filtering power. Therefore, FOCIL adds a layer of inclusion constraints from validators outside the normal block construction process.

According to FOCIL's design, each Slot will select a group of validators to form an "Inclusion List Committee" (IL committee). Committee members will create and broadcast inclusion lists based on the pending transactions they see. The block builders for the next Slot will collect these lists and include transactions that meet execution conditions when constructing blocks. Validators responsible for proving the new block will also retain the inclusion lists they received in a timely manner and check whether the block meets the corresponding requirements.

If a block unjustifiably omits transactions from the lists saved by validators, the prover will not vote for that block. Such a block, even if still valid at the execution level, will not receive the consensus support needed to enter the canonical chain. This is the significance of FOCIL: it does not allow committee members to directly modify blocks, but constrains the choices of block builders through whether validators vote.

The accompanying EIP-8369 further describes which transactions are suitable for mandatory inclusion assurance under FOCIL. The reasons for omission of ordinary transactions are relatively easy to verify; Frames transactions allow programmable verification, which incurs higher judgment costs, thus requiring additional limitations on the readable state range and verification budget.

In simple terms, FOCIL does not allow validators to take over the work of block builders, but adds a consensus layer rule for builders: you can still arrange most transactions in the block, but you cannot continuously ignore qualified transactions listed by the committee without reasonable cause.

Frame Transactions (EIP-8141) address account layer issues. It plans to make transaction verification, 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 hope to allow accounts to use more flexible verification logic, such as adopting new signature schemes, combining multiple authorization conditions, or allowing other accounts to pay transaction fees. It can also support signature aggregation and allow for the introduction of new signature schemes in the future without needing a hard fork for each scheme.

However, Frames itself is not a complete quantum-resistant signature scheme and will not immediately replace existing keys after Hegotá goes live. It provides "cryptographic agility": in the future, if a signature scheme needs to be changed, accounts can complete the migration through programmable verification, rather than being permanently locked into one key system.

Frames also require two A-level proposals as core support. EIP-8250 Keyed Nonces allows the same sender to use mutually independent nonce channels, so different transactions do not block each other due to sharing a strict order; EIP-8272 allows transactions to use recent on-chain states available for validators to check, enabling relevant privacy transactions to also gain the inclusion assurance provided by FOCIL.

Therefore, FOCIL and Frames are not two unrelated functions. The former changes which qualifying transactions must be included in blocks, while the latter changes the verification structure of the transactions themselves. Whether the two can safely work together is one of the most important testing tasks for Hegotá.

Besides S-level, which other EIPs are worth noting?

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

First is EIP-8365. It plans to initiate a gradual exit from certain BLS withdrawal credentials, as these credentials still rely on cryptographic technologies that may lose security under sufficiently strong quantum attacks. The protocol team believes this migration can begin early, without waiting for the complete design of quantum consensus to be finalized.

In terms of account security, EIP-7906, EIP-8298, and EIP-8151 are seen as extensions of Frames.

EIP-7906 introduces a Transaction Assertions mechanism, allowing transactions to check whether specified results occur before final submission. This mechanism aims to reduce losses caused by malicious contracts draining wallet assets and some MEV behaviors. However, the specific reading range of this proposal is still under research and narrowing, so the current design cannot 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 existing account code addresses from continuing to rely on traditional ecRecover authentication.

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

EIP-8025 (optional execution proofs) relates to the future zkEVM roadmap. It plans to incorporate the changes needed for optional execution proofs into a unified execution specification, reducing the long-term maintenance issues of different zkVM projects with their forked versions.

EIP-8279 (block access list Byte layer) and EIP-8131 (unified transaction content layer) are a set of execution security proposals. Both set minimum pricing standards for block access lists and transaction content, aiming to limit attackers from creating extreme resource burdens by exploiting underpriced content. They primarily address the worst-case block processing costs, rather than directly announcing an increase in network capacity. Whether to utilize the resulting security surplus to expand capacity will require separate decisions in the future.

EIP-3298 plans to completely remove the Gas refund mechanism, reducing special cases in measurement, implementation, and testing; EIP-5920 (PAY Opcode) allows contracts to transfer ETH without executing the receiving party's code, clearly separating "transferring value" from "calling contracts."

Meanwhile, some proposals of interest remain at level B.

For example, EIP-8198 (Quick Slots) hopes to shorten Slot time, but the protocol team requires it to first complete specifications covering core protocol changes, a complete prototype, downstream impact assessments, and prove that it will not interfere with subsequent decoupling consensus designs. The reason is that Slot time affects not only block speed but also network propagation, consensus judgment, and application assumptions about time.

Additionally, EIP-8368 and EIP-8372 are listed as "TBD" (to be determined). These two proposals involve Gas limits and state resource pricing, and the protocol team has decided to wait for mainnet data after Glamsterdam goes live in December 2026 before determining whether recalibration is needed.

The ultimate number of EIPs included in Hegotá is not the only standard for measuring the success of this upgrade.

More importantly, it is whether it can deliver FOCIL, Frames, and their core support without sacrificing security and testing quality, while leaving enough R&D resources for public key registration and decoupling consensus for I*, minimum viable quantum resistance for J*, and execution proofs and complete quantum consensus for K* and L*.

According to the current goals, Glamsterdam will kick off this compact upgrade cycle in December 2026, with L* in the baseline roadmap reaching its endpoint in December 2029. Each upgrade in between must not only focus on completing its own functions but also ensure that the next phase can continue to progress.

Whether the quantum threat will become a reality before 2030, no one can provide a definitive answer. But Ethereum's current choice is already clear: first set a deadline for the risk, and then let each proposal prove itself capable of entering the mainnet through standards, prototypes, and testing.

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