L1 PoS / Smart Contract Platform

EXECUTION LAYER (EOAs)

secp256k1 ECDSA EOA signatures. Public keys are exposed following the first outgoing transaction. A CRQC can derive the private key from the public key. Keys cannot be rotated in the current implementation. This impacts both smart contracts and users. (1)

EXECUTION LAYER (APPS / L2)

ECDSA, alt_bn128, KZG, BLS12-381 used in precompiled contracts by applications on Ethereum and Layer 2 networks. Two distinct surface areas: (1)

1. Signature verification: ECDSA via ecrecover (0x01), same primitive as EOAs.

2. Proof/commitment verification: alt_bn128 (bn254) pairings (0x06-0x08) behind Groth16 and PLONK-KZG verifiers, KZG point-evaluation (0x0a), BLS12-381 pairings (0x0b-0x11) relied on by zk-rollups, privacy protocols and ZK light-client bridges.

CONSENSUS LAYER

BLS over BLS12-381 used for signatures of validator attestations, aggregated via elliptic curve pairings. Validator public keys are recorded in plaintext in the on-chain validator registry. A CRQC running Shor's algorithm recovers a validator's private key from its public key, the recovered key then enables unlimited signature forgery on classical hardware. Aggregation does not change this exposure, as it is an efficiency mechanism only and validator identities are already publicly visible. Recovering keys on BLS12-381 is more memory-intensive than on secp256k1, but the additional cost is modest. Re-keying requires validators to unstake and restake, and no simple mechanism exists today. (1)

DATA LAYER

KZG polynomial commitments over BLS12-381. The trusted-setup secret used in KZG ("toxic waste") can be recovered from the public SRS by a single one-time CRQC computation, the recovered secret can then be reused indefinitely to forge proofs on classical hardware. Forged proofs can trick validators into thinking unavailable data is available, breaking DAS, which could stall rollups and enable ransom attacks. (1)

Execution layer (EOAs): Any EOA (a user address) that has sent funds and thus exposed its public key means a CRQC can derive the private key. (1)

Execution layer (smart contracts and L2s): Authenticate via ECDLP-based precompiles (ecrecover, alt_bn128 pairings, KZG point evaluation). A CRQC can forge inputs these precompiles accept, so any contract that gates on them is at-rest vulnerable and the exposed parameters sit permanently on-chain. (1)

Consensus layer: Validator keys can be recovered, given all public keys are published in the validator registry. (1)

Very low. Given deterministic 12-second slots, on-spend attacks are nearly impossible for early fast-clock CRQCs. Ethereum's private mempools, including TEE-based BuilderNet, let users submit transactions directly to builders, providing a further mitigation. (1)

Data availability sampling currently uses the KZG polynomial commitment scheme, which involves a trusted setup utilizing a Structured Reference String (SRS). This SRS can be used by a CRQC to recover "toxic waste" based on the publicly available SRS to create a backdoor. This backdoor would only require the use of a CRQC once, and could then be utilized by standard compute to forge data availability proofs indefinitely.

The forged cells could be used to deceive validators that a blob is available despite it not being reconstructible from the cells with the forged proof. This could lead to a rollup stalling or a ransom attack. (1)

The same on-setup attack surface area extends to application layer, any application/protocol whose proof system relies on a trusted setup is exposed to the identical attack.

Not Applicable

Active. Three tracks, rolled out in parallel:

1. Execution Layer: Frame Transactions, Ephemeral keys, PQ leanSPHINCS transactions, leanSPHINCS mempool, zkzk frames.

2. Consensus Layer: PQ leanXMSS attestations, Post quantum heartbeat, PQ pubkey registry, decoupled consensus, fast confirmation, leanVM.

3. Data Layer: Post quantum L1 (hash-based), PQ leanDA sampling, leanVM, remove blob transaction type.

Fork sequence (per strawmap.org, Jul 10 2026):

Glamsterdam (2026): fast confirmation (Consensus).

Hegota (2026-2027): frame transactions (prereq for PQ transactions) (Execution).

I* (2027-28): decoupled consensus (prereq for PQ consensus), post quantum pubkey registry (Consensus), ephemeral keys (prereq for PQ transactions) (Execution).

J* (2028): post quantum heartbeat (prereq for PQ consensus) (Consensus), PQ leanSPHINCS transactions (Execution), PQ leanDA sampling, leanVM (Data).

K* (2028-29): leanSPHINCS mempool (Execution).

L* (2029): PQ leanXMSS attestations, real-time CL proofs (Consensus), zkzk frames (Execution), post quantum L1 (hash-based), remove blob transaction type (Data).

EXECUTION LAYER

PQ transactions path: the execution-layer chain runs frame transactions (Hegota) → ephemeral keys (I*) → PQ leanSPHINCS transactions (J*) → leanSPHINCS mempool (K*) → zkzk frames (L*). No single end-to-end completion milestone appears on the Jul 10 strawmap.

Components:

Frame transactions (Hegota, 2026-2027): a new transaction type whose validity and gas payment can be defined abstractly. Transactions can be authenticated with a PQ system outside ECDSA, and accounts unlinked from ECDSA keys, allowing native key rotation. (6)

Ephemeral keys (I*, 2027-28): a quantum-safe wallet design using account abstraction, keeping the account address constant while rotating the authorized signer after every transaction so public keys are not exposed long term. Two implementations:

- Non-native ephemeral keys (ERC-4337 smart contract wallet, deployable today, no protocol change). (7)

- Native ephemeral keys (proposed for I*) baking rotation into frame transactions via a singleton signer registry and rotation frame, which has open blockers under development. (15)

PQ leanSPHINCS transactions (J*, 2028): leanSPHINCS is the desired final evolution of SPHINCS-, a family of EVM-optimised variants of SPHINCS+. SPHINCS- is intended to minimize on-chain verification cost without relying on a precompile or protocol change. The EVM-native SPHINCS- variants replace SPHINCS+'s SHAKE256 with KECCAK256, which allows the verifier to run natively on chain without a precompile. Additionally, SPHINCS- has a more conservative signature budget than SPHINCS+. leanSPHINCS describes the future end-state variation in which the underlying hash function would be ZK friendly. SPHINCS- is not ZK friendly because KECCAK256 is orders of magnitude more expensive to arithmetize, so it could not be verified natively inside the aggregation circuit. SPHINCS- is intended to potentially serve as a suitable PQ signature option today, while leanSPHINCS is the long-term PQ solution. (19)

leanSPHINCS mempool (K*, 2028-29): mempool nodes and builders fold transactions' declared PQ signature and STARK dependencies off-chain into a single recursive STARK. (19)(20)

zkzk frames (L*, 2029): a new frame type building on EIP-8141 (frame transactions). Enables EVM-level aggregation of PQ signatures and STARK proofs, in which transactions declare (scheme, data_hash, verification_key) dependencies instead of carrying signatures on-chain. Mempool nodes and builders fold these off-chain, and each block carries one recursive STARK in the block header proving all declared signatures and STARKs. (20)

PQ Proofs / Application layer (no single milestone, enabled by the above): the proof-verification precompiles that apps and L2s depend on (alt_bn128 pairings, KZG point-evaluation, BLS12-381) are quantum vulnerable at the curve level and cannot be made PQ-safe in place. Each application must replace its own proof system, moving Groth16/KZG verifiers to hash-based STARKs (FRI), which rely only on hashing the EVM already provides, so no new PQ verification precompile is required. The Ethereum protocol's contribution is limited to the EIP-8141 frame-aggregation rail above (shared with PQ signature aggregation), which absorbs the gas cost of on-chain STARK verification by replacing all frames in a block with one recursive proof. Aggregation itself does not provide security against a QC so applications and L2s migrating to a hash-based system is the actual fix. (13)(8)

CONSENSUS LAYER

PQ Key Registry (I*, 2027-28): validators register PQ public keys before the signature scheme switches. The registry stays flexible since a scheme has not been determined, and gives validators a low-stakes way to manage hardware setups and gradually commit to PQ identities ahead of the upgrade. Keys are registered first, potentially with a hash-function identifier, allowing the network to support multiple hash functions during the transition and mandate migration if one is deprecated.

Hash-function candidates (inside leanXMSS): (9)

SHA-3 / BLAKE3: not optimized for SNARK proving but well battle-tested. (9)

Poseidon1: the older Poseidon, not vulnerable to recent attacks on Poseidon2 (16), but less optimized. (9)

Poseidon2: highly optimized but has taken hits on its security analysis recently. (9)(16)

PQ leanXMSS attestations (L*, 2029): validators sign attestations with leanXMSS and signatures are aggregated through proof-based aggregation via leanVM. leanXMSS is a generalized XMSS scheme, the public key is a Merkle root committing to a tree of Winternitz-style one-time keys, so security rests only on the underlying hash function. The scheme is stateful and synchronized, each one-time key signs exactly once, signatures are bound to an epoch, and a key has a fixed lifetime. Recursion for the aggregation proof is proposed to be either recursive SNARK verification or a folding/accumulation scheme, the final system has not been determined. (12)(21)(22) A draft EIP (EIP-8292) proposes an opt-in aggregator role at L*, in which high-spec nodes generate the succinct proofs verifying attestations, separating aggregation from block production. (24)

Prerequisites:

Fast confirmation (Glamsterdam, 2026): a client-side rule in consensus clients, no hardfork. Gives faster confirmation to those who can tolerate weaker safety guarantees than full finality. Intended for L2 deposits, exchange deposits, and bridge transfers. Uses LMD-GHOST. (17)

Decoupled consensus (I*, 2027-28): decoupling block production and finality. Block production runs on a small randomly sampled committee while finality happens in parallel. Uses Goldfish, a variant of LMD-GHOST. (10)

Post quantum heartbeat (J*, 2028): a fast available chain with a separate finality mechanism trailing behind it. Keeps the protocol safe and live as long as a majority of currently-awake validator stake is honest. Could run on a ~256-validator subsampled set with full-validator-set finality in parallel. Heartbeat signatures can be concatenated with leanVM, so the PQ heartbeat layer could deploy ahead of the full PQ decoupled layer. (11)

leanVM (J*, 2028): a minimal special-purpose zkVM optimized for hash-based cryptography, built first for consensus-layer PQ signature aggregation. It is the SNARK engine that compresses attesters' hash-based signatures into a single proof. Also the leading candidate to be reused at the data layer, and may handle execution-layer signatures. (18)

Real-time CL proofs (L*, 2029): a succinct proof of consensus-layer validity produced for each live slot, so the entire consensus state transition can be verified from a small proof rather than by re-executing it.

Full PQ Consensus (longer term): final state. BLS fully removed, every validator authenticates with hash-based signatures, all attestations aggregated through leanVM recursive proofs, and as the hard deadline approaches the protocol could apply an inactivity leak or forced exits to validators that have not registered PQ keys, so the active set is fully PQ-ready before the switch. (9)

DATA LAYER

The migration replaces KZG polynomial commitments over BLS12-381 with a hash-based commitment scheme, which is post-quantum as it relies only on a hash function and no trusted setup. Blobs stay Reed-Solomon erasure-coded as under PeerDAS today. Removing KZG and its linearity property means 2D DAS is deprioritized in favor of maxing out 1D DAS. Because a single STARK is larger than a blob, proving blob correctness is done with recursive STARKs. The design is not finalized. Work is ongoing and was described as urgent as of the June 2026 Berlin researcher meeting. (1)(13)(23)

leanVM (J*, 2028): the minimal hash-based zkVM built for consensus signature aggregation is also the proving engine for the data layer. It proves that a blob was correctly encoded and committed.

PQ leanDA sampling (J*, 2028): post-quantum data availability sampling. No public specification exists. (14)

Post quantum L1 (hash-based) + remove blob transaction type (L*, 2029): the migration endpoint per strawmap placement: elliptic-curve commitments fully removed, blob transaction type retired. The replacement mechanism is not specified in any public source. The role of aggregation at the data layer is still being explored. (1)(14)(23)

While not finalized, leanSPHINCS is the current candidate for execution-layer signatures (3), with SPHINCS- as the bridge variant deployable today. The leading consensus-layer signature is leanXMSS, with the internal hash function not yet finalized.

CONSENSUS LAYER SIGNATURES

1. leanXMSS (1)

Hash functions for the signature scheme (2): SHA-3 / BLAKE3, Poseidon1, Poseidon2.

Jan 23 2026: Ethereum Foundation announces Post-Quantum team. (1)

Feb 26 2026: Vitalik Buterin publishes the quantum-resistance roadmap thread. (2)

Mar 24 2026: pq.ethereum.org launches, consolidating the EF post-quantum roadmap. (3)

Upcoming / target forks (per strawmap.org, Jul 10 2026):

Glamsterdam (2026): fast confirmation (Consensus).

Hegota (2026-2027): frame transactions (Execution).

I* (2027-28): post quantum pubkey registry, decoupled consensus (Consensus), ephemeral keys (Execution).

J* (2028): post quantum heartbeat (Consensus), PQ leanSPHINCS transactions (Execution), PQ leanDA sampling, leanVM (Data).

K* (2028-29): leanSPHINCS mempool (Execution).

L* (2029): PQ leanXMSS attestations, real-time CL proofs (Consensus), zkzk frames (Execution), post quantum L1 (hash-based), remove blob transaction type (Data). Target for completing core L1 protocol upgrades, per the EF's current assessment.

Longer term: full PQ consensus (BLS fully removed), encrypted mempool (Execution). Full execution-layer and ecosystem migration extends beyond 2029.

No single fixed date has been selected. According to the PQ team, their assessment is that "L1 protocol upgrades could be completed by 2029, with full execution-layer migration taking additional years beyond that." (1)

Ethereum protocol changes go through the EIP process and All Core Devs (ACDE/ACDC) calls, activated at coordinated network upgrades (hard forks). The EF coordinates and researches but does not control protocol direction. The PQ migration is opt-in where possible and split across the per-layer forks below.

Execution Layer — fork-activated infrastructure, opt-in adoption, no flag day

The infrastructure activates at coordinated forks like any other protocol change: frame transactions (EIP-8141) at Hegota (2026-2027). PQ leanSPHINCS transactions activate at J* (2028). SPHINCS- verification runs in plain EVM, so no precompile is required. leanSPHINCS mempool follows at K* (2028-29), and zkzk frames (recursive-STARK aggregation of PQ signatures and STARK proofs) at L* (2029). Adoption on top of this infrastructure is opt-in with no flag day with account abstraction allowing each account to migrate to PQ signatures on its own schedule rather than at a single network-wide switch. Full ecosystem migration extends beyond 2029.

Consensus Layer — registry first, then switch

PQ Key Registry activates first (I*) in which validators register PQ keys without changing signature in prod. The signature switch to leanXMSS with leanVM aggregation happens at a later fork (L*). At Full PQ Consensus, as the hard deadline (TBD) approaches the protocol could apply an inactivity leak or forced exits to validators that have not registered PQ keys, ensuring the active set is fully PQ-ready before the legacy BLS surface is removed. (5)

Data Layer — commitment swap

The data layer's migration endpoint activates at L* (2029) (post quantum L1, hash-based + remove blob transaction type): elliptic-curve commitments fully removed and the blob transaction type retired. KZG is replaced by a hash-based commitment, proven in leanVM, which arrives at J* (2028) and is reused as the data layer's proving system. How the mechanism is split between J* and L* is not specified by any public source. No separate governance beyond the standard fork process.