Not a quantum resistance upgrade, but it will determine the success or failure of quantum resistance: Understanding Hegotá.

Written by: KarenZ, Foresight News

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

This is the engineering deadline set by the Ethereum Foundation's protocol team: to prepare for scenarios in which the quantum threat may arise earlier, aiming to complete the quantum-resistant transformation of Ethereum's layer one network before the risk truly approaches.

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

EF has set a December 2029 deadline for “Q-day”

“Q-day” usually refers to a hypothetical time point: the emergence of quantum computers with real attack capabilities, thus posing a substantial threat to existing public-key cryptography systems.

No one can accurately predict when it will arrive. The Ethereum Foundation has also explicitly acknowledged that most credible predictions suggest Q-day will occur later than 2030, and it may even be significantly later, or it may not arrive at all.

The Ethereum Foundation's protocol team has adopted a somewhat conservative engineering assumption: Ethereum's layer one 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 ensure that by December 2029, the execution, consensus, and data components of Ethereum’s layer one have complete quantum resistance capabilities.

This goal is not set in stone and will not be adjusted indefinitely. The protocol team plans to reassess the developments in quantum computing in January 2027 based on feedback from external experts. Until then, the December 2029 deadline will be regarded as a work goal not to be easily compromised.

The reason for needing several years of preparation for the quantum resistance transformation is that Ethereum does not only use one cryptographic technology, nor can the migration be completed simply by changing 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 modifications must undergo standardized design, client implementation, security review, network testing, and mainnet coordination, making it impossible to wait until the threat has emerged to start addressing it.

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

According to the benchmark roadmap announced by the Ethereum Foundation's protocol team, the Glamsterdam network upgrade is scheduled to go live on the mainnet in December 2026, while complete quantum resistance capabilities are arranged for the fifth hard fork L* after Glamsterdam, with a target date of December 2029. There are only three years from Glamsterdam to L*, and in order to complete Hegotá, I*, J*, K*, and L* in succession, there are only about 7.2 months on average between each upgrade.

This is quite an aggressive timeline. Currently, the Ethereum Foundation has not announced specific mainnet launch times for Hegotá, I*, J*, and K*. What is certain is that the client team expects to implement Hegotá as early as late Q4 2026, while multiple subsequent versions' research, standards, and testing must be advanced in parallel.

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

• Hegotá: Located 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 be advanced on time.
• I*: Deploy 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 currently leading core candidate direction for this version, with larger-scale state structure design and migration work also expected to begin from I*.
• J*: Establishing the "minimum viable quantum resistance" layer, namely MV-PQ. Its key components include a consensus layer quantum-resistant heartbeat mechanism, a data layer post-quantum leanDA sampling, and an execution layer post-quantum leanSPHINCS transaction.
• K*: According to the current benchmark order, introducing mandatory execution proofs. At that point, the development direction for validators will focus on validating concise execution proofs rather than each validator re-executing the entire block.
• L*: Following the current benchmark order, supplementing the quantum-resistant proof messages necessary to achieve complete quantum-resistant consensus, namely post-quantum attestations, and reaching the goal of complete quantum resistance 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 switching proposal: moving the quantum-resistant proof messages from L* to K*, allowing complete quantum resistance capabilities to be realized earlier; while postponing the mandatory execution proofs from K* to L*. If this plan is adopted, the specific responsibilities of K* and L* and the upgrade pace will change accordingly. Therefore, the most accurate statement at this stage is: December 2026 is the current mainnet goal for Glamsterdam, and December 2029 is the target for L* and complete quantum resistance capabilities in the benchmark roadmap; the internal ordering of K and L* may still be adjusted.

Researchers, client developers, security auditors, and testing teams need to not only complete Hegotá but also prepare standards and prototypes for I*, J*, K*, and L* in advance. If Hegotá includes too many interdependent features, it may not only delay its own launch but also occupy the teams needed for subsequent quantum resistance work.

Therefore, the Ethereum Foundation's protocol team has categorized the Hegotá candidate proposals into S (2 items), A (15 items), B (8 items), C (7 items), DFI (28 items), and TBD (2 items), totaling 62 candidate proposals. S level represents must-deliver; A level represents high priority, expected delivery; B level must meet conditions such as specification, prototype, or confirmation from responsible parties; C level temporarily falls below the inclusion line; DFI indicates not recommended for this upgrade; TBD indicates pending.

Two S Levels in Hegotá: FOCIL and Frames

Among the graded proposals for Hegotá announced by the protocol team, only two EIPs entered the S level: consensus layer EIP-7805 FOCIL and execution layer EIP-8141 Frame transactions.

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

FOCIL (EIP-7805) stands for "Fork-choice Enforced Inclusion Lists." Its goal is to improve the transaction inclusion guarantee of Ethereum.

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

According to the design of FOCIL, 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 builder for the next slot will collect these lists and incorporate transactions that meet execution conditions when building the block. Validators responsible for proving the new block will also keep the inclusion lists they receive promptly and check whether the block meets the corresponding requirements.

If a block improperly omits transactions from the inclusion list stored by the validators without justifiable reason, the proposer will not vote for that block. Such blocks, even if valid from the execution perspective, cannot obtain the consensus support needed to enter the canonical chain. This is the significance of FOCIL: it does not allow committee members to directly modify the block but constrains the block builder's choices through whether validators vote.

Accompanying EIP-8369 further describes which transactions are suitable to receive FOCIL's mandatory inclusion guarantees. Ordinary transaction omissions are relatively easy to verify; Frame 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 let validators 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 cannot continuously ignore qualified transactions listed by the committee without reasonable cause.

Frame Transactions (EIP-8141) address account layer issues. It aims to make transaction verification, transaction execution, and gas payments more programmable at the protocol level, 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 the need for a separate 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 offers "cryptographic agility": if it becomes necessary to change the signature scheme in the future, accounts can complete migration through programmable verification instead of being locked into one key system permanently.

Frames will also require two A level proposals as critical support. EIP-8250 Keyed Nonces allows the same sender to use independent nonce channels, so that different transactions do not block each other due to sharing a strict order; EIP-8272 then enables transactions to use recent on-chain states verifiable by validators, allowing relevant privacy transactions to also receive the inclusion guarantees provided by FOCIL.

Thus, FOCIL and Frames are not two unrelated functions. The former alters which qualified transactions must be included in a block, 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á.

What other EIPs are worth watching besides S level?

The S level proposals define the main line of Hegotá, but multiple A level proposals will also affect the future account security, quantum resistance migration, execution proofs, and resource pricing of Ethereum.

First is EIP-8365. It plans to initiate a gradual exit for some BLS withdrawal certificates because these certificates still rely on cryptographic technology that may lose security in the face of sufficiently strong quantum attacks. The protocol team believes this migration can begin in advance without waiting for the complete quantum-resistant consensus design to be finalized.

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

EIP-7906 introduces a Transaction Assertions mechanism, allowing transactions to verify whether specified outcomes occur before final submission. This mechanism aims to reduce losses caused by malicious contracts withdrawing 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 finalized specification.

EIP-8298 allows accounts to reuse existing contract code, enabling delegated accounts to further transform into smart contract accounts with complete code ownership. EIP-8151 limits 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 phasing out old key systems in the future.

EIP-8025 (optional execution proofs) relates to future zkEVM routes. It aims to incorporate the changes required for optional execution proofs into a unified execution specification to reduce problems with different zkVM projects maintaining their own forked versions long-term.

EIP-8279 (block access list Byte layer) and EIP-8131 (unified transaction content layer) represent a group of execution security proposals. Both set minimum pricing standards for block access lists and transaction contents to limit attackers from exploiting low-priced content to create extreme resource burdens. They primarily address the cost of block processing in the worst-case scenario rather than directly announcing an increase in network capacity. Whether to utilize the resulting security margin to expand capacity will require separate decisions 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 the recipient's code, clearly separating "transfer value" from "calling contracts."

At the same time, some concerned proposals remain at B level.

For example, EIP-8198 (Quick Slots) hopes to shorten slot time, but the protocol team requires it first to complete the specification, complete prototype, downstream impact assessment covering core protocol changes, and demonstrate that it will not interfere with subsequent decoupled consensus designs. This is because 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 marked as "TBD" (to be determined). These two proposals concern gas limits and state resource pricing, and the protocol team has decided to wait for mainnet data after Glamsterdam launches in December 2026 to reassess the need for recalibration.

How many EIPs are ultimately 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 compromising security and testing quality, while leaving sufficient R&D resources for I*'s public key registration and decoupled consensus, J*'s minimum viable quantum resistance capabilities, as well as K* and L*'s execution proofs and complete quantum consensus.

According to the current goals, Glamsterdam will initiate this compact upgrade cycle in December 2026, with the benchmark roadmap's L* arriving at the finish line by 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.

No one can give a definitive answer as to whether the quantum threat will become a reality before 2030. But Ethereum's current choice is clear: first set deadlines for risks, and then let each proposal prove its readiness to enter the mainnet through standards, 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