Ethereum’s protocol team is working toward a December 2029 deadline for making the network’s execution, consensus and data layers resistant to quantum attacks, using a planning assumption that “Q-day” — the point at which quantum computers can break widely used cryptography — could arrive by 2030.
The schedule would place full post-quantum capability in an upgrade known as L*, the fifth hard fork after Glamsterdam, which is targeted for mainnet deployment in December 2026. The Ethereum Foundation’s protocol team plans to reassess quantum-computing progress in January 2027, but has treated the 2029 endpoint as the working engineering deadline rather than a distant research goal.
That timetable leaves Ethereum attempting several large protocol changes in parallel. Between Glamsterdam and L*, the network would need to ship Hegotá, I*, J*, K* and L* at an average interval of roughly 7.2 months. The team has not set fixed mainnet dates for the upgrades after Glamsterdam, and the order of some later quantum-related work remains under review.
A compressed route to quantum-resistant Ethereum
Hegotá would serve as the first delivery checkpoint in the program, although it is not designed as a post-quantum hard fork itself. Client teams expect initial implementation work to begin in late 2026, while research, technical specifications, prototypes and security testing for subsequent upgrades would proceed at the same time.
The roadmap divides the quantum transition into stages rather than trying to replace every vulnerable cryptographic component in one release. I* is expected to introduce a post-quantum public-key registry, giving accounts a way to register and use quantum-resistant keys. It is also the point at which “decoupled consensus” is being considered as a leading direction, alongside early work on major changes to Ethereum’s state structure and migration process.
J* is planned to introduce a minimum viable post-quantum Layer 1, or MV-PQ. The package would combine a post-quantum “heartbeat” mechanism for consensus, post-quantum leanDA sampling for Ethereum’s data-availability layer, and post-quantum leanSPHINCS transactions for execution.
K* is currently assigned enforced execution proofs. Under that design, validators would move toward checking succinct cryptographic proofs of block execution instead of fully re-executing every block themselves. The approach could alter the computational role of validators while preparing Ethereum for a more proof-driven execution environment.
L* would add post-quantum attestation messages, completing the planned protection of Ethereum’s consensus layer. The ordering is not settled: protocol researchers are considering moving quantum-safe attestations into K* and pushing enforced execution proofs into L*. Either sequence would retain L* as the target point for full coverage across execution, consensus and data systems.
Hegotá narrows its initial scope to two mandatory proposals
The protocol team has sorted 62 candidate proposals for Hegotá into priority groups. Two are in the mandatory S tier, 15 are categorized as high-priority A-tier work, eight sit in the conditional B tier, seven fall below the inclusion line in C, 28 are marked “do not fork include,” and two remain undecided.
The two mandatory Hegotá items are EIP-7805, Fork-choice enforced Inclusion Lists, or FOCIL, and EIP-8141, Frame Transactions.
FOCIL would add validator-enforced transaction inclusion rules to Ethereum’s existing block-building process. In each slot, a committee would publish lists of transactions visible to its members. The following slot’s block builder would aggregate the lists and include qualifying transactions, while attesting validators would check whether the proposed block complied with the lists they received in time.
A block that omits eligible listed transactions without a permitted reason could remain valid under Ethereum’s execution rules but fail to receive enough attestation support to become part of the canonical chain. The design gives validators a more direct role in resisting transaction censorship without replacing the current block-production flow.
EIP-8369 sets out which transactions can qualify for FOCIL-style inclusion. It distinguishes conventional transactions from Frames transactions, whose programmable verification can require limits on the state they read and the computation they consume.
Frames, proposed under EIP-8141, would make transaction validation, execution and gas payment more programmable at the protocol level. The proposal provides a base for native account abstraction, allowing accounts to use custom validation logic rather than relying solely on the signature model associated with externally owned accounts.
That flexibility also forms part of Ethereum’s migration strategy. Programmable validation could allow accounts to adopt new signature schemes as cryptographic conditions change, reducing the need for a separate hard fork every time Ethereum needs to support a different authentication method.
Account migration and censorship resistance converge
Frames depends on two A-tier proposals: EIP-8250, Keyed Nonces, and EIP-8272. Keyed Nonces would let a sender operate multiple independent nonce channels, reducing the risk that one delayed transaction blocks unrelated activity from the same account. EIP-8272 would allow transactions to reference recent on-chain state that validators can verify.
The protocol team links that state-reference capability to efforts to extend inclusion guarantees to some privacy-oriented transaction designs. In practical terms, Ethereum is trying to pair stronger anti-censorship rules with account features that can accommodate more complex transaction verification.
Several other A-tier proposals address the migration away from cryptographic assumptions that may become unsafe under sufficiently capable quantum computing. EIP-8365 would start a phased exit from certain BLS withdrawal credentials. The work could begin before Ethereum finalizes its complete post-quantum consensus architecture.
EIP-7906, EIP-8298 and EIP-8151 form an additional account-security set around Frames. EIP-7906 would introduce Transaction Assertions, letting a transaction require specified conditions before it is finalized. EIP-8298 would allow accounts to reuse existing contract code, giving delegated accounts a route to become smart-contract accounts with their own full code. EIP-8151 would prevent addresses that already contain account code from continuing to use traditional ecRecover-based authentication.
Proof systems and resource pricing remain part of the trade-off
The roadmap also places EIP-8025, optional execution proofs, in the Hegotá discussion. The proposal is connected to future zkEVM work and aims to place necessary changes in a shared execution specification, avoiding long-term maintenance of separate protocol forks for different zero-knowledge virtual machine projects.
EIP-8279 and EIP-8131 would establish minimum prices for block access-list bytes and a unified transaction content layer. Their purpose is to limit worst-case block-processing costs created by underpriced transaction content. EIP-3298, which removes Ethereum’s gas refund mechanism, and EIP-5920, the PAY opcode for transferring ETH without running recipient code, are also in the A tier.
Some prominent ideas have lower priority. EIP-8198, Quick Slots, which seeks shorter slot times, remains conditional on full specifications, prototypes, downstream-impact analysis and evidence that it will not interfere with consensus decoupling. Decisions on EIP-8368 and EIP-8372, covering gas limits and state-resource pricing, are expected to depend on mainnet data collected after Glamsterdam.
Ethereum’s proposed sequence places near-term deliverables such as FOCIL and Frames alongside a four-year security migration that reaches into the network’s validator duties, transaction model and cryptographic foundations. The January 2027 reassessment will test whether the assumed pace of quantum progress — and Ethereum’s own ability to deliver upgrades roughly twice a year — still supports a December 2029 finish.
Explore how Ethereum’s roadmap shapes trading and network security—start analyzing live crypto markets with Toobit Markets today.
Disclaimer: The content on this page is provided for general informational purposes only and does not represent the views or financial advice of Toobit. We make no guarantees regarding the accuracy or completeness of this information and shall not be held liable for any errors, omissions, or outcomes resulting from its use. Investing in digital assets involves risk; users should independently evaluate their financial situation and the risks involved. For further details, please consult our Terms of Service and Risk Disclosure.
