Not a post-quantum upgrade, but determines the success or failure of post-quantum efforts: Understanding Hegotá.

Written by: KarenZ, Foresight News

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

It's an engineering deadline set by the Ethereum Foundation's Protocol Team: prepare for scenarios where quantum threats may emerge earlier, and strive to complete the post-quantum transformation of Ethereum Layer 1 before risks truly loom.

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

EF Sets an Early 2029 Deadline for "Q-day"

"Q-day" usually refers to a hypothetical point in time: when quantum computers with real-world attack capabilities emerge, existing public-key cryptosystems face substantial threats as a result.

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, and there's also the possibility it may never come.

The Ethereum Foundation's Protocol Team uses a conservative engineering assumption: Ethereum Layer 1 should prepare in advance for the scenario where Q-day could arrive as early as 2030.

To this end, the Protocol Team has set a goal: strive to enable Ethereum Layer 1's execution, consensus, and data components to have full post-quantum capabilities by December 2029.

This goal isn't set in stone. The Protocol Team plans to re-evaluate the development of quantum computing in January 2027, incorporating external expert opinions. Until then, the December 2029 deadline will be treated as a non-negotiable work target.

The reason post-quantum transformation requires years of advance preparation is that Ethereum doesn't use just one cryptographic technology, nor can migration be completed by replacing a single 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 review, testnet testing, and mainnet coordination—you can't wait until the threat has already emerged to start handling it.

Hegotá Isn't a "Post-Quantum Upgrade", But It's the First Exam 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 launch on the mainnet in December 2026, and full post-quantum capabilities are planned for L*, the fifth hard fork after Glamsterdam, with a target date of December 2029. From Glamsterdam to L* is only three years; if Hegotá, I*, J*, K*, and L* are completed in sequence, the average interval between each upgrade is about 7.2 months.

This is a rather aggressive timeline. Currently, the Ethereum Foundation hasn't announced definite mainnet launch dates for Hegotá, I*, J*, and K*. What's certain is that the client teams expect to start implementing Hegotá as early as late Q4 2026, and research, specification, 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 start of this roadmap. The official positioning is very clear: Hegotá itself isn't a post-quantum upgrade, but it will determine whether subsequent post-quantum upgrades can proceed on schedule.
• I*: Deploy a post-quantum public key registry to establish a protocol foundation for account registration and use of post-quantum public keys; at the same time, decoupling consensus is the leading core candidate direction for this version, and large-scale state structure design and migration work are also expected to start from I*.
• J*: Establish a "Minimum Viable Post-Quantum" Layer 1, i.e., MV-PQ. Its key components include a post-quantum heartbeat mechanism in the consensus layer, post-quantum leanDA sampling in the data layer, and post-quantum leanSPHINCS transactions in the execution layer.
• K*: According to the current baseline order, introduce mandatory execution proofs. At that time, validators will move toward verifying concise execution proofs instead of each validator re-executing the entire block.
• L*: According to the current baseline order, add the post-quantum attestation messages needed to achieve full post-quantum consensus, i.e., post-quantum attestations, and reach the full post-quantum goals for the execution, consensus, and data layers by December 2029.

However, the order of tasks for K* and L* hasn't been finalized. The Protocol Team is evaluating a swap plan: move post-quantum attestation messages from L* to K* to achieve full post-quantum capabilities earlier; at the same time, delay mandatory execution proofs from K* to L*. If this plan 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; December 2029 is the target for L* and full post-quantum capabilities in the baseline roadmap; the internal order 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 mutually influencing features, it may not only delay its own launch but also occupy the teams needed for subsequent post-quantum work.

Therefore, the Ethereum Foundation's 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) levels, totaling 62 candidate proposals. Level S means must deliver; Level A means high priority and expected to deliver; Level B requires meeting conditions such as specification, prototype, or owner confirmation; Level C is temporarily below the inclusion line; DFI means not recommended for this upgrade; TBD means to be determined.

Hegotá's Two S-Level Proposals: FOCIL and Frames

In the Hegotá classification published by the Protocol Team, only two EIPs have entered Level S: EIP-7805 FOCIL in the consensus layer and EIP-8141 Frame Transactions in the execution layer.

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 transactions.

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

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 a long time, they may also gain strong transaction filtering capabilities. Therefore, FOCIL adds an additional layer of inclusion constraints from validators outside the normal block building 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 builder for the next slot will collect these lists and add transactions that meet execution conditions when building the block. Validators responsible for attesting to the new block will also save the inclusion lists they receive in a timely manner and check whether the block meets the corresponding requirements.

If a block omits transactions from the lists saved by validators without just cause, the attesters will not vote for the block. Even if such a block is valid at the execution level, it cannot obtain the consensus support needed to enter the canonical chain. This is the significance of FOCIL: it doesn't allow committee members to directly modify blocks, but constrains the block builder's choices through whether validators vote.

The supporting EIP-8369 further describes which transactions are suitable for FOCIL's mandatory inclusion guarantees. The reasons for omitting ordinary transactions are relatively easy to verify; Frame Transactions allow programmable verification, which has a higher judgment cost, so additional restrictions on the state range that can be read and the verification budget are needed.

Put simply, FOCIL doesn't let validators take over the block builder's job; instead, it adds a consensus layer rule to builders: you can still arrange most transactions in the block, but you can't continuously ignore qualified transactions listed by the committee without a reasonable reason.

Frame Transactions (EIP-8141) address account layer issues. 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-type 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 letting other accounts pay transaction fees. It can also support signature aggregation and allow new signature schemes to be introduced later without needing a separate hard fork for each scheme.

But Frames itself isn't a complete post-quantum signature scheme, nor will it immediately淘汰 existing keys after Hegotá goes live. It provides "cryptographic agility": if a signature scheme needs to be replaced in the future, accounts can migrate through programmable verification instead of being permanently locked into one key system.

Frames also need two Level A proposals as core supporting components. EIP-8250 Keyed Nonces allows the same sender to use mutually independent nonce channels, so that different transactions don't block each other due to sharing a strict sequence; EIP-8272 allows transactions to use recent on-chain states that can be checked by validators, so that related privacy transactions can also obtain the inclusion guarantees provided by FOCIL.

Therefore, FOCIL and Frames are not two unrelated functions. The former changes which qualified transactions must be included in the block, and the latter changes the verification structure of the transaction itself. Whether the two can cooperate safely is one of the most important test tasks of Hegotá.

Beyond S-Level: Which Other EIPs Are Worth Paying Attention To?

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

First is EIP-8365. It plans to start the phased retirement of some BLS withdrawal credentials, as these credentials still rely on cryptographic technologies that may lose security in the face of sufficiently strong quantum attacks. The Protocol Team believes this migration can start early without waiting for the complete post-quantum consensus design to be finalized.

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

EIP-7906 introduces a Transaction Assertions mechanism, allowing transactions to check whether a specified result has occurred 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 complete code. EIP-8151 restricts addresses with existing account code from continuing to rely on traditional ecRecover authentication.

After combining these two proposals, accounts may truly stop using old secp256k1 keys as the highest control credentials, establishing a complete path for exiting the old key system in the future.

EIP-8025 (Optional Execution Proofs) is related to the future zkEVM roadmap. It plans to incorporate the changes needed for optional execution proofs into a unified execution specification, reducing the problem of different zkVM projects maintaining分叉 versions of each other for a long time.

EIP-8279 (Block Access List Byte Layer) and EIP-8131 (Unified Transaction Content Layer) are a set of execution security proposals. They set minimum pricing standards for block access lists and transaction content respectively, aiming to restrict attackers from using underpriced content to create extreme resource burdens. They first address the worst-case block processing cost, not directly announce an increase in network capacity. Whether to use the resulting security 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 the recipient's code, clearly separating "value transfer" and "contract call".

At the same time, some attention-grabbing proposals remain at Level B.

For example, EIP-8198 (Quick Slots) hopes to shorten the slot time, but the Protocol Team requires it to first complete the specification covering core protocol changes, a complete prototype, downstream impact assessment, and prove that it won't interfere with subsequent decoupled consensus design. The reason is that slot time not only affects block production speed but also network propagation, consensus judgment, and application assumptions about time.

In addition, EIP-8368 and EIP-8372 are classified 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 judging whether recalibration is needed.

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

More importantly, can it deliver FOCIL, Frames, and their core supporting components without sacrificing security and testing quality, while leaving sufficient R&D resources for I*'s public key registration and decoupled consensus, J*'s minimum viable post-quantum capabilities, and K* and L*'s execution proofs and full post-quantum consensus?

According to current goals, Glamsterdam will launch this compact 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 functions but also must ensure that the next phase can continue to advance.

No one can give a definite answer as to whether quantum threats will become a reality before 2030. But Ethereum's current choice is clear: first set a deadline for risks, then let each proposal prove its eligibility to enter the mainnet through specifications, prototypes, and tests.

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