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.
This is the engineering deadline the Ethereum Foundation's Protocol Support Team has set for itself: to prepare for a scenario where quantum threats might emerge relatively early, aiming to complete the quantum-resistant transformation of the Ethereum Layer 1 network before the risk truly becomes imminent.
The currently planned Hegotá, while not directly transforming Ethereum into a fully quantum-resistant blockchain, will determine whether subsequent plans can proceed on schedule.
EF Sets an Early 2029 Deadline for "Q-day"
"Q-day" typically refers to a hypothetical point in time: the emergence of quantum computers with practical attack capabilities, posing a substantial threat to existing public-key cryptography systems.
No one can predict exactly when it will arrive. The Ethereum Foundation also explicitly acknowledges that most credible predictions suggest Q-day will occur after 2030, possibly much later, and there's also a chance it may never arrive.
The Ethereum Foundation Protocol Support Team is adopting a conservative engineering assumption: the Ethereum Layer 1 should prepare in advance as if Q-day could arrive as early as 2030.
To this end, the Protocol Team has proposed a goal: to strive for the execution, consensus, and data layers of Ethereum Layer 1 to possess complete quantum resistance by December 2029.
This goal is not set in stone forever. 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 non-negotiable work target.
The quantum-resistant upgrade requires preparation years in advance because Ethereum doesn't use just one cryptographic technology, and it's not as simple as swapping out a signature algorithm. User accounts proving transaction authorization, validators participating in consensus, and data verification all involve different cryptographic structures. Any modification must go through specification design, client implementation, security review, devnet testing, and mainnet coordination—it cannot wait until the threat has already materialized.
Hegotá Is Not the "Quantum-Resistant Upgrade," But It Is the First Test for 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. Full quantum resistance is scheduled for L*, the fifth hard fork after Glamsterdam, with a target date of December 2029. From Glamsterdam to L* is only three years, and to complete Hegotá, I*, J*, K*, and L* sequentially, there would be only about 7.2 months on average between each upgrade.
This is a rather aggressive timeline. Currently, the Ethereum Foundation has not announced definitive mainnet launch dates for Hegotá, I*, J*, and K* individually. What is certain is that client teams are expected to begin implementing Hegotá as early as late Q4 2026, while 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á: Located at the starting point of this roadmap. Its 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 accounts to register and use quantum-resistant public keys; concurrently, decoupled consensus is currently the leading core candidate direction for this version. Larger-scale state structure design and migration work are also expected to begin with I*.
- J*: Establish a "Minimum Viable Post-Quantum" Layer 1, i.e., 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 sequencing, introduce enforced execution proofs. The direction for validators will then be to verify succinct execution proofs, rather than each validator re-executing the full block.
- L*: According to the current baseline sequencing, add the quantum-resistant proof messages required for achieving full quantum-resistant consensus, i.e., post-quantum attestations, reaching the goal of full quantum resistance for the execution, consensus, and data layers by December 2029.
However, the order of tasks for K* and L* is not yet final. The Protocol Team is evaluating a swap option: moving quantum-resistant proof messages from L* forward to K*, enabling full quantum resistance earlier; and simultaneously postponing enforced execution proofs from K* to L*. If this option is adopted, the specific responsibilities and upgrade cadence for 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 sequencing of K* and L* may still be adjusted.
Researchers, client developers, security reviewers, and testing teams must not only complete Hegotá but also prepare specifications and prototypes for I*, J*, K*, and L* in advance. If Hegotá includes too many interdependent features, it could not only delay its own launch but also consume team resources needed for subsequent quantum-resistant work.
Therefore, the Ethereum Foundation Protocol Team has categorized 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 signifies must-deliver; A-tier signifies high priority, expected to be delivered; B-tier still needs to meet conditions like finalized specifications, prototypes, or confirmed leads; C-tier is temporarily below the inclusion line; DFI indicates not recommended for this upgrade; TBD means to be determined.
Hegotá's Two S-Tier Proposals: FOCIL and Frames
In the tier list published by the Protocol Team, only two EIPs are in the S-tier: EIP-7805 FOCIL for the consensus layer, and EIP-8141 Frame transactions for 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 authorize and execute a transaction.
FOCIL (EIP-7805) stands for "Fork-choice enforced Inclusion Lists." Its goal is to improve transaction inclusion guarantees on Ethereum.
Currently, professional block builders dominate block construction. This division of labor helps improve block building efficiency, but if block production becomes concentrated among a few builders long-term, they could gain significant transaction filtering power. FOCIL adds an extra layer of inclusion constraint from validators alongside the normal block building process.
According to FOCIL's design, a set of validators is selected each Slot to form an "Inclusion List Committee" (IL committee). Committee members, based on the pending transactions they see, create and broadcast their own inclusion lists. The block builder for the next Slot collects these lists and includes transactions from them that meet execution conditions when constructing the block. Validators attesting to the new block also save the inclusion lists they received in time and check if the block meets the corresponding requirements.
If a block, without valid reason, omits transactions from an inclusion list saved by an attester, that attester will not vote for the block. Such a block, even if valid at the execution layer, cannot gain the consensus support needed to enter the canonical chain. This is the essence of FOCIL: it doesn't let committee members directly modify blocks but constrains the builder's choices through whether validators vote.
The companion EIP-8369 further describes which transactions are suitable for receiving FOCIL's forced inclusion guarantee. Reasons for omitting ordinary transactions are relatively easier to verify; Frame transactions allow programmable validation, which has a higher verification cost, thus requiring additional limits on readable state scope and verification budget.
In simple terms, FOCIL doesn't take the block builder's job away from them; it adds a consensus layer rule: you can still arrange most transactions in the block, but you cannot, without reasonable cause, continuously ignore the eligible transactions listed by the committee.
Frame Transactions (EIP-8141) deals with the account layer. It plans to make transaction validation, 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 regular Ethereum accounts rely on fixed-type private key signatures. Frames aims to allow accounts to use more flexible validation 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 the introduction of new signature schemes in the future without needing a separate hard fork for each one.
However, Frames itself is not a full quantum-resistant signature scheme, nor will it immediately obsolete existing keys upon Hegotá's launch. It provides "cryptographic agility": in the future, if a signature scheme needs to be replaced, accounts can complete the migration through programmable validation, 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 independent nonce channels, preventing different transactions from blocking each other due to sharing a strict sequence; EIP-8272 enables transactions to use recent on-chain state that validators can check, allowing related privacy transactions to also receive the inclusion guarantee provided by FOCIL.
Therefore, FOCIL and Frames are not two unrelated features. The former changes which eligible transactions a block must include; the latter changes the validation structure of the transaction itself. Whether they can interact safely is one of the most critical testing tasks for Hegotá.
Beyond the S-Tier, Which Other EIPs Are Worth Noting?
S-tier proposals define the main thrust of Hegotá, but several A-tier proposals will also impact Ethereum's future account security, quantum migration, execution proofs, and resource pricing.
First is EIP-8365. It plans to initiate the gradual exit of certain BLS withdrawal credentials, as these credentials still rely on cryptographic techniques that could become insecure against a sufficiently powerful quantum attack. The Protocol Team believes this migration can start early, without waiting for the full quantum-resistant consensus design to be finalized.
Regarding account security, EIP-7906, EIP-8298, and EIP-8151 are seen as an extension suite for Frames.
EIP-7906 introduces a Transaction Assertions mechanism, allowing transactions to check whether specified outcomes occur before final commitment. This mechanism aims to reduce losses caused by malicious contracts draining wallet assets and certain MEV behaviors. However, the specific read scope of this proposal is still under research and being narrowed, so the current design cannot be treated as a locked final specification.
EIP-8298 allows accounts to reuse existing contract code, enabling delegated accounts to further evolve into smart contract accounts with full code. EIP-8151 restricts addresses with existing account code from continuing to rely on traditional ecRecover authentication.
Combined, these two proposals establish a complete path for accounts to potentially stop using old secp256k1 keys as the supreme control credential, paving the way for eventually phasing out the old key system.
EIP-8025 (Optional Execution Proofs) relates to the future zkEVM roadmap. It plans to incorporate the changes needed for optional execution proofs into the unified execution specification, reducing the long-term maintenance burden of different zkVM projects maintaining their own forked versions.
EIP-8279 (Block Access List Byte Layer) and EIP-8131 (Uniform Transaction Content Layer) are a set of execution security proposals. They respectively set minimum pricing standards for block access lists and transaction content, aiming to limit attackers from creating extreme resource burdens using underpriced content. They primarily address worst-case block processing costs rather than directly announcing increased network capacity. Whether to utilize the resulting security margin to expand capacity requires separate future decisions.
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 code, clearly separating "transfer of value" from "contract call."
Meanwhile, some proposals of interest remain in the B-tier.
For example, EIP-8198 (Quick Slots) aims to shorten Slot time, but the Protocol Team requires it to first complete specifications covering core protocol changes, a full prototype, assessment of downstream impact, and proof that it won't interfere with subsequent decoupled consensus design. The reason is that Slot time affects not only block speed but also network propagation, consensus judgment, and application time assumptions.
Furthermore, EIP-8368 and EIP-8372 are listed as "TBD" (To Be Determined). These proposals involve Gas limit and state resource pricing. The Protocol Team has decided to wait for mainnet data after Glamsterdam's launch in December 2026 before judging whether recalibration is needed.
The number of EIPs Hegotá ultimately includes is not the sole measure of the upgrade's success.
More importantly, can it deliver FOCIL, Frames, and their core companions without sacrificing security and testing quality, while also leaving sufficient R&D resources for I*'s public key registry and decoupled consensus, J*'s minimum viable quantum resistance, and the execution proofs and full quantum-resistant consensus of K* and L*?
According to current targets, Glamsterdam will kick off this intensive upgrade cycle in December 2026, and L* in the baseline roadmap will reach the finish line in December 2029. Every upgrade in between cannot just focus on completing its own features; it must also ensure the next stage can continue to advance.
Whether the quantum threat will become a reality before 2030, no one can give a definitive answer. But Ethereum's current choice is clear: first set a deadline for the risk, then let each proposal prove its readiness for mainnet with specifications, 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
