Quantum computers are not suddenly breaking Ethereum keys. What changed is that Ethereum has stopped treating that fact as a reason to wait.
The Foundation's Protocol cluster is now planning around Q-day occurring as early as 2030. It explicitly describes that assumption as aggressive: credible estimates generally place a cryptographically relevant quantum computer later, sometimes much later, and the feared event may never arrive at all.
The engineering problem is migration time. Replacing cryptography on a global decentralized protocol requires specifications, implementations, interoperability work, audits, test networks and eventually coordinated hard forks. By the time an attack becomes practical, beginning that process would be far too late.
Ethereum has three different quantum problems
The target covers execution, consensus and data because each layer depends on cryptography differently. User accounts can be redesigned around programmable validation. Validator signatures and their aggregation are much less flexible. Data-availability mechanisms need their own post-quantum components as well.
That distinction shapes the roadmap. Execution can gain cryptographic agility: an account should eventually be able to adopt a different signature scheme without Ethereum adding a bespoke hard fork every time the preferred algorithm changes.
Consensus cannot work that way. Every validator has to speak a compatible cryptographic language, so new aggregation and attestation schemes need to be tested, standardized and activated network-wide.
Hegotá is infrastructure for the migration, not the quantum-safe fork
The Foundation describes Hegotá in unusually direct terms: it is not the post-quantum fork. It is the fork that determines whether the later post-quantum forks can arrive on schedule.
EIP-8141 Frame Transactions is one of its two must-ship headliners. Frames makes transaction validation, gas payment and execution programmable at protocol level. That is useful for account abstraction on its own, but its long-term security value is the ability to move accounts away from secp256k1 and introduce new signature systems without redesigning Ethereum's account model each time.
Related proposals extend that migration path. EIP-8298 lets delegated accounts become full smart-contract accounts, while EIP-8151 can disable legacy ecRecover-based authentication once account code is present.
Users get an escape route before the final quantum cryptography has even been chosen.
Validators require the slower route
Consensus signatures cannot simply become a wallet preference. Their aggregation, verification cost and security properties affect every validator.
The Protocol cluster therefore intends to harden the new consensus cryptography before deployment rather than introduce its components piecemeal. EIP-8365 can begin retiring withdrawal credentials tied to vulnerable cryptography now, but full post-quantum consensus still requires new attestations.
Those attestations are one of the remaining pieces needed for full economic finality under the new design.
There is a fallback plan for arriving late
Ethereum's roadmap now includes a minimum viable post-quantum milestone, or MV-PQ. It is not meant to provide every guarantee of the final architecture. It is a contingency system intended to keep the network operating through Q-day if the complete migration has not finished.
A post-quantum public-key registry currently sits in the provisional I* fork. J* is expected to carry several heavier components: a post-quantum consensus heartbeat, leanDA sampling for the data layer and leanSPHINCS transactions for execution.
Researchers are still defining precisely which guarantees would be reduced under MV-PQ. The distinction matters: December 2029 is still the target for full resistance across all three layers, not merely an emergency transaction mode.
The fork cadence is the uncomfortable part
Under the current Strawmap, full post-quantum readiness sits at L*, five hard forks after Glamsterdam. If Glamsterdam ships in December 2026 and L* lands in December 2029, Ethereum needs to average roughly 7.2 months per fork.
That is an aggressive schedule for changes that move through research, EIPs, prototypes, devnets and multiple inclusion stages before reaching mainnet.
A slower twelve-month cadence could still reach the MV-PQ contingency milestone by December 2029. Full resistance would require more parallelism.
The plan is therefore explicitly non-linear: client teams can implement Hegotá while I* specifications mature and later J* through L* components are researched and prototyped at the same time.
Quantum security is already competing with zkEVM work
No useful quantum attack is required for the roadmap to have consequences today. Engineering capacity is finite.
After Glamsterdam, the Protocol cluster places the Hegotá-to-J* path toward minimum viable post-quantum security directly below keeping mainnet safe. Fast finality, privacy, state work and zkEVM development continue, but they now compete against a dated cryptographic migration.
Even the order of later forks remains negotiable. One option under review would move post-quantum attestations forward while pushing mandatory zkEVM execution proofs back by one fork. The purpose is simple: finish the largest remaining consensus-level quantum component sooner.
The December 2029 deadline will be reassessed with external experts in January 2027. Until then, the Ethereum Foundation Protocol cluster says it is treating that date as non-negotiable.