Quantum computers have not yet become a practical attack tool against blockchains, but the Ethereum Foundation has already marked a date on the calendar: December 2029.
According to the Ethereum Foundation protocol team’s current plan, Ethereum layer 1 is being prepared under a conservative engineering assumption that "Q-day" could arrive as early as 2030. The target is to have the execution, consensus, and data layers fully post-quantum ready by December 2029. Hegotá would not itself turn Ethereum into a fully post-quantum blockchain, but it is expected to determine whether the rest of the roadmap can proceed on time.
Why the Ethereum Foundation chose December 2029
"Q-day" is commonly used to describe a hypothetical moment when quantum computers gain real-world offensive capability and existing public-key cryptography faces a material threat. The Ethereum Foundation said most credible forecasts still place Q-day after 2030, possibly far later, and it also acknowledged the possibility that such a day may not arrive for a long time.
Even so, the protocol team is working from a stricter planning assumption: Ethereum layer 1 should prepare as if Q-day could come as early as 2030. On that basis, the team set a goal of reaching full post-quantum capability across the base layer by December 2029.
The date is not completely fixed forever. The protocol team plans to revisit the state of quantum computing in January 2027 with input from external experts. Until then, the 2029 deadline is being treated as a firm working target.
The reason is structural. Ethereum does not rely on a single cryptographic primitive, and migration is not a matter of swapping one signature scheme for another. Transaction authorization, validator participation in consensus, and data verification all involve different cryptographic components. Any change would need specification work, client implementation, security review, devnet testing, and mainnet coordination, which leaves little room for a last-minute response.
Hegotá is not the post-quantum fork, but it is the first exam
Under the baseline roadmap published by the protocol team, the Glamsterdam network upgrade is targeted for Ethereum mainnet in December 2026. Full post-quantum capability sits further down the line at L*, the fifth hard fork after Glamsterdam, with a target date of December 2029.
That gives Ethereum only three years from Glamsterdam to L*. If Hegotá, I*, J*, K*, and L* all need to be delivered in sequence, the average gap between upgrades is about 7.2 months.
That is an aggressive schedule. The Ethereum Foundation has not published final mainnet dates for Hegotá, I*, J*, or K*. What is known is that client teams expect implementation work on Hegotá to begin no earlier than late Q4 2026, while research, specifications, and testing for later releases will need to move in parallel.
Under the current roadmap, the stages break down as follows:
- Hegotá: the starting point. The protocol team has been explicit that it is not itself a post-quantum upgrade, but it will determine whether the later post-quantum upgrades can remain on schedule.
- I*: deployment of a post-quantum public key registry to create the protocol basis for registering and using post-quantum public keys at the account level. Decoupled consensus is the leading core candidate for this release, and larger state-structure design and migration work is also expected to begin here.
- J*: introduction of a minimum viable post-quantum layer 1, or MV-PQ. The key pieces 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*: in the current baseline ordering, this is where mandatory execution proofs would be introduced. The longer-term direction is for validators to verify concise execution proofs rather than re-execute full blocks individually.
- L*: in the current baseline ordering, this release adds the post-quantum proof messages needed for full post-quantum consensus, namely post-quantum attestations, and reaches the December 2029 goal of full post-quantum capability across the execution, consensus, and data layers.
The sequencing of K* and L* is not final. The protocol team is evaluating a swap that would move post-quantum proof messages from L* into K*, bringing full post-quantum capability forward, while pushing mandatory execution proofs from K* into L*. If adopted, that change would alter both the responsibilities of K* and L* and the rhythm of the upgrade cycle.
For now, the most precise description is this: December 2026 remains the current mainnet target for Glamsterdam; December 2029 remains the baseline target for L* and full post-quantum capability; the internal ordering of K* and L* can still change.
That is why the scope of Hegotá matters so much. Researchers, client developers, security reviewers, and testing teams must not only deliver Hegotá, but also prepare specifications and prototypes for I*, J*, K*, and L* in advance. If Hegotá absorbs too many tightly coupled features, it could delay itself and pull engineering resources away from later post-quantum work.
How Hegotá’s candidate proposals are being ranked
The Ethereum Foundation protocol team has grouped Hegotá’s candidate proposals into six buckets: S, A, B, C, DFI, and TBD. There are 62 candidate proposals in total: 2 in S, 15 in A, 8 in B, 7 in C, 28 in DFI, and 2 in TBD.
The categories have specific meanings. S means must-deliver. A signals high priority and expected delivery. B still depends on conditions such as specification maturity, prototype work, or owner confirmation. C sits below the inclusion line for now. DFI means the proposal is not recommended for this upgrade. TBD means undecided.
Only two EIPs are currently in the S tier: EIP-7805 FOCIL on the consensus side and EIP-8141 Frame Transactions on the execution side.
The two S-tier EIPs: FOCIL and Frames
Each addresses a different part of the transaction lifecycle: whether an eligible transaction can make it into a block, and how an account can validate and execute a transaction.
FOCIL: adding consensus pressure around inclusion
FOCIL, or EIP-7805, stands for Fork-choice enforced Inclusion Lists. Its purpose is to improve transaction inclusion guarantees on Ethereum.
Today, specialized block builders dominate block production. That division of labor helps block construction efficiency, but if production remains concentrated among a small number of builders, they may also gain stronger filtering power over which transactions get included. FOCIL adds a validator-driven inclusion constraint on top of the ordinary block-building flow.
Under the design, a group of validators is selected in each slot to form an inclusion list committee. Committee members create and broadcast inclusion lists based on the pending transactions they see. The block builder for the next slot collects those lists and includes transactions that satisfy execution conditions. Validators responsible for attesting to the new block keep the inclusion lists they received in time and check whether the block satisfies those requirements.
If a block omits listed transactions without a valid reason, attesters do not vote for that block. In that case, the block may still be valid at the execution layer, but it would not gain the consensus support needed to become canonical.
That is the core of FOCIL. It does not allow committee members to rewrite blocks directly. It uses validator votes to constrain builders, making it harder to repeatedly ignore eligible transactions without justification.
The companion proposal EIP-8369 goes further by describing which kinds of transactions are suitable for FOCIL’s forced-inclusion guarantee. Omissions are relatively straightforward to assess for ordinary transactions. Frame Transactions permit programmable validation, which is more costly to evaluate, so the proposal imposes additional limits on readable state and verification budget.
Frames: building programmable validation into the account layer
Frame Transactions, or EIP-8141, focus on the account layer. The proposal would make transaction validation, execution, and gas payment more programmable at the protocol level, laying a foundation for native account abstraction. Vitalik Buterin is listed as a co-author of EIP-8141.
Most ordinary Ethereum accounts today rely on fixed private-key signature types. Frames is meant to support more flexible validation logic, such as new signature schemes, combinations of multiple authorization conditions, or gas being paid by a different account. It can also support signature aggregation and allow new schemes to be introduced later without requiring a separate hard fork for each one.
Frames is not, by itself, a complete post-quantum signature scheme, and it would not retire existing keys as soon as Hegotá goes live. What it provides is cryptographic agility. If Ethereum later needs to move to a new signature model, accounts could migrate through programmable validation rather than remain permanently tied to one key system.
Frames also depends on two A-tier proposals as core companions. EIP-8250 Keyed Nonces would let the same sender use independent nonce channels, so different transactions do not block one another merely because they share a single strict ordering. EIP-8272 would allow transactions to rely on recent onchain state that validators can inspect, enabling related privacy transactions to qualify for the inclusion guarantees provided by FOCIL.
That means FOCIL and Frames are not separate stories. One changes which eligible transactions a block must include; the other changes the structure used to validate those transactions. Whether they can operate together safely is one of the central tests for Hegotá.
A-tier proposals also shape security, migration, and execution
The S-tier proposals define Hegotá’s spine, but a number of A-tier EIPs also matter for Ethereum’s future account security, post-quantum migration path, execution proofs, and resource pricing.
EIP-8365: phasing out some BLS withdrawal credentials
EIP-8365 would start a gradual exit for some BLS withdrawal credentials because they still depend on cryptography that may not remain secure against sufficiently strong quantum attacks. The protocol team’s view is that this migration can begin early, without waiting for the final shape of full post-quantum consensus.
Account security extensions: EIP-7906, EIP-8298, and EIP-8151
On account security, EIP-7906, EIP-8298, and EIP-8151 are being treated as an extension set for Frames.
EIP-7906 introduces Transaction Assertions, a mechanism that would let a transaction check whether a specified outcome has occurred before final submission. The aim is to reduce losses from malicious contracts draining wallet assets, along with some damage associated with MEV behavior. The proposal’s exact read scope is still under study and being narrowed, so the current design should not be described as a final specification.
EIP-8298 would let accounts reuse existing contract code, pushing delegated accounts closer to becoming fully coded smart contract accounts. EIP-8151 would restrict addresses with existing account code from continuing to rely on traditional ecRecover authentication.
Taken together, those changes create a more complete path for accounts to stop treating old secp256k1 keys as the highest control credential and eventually move away from that legacy key system.
EIP-8025: optional execution proofs and the zkEVM path
EIP-8025 concerns optional execution proofs and is tied to Ethereum’s future zkEVM direction. The proposal would pull the required changes into a unified execution specification, reducing the need for different zkVM projects to keep maintaining divergent forked versions over the long term.
EIP-8279 and EIP-8131: execution safety and resource pricing
EIP-8279, described as a byte layer for block access lists, and EIP-8131, a unified transaction content layer, form a pair of execution-safety proposals. They would set minimum pricing standards for block access lists and transaction contents respectively, with the goal of limiting worst-case resource burdens created by underpriced content.
The immediate purpose is to address worst-case block processing costs, not to declare higher network capacity. Whether Ethereum later uses the resulting safety margin to expand capacity would be a separate decision.
EIP-3298 and EIP-5920: simplifying execution behavior
EIP-3298 would remove the gas refund mechanism entirely, reducing special cases in metering, implementation, and testing. EIP-5920, the PAY opcode proposal, would let contracts transfer ETH without executing receiver code, separating value transfer from contract invocation more clearly.
B-tier and TBD proposals remain unsettled
Some widely watched proposals remain in the B tier.
EIP-8198, known as Quick Slots, aims to shorten slot time. The protocol team said it first needs a specification that covers the core protocol changes, a complete prototype, downstream impact analysis, and evidence that it would not interfere with later decoupled-consensus work. The concern is broader than block speed: slot time affects network propagation, consensus judgment, and application-level assumptions about time.
Two other proposals, EIP-8368 and EIP-8372, are currently marked TBD. Both deal with gas limits and state resource pricing. The protocol team wants to wait for mainnet data after Glamsterdam goes live in December 2026 before deciding whether recalibration is needed.
Success will not be measured only by the EIP count
The final number of EIPs in Hegotá will not be the only measure of whether the upgrade succeeds. The larger question is whether Ethereum can ship FOCIL, Frames, and their core dependencies without sacrificing safety or testing quality, while still preserving enough research and engineering capacity for I* public-key registration and decoupled consensus, J* minimum viable post-quantum capability, and K* and L* work on execution proofs and full post-quantum consensus.
Under the current target, Glamsterdam would begin this compressed upgrade cycle in December 2026, and L* in the baseline roadmap would reach the finish line in December 2029. Each upgrade in between has to do more than complete its own feature set. It also has to leave the next phase workable.
No one can say with certainty whether the quantum threat will become real before 2030. Ethereum’s present choice is already clear: set the deadline first, then require each proposal to justify its place on mainnet through specifications, prototypes, and testing.
