Ethereum's Quantum Migration: The Hard Part Is Retiring Old Authority

A wallet can verify a sound post-quantum signature while an old key still has permission to empty it. A validator can register a new signature scheme while its replacement-key procedure still trusts the old one. A rollup can prove execution with hashes while its final verifier accepts a pairing-based proof.

These are migration failures hiding inside successful cryptographic upgrades.

Ethereum's post-quantum finish line is an authorization condition: every path that can change protected state must remain secure under the chosen threat model. Installing a new verifier establishes one path. Retiring or safely restricting the old paths completes the account transition. The same reasoning extends to validator identity, data commitments, and proof acceptance.

Research snapshot: November 5, 2026 (UTC). The EF Protocol cluster's September statement targets quantum resistance across execution, consensus, and data by December 2029. Its minimum viable post-quantum contingency explicitly offers reduced guarantees; full economic finality still requires additional work. These are research and delivery objectives. They do not predict the arrival of a cryptographically relevant quantum computer or establish that the transition has shipped.

Model the capability before choosing the deadline

Shor's algorithm makes discrete logarithms tractable on a sufficiently capable quantum computer. That threatens several distinct Ethereum trust boundaries. Treating all of them as a wallet-signature problem loses the dependencies that make a migration difficult.

Hash-based constructions have a different analysis. They require appropriate parameters and a security argument against quantum queries; a hash appearing somewhere in a protocol does not transfer its security to every other component.

The operational timeline is also uneven. An attacker able to target one exposed administrative key presents a different workload from an attacker forging a large fraction of consensus votes. A credible migration plan needs a capability model and a lead-time budget. A single confident date for “Q-day” cannot supply either.

An account's weakest authorization branch can undo its upgrade

Consider this illustrative acceptance policy:

accept(operation) = valid_pq_signature(operation)
                 OR valid_legacy_signature(operation)

The post-quantum branch can be perfectly implemented. An attacker who can satisfy the legacy branch still wins. The same problem appears when the second branch is named recovery, emergency owner, upgrade administrator, or session-key manager.

Figure 1. A conceptual authorization graph. Each accepted branch needs review under the same threat model; this is not a diagram of an adopted Ethereum transaction format.

EIP-7702 provides a concrete case. Delegating an EOA to code can make contract-defined verification available, but the original secp256k1 key retains protocol-level powers. It can authorize another delegation or clear the delegation; delegated accounts can also originate transactions under the retained rules. A post-quantum check inside the delegate does not revoke those powers.

This gives a useful review test: let the adversary control the old EOA key, then ask whether the intended post-quantum policy still constrains every state-changing action. A successful demonstration of the new signing flow is insufficient evidence for that test.

There is an equally important counterexample to blanket pessimism. In ERC-4337, the account validates the user operation independently. If a bundler submits it using an ECDSA transaction, compromising that submitting key does not automatically produce the user's post-quantum authorization. The bundler's funds and availability may be exposed, and the underlying chain still needs protection. Those are different failures from bypassing the account's validator. This distinction follows from the separation of roles in the interface.

Draw the authority graph before declaring a dependency fatal. Identify the keys that authorize user state changes, the parties that merely carry requests, and the mechanisms that can replace those roles.

EIP-8141, still Draft at this snapshot, explores native programmable transaction validation. Its rationale explicitly discusses the post-quantum limitation of ECDSA-based authorization lists. That is a promising design direction, while the security conclusion for an existing account still depends on its actual accepted transaction and recovery paths.

Application contracts add another layer. A token's permit interface may continue accepting secp256k1 signatures independently of what the wallet UI now signs. ERC-1271 provides a contract-defined verification interface, but its concrete implementation and administrators still matter. Migration inventories must include orders, permits, governance rights, recovery, and upgrades alongside the account's principal signing module.

A zero transaction count does not establish an unexposed key

Ethereum transaction signatures make public-key recovery possible from the signature and the known signing digest; EIP-155 specifies the chain-aware recovery rules. Other signatures can reveal the same key when the adversary has the corresponding digest and recovery information.

A user can sign a permit that someone else submits. An adversary can retain an offchain signed message. Neither requires the account to have originated a transaction or advanced its transaction nonce. A third party can also carry an account's 7702 authorization, although processing that authorization does increment the authority nonce. These distinct exposure routes make transaction nonce zero a weak proxy for public-key secrecy.

The hidden-key case deserves precision too. An Ethereum address retains 160 bits of a hash of the public key. In an idealized black-box model, applying Grover's search to a targeted address preimage suggests roughly 2^80 oracle calls. That is an asymptotic model, with substantial circuit and engineering costs omitted, not a practical attack-time estimate. It also does not justify describing a 20-byte address as 256-bit post-quantum protection.

The useful classification is what the adversary knows and which permissions remain attached to that identity. A database field saying “never sent” cannot establish those facts on its own.

Consensus migration has a state-management problem

Ethereum's consensus specification exposes validator public keys and uses 96-byte BLS signatures, including aggregate signatures. Compact aggregation is central to the comparison: multiplying a new signature size by the validator count does not describe today's wire format.

The identity transition has a more fundamental ordering constraint. Suppose a future registry accepts a new post-quantum key solely because the old BLS key signed its registration. If that BLS key is already forgeable, a valid registration signature cannot distinguish the original validator from an attacker. This is a consequence of the threat model, not a claim that a particular registry design has been adopted. Pre-registration, activation, and retirement of old authority must be designed together.

Hash-based validator signatures introduce a second constraint. The current leanVM research implementation's leanXMSS specification requires one message per signing leaf. Reusing a leaf for different messages breaks the scheme's security. Re-signing the identical message is deterministic in this implementation, although the stated proof does not cover repeated leaf use.

That requirement crosses the boundary into infrastructure. A restored seed does not establish which leaves have already been consumed. The implementation's seed serialization does not carry a complete persistent leaf-use ledger.

Imagine a primary signer consuming an index, timing out before its caller records success, and a restored standby assigning that index to a different message. Both machines may possess the correct seed and still violate the signing contract. Preventing that requires a deliberate allocation, persistence, and failover design. This is an operational consequence of the research scheme, rather than a report of an exploited mainnet bug.

Put actual units beside the aggregation claim

NIST standardization gives useful primitives, while Ethereum must also solve distributed transport and verification. For scale, ML-DSA-44 has a 2,420-byte signature; SLH-DSA-SHA2-128s has a 7,856-byte signature. Ten thousand unaggregated signatures would occupy 24.2 MB and 78.56 MB respectively, excluding messages, keys, encoding, and all networking overhead. This hypothetical batch is a size calculation, not an Ethereum throughput claim.

A more relevant research snapshot comes from leanVM commit 79289f2. Its authors report the following CPU-only result on an M4 Max MacBook Pro with 48 GB RAM, without Metal acceleration:

At that same revision, the signature format is 2,404 bytes. The transparent arithmetic is:

1,400 * 2,404 bytes = 3,365,600 bytes, approximately 3.21 MiB
359.5 KiB         =   368,128 bytes
raw signatures / reported proof bytes ≈ 9.14

That ratio compares two byte counts. The implementation counts the VM proof alone; the full wire format separately carries signer information and other fields. Our ratio does not model that full object, message delivery, recursion, propagation, or retries. It is neither a measured network compression factor nor an equal-format comparison with a BLS aggregate. We have checked the arithmetic and source revision, not reproduced the authors' benchmark.

Figure 2. Original illustration calculated from the pinned prototype's signature format and author-reported proof size. The reported KiB figure is rounded; the approximate ratio describes these byte counts rather than network compression.

The same README marks the project as unready for production and its parameters as provisional. It reports 128-bit ROM and 64-bit QROM soundness. The leanXMSS technical document separately identifies its proved classical bound and remaining conjectural steps in the quantum argument. These labels cannot be combined into a claim of formally proved 128-bit quantum security.

The next convincing evidence would be end-to-end tail latency across independent implementations and ordinary hardware, including missing signatures, malformed inputs, lost aggregators, and signer recovery. The identity and message checked by the proof must also be the identity and message required by consensus. A fast proof for the wrong statement remains the wrong proof.

A trusted setup cannot repair KZG after its assumption breaks

KZG's setup ceremony addresses an adversary who might retain the setup secret. It does not make the underlying discrete-logarithm assumption survive Shor.

The original KZG construction makes the distinction concrete. In simplified additive notation, let the setup secret be tau, the polynomial commitment be C = f(tau)G1, and an opening claim that f(z) = y. The verification relation has this form:

e(C - yG1, G2) = e(proof, (tau - z)G2)

The public setup contains group elements encoding tau. If a capable quantum adversary recovers that scalar, then for z != tau the adversary can construct:

proof = (tau - z)^(-1) * (C - yG1)

The pairing equation now holds for a chosen y, including an incorrect opening of the fixed commitment. This is a schematic algebraic derivation for a single opening; it leaves out encoding, batching, and protocol-specific checks.

Notice what stayed unchanged: C. Hashing that commitment into EIP-4844's versioned hash does not prevent this attack on the opening relation. The attacker has no need to find a different commitment with the same hash.

PeerDAS combines sampling with cryptographically authenticated pieces. Encoding and sampling address availability, while the proofs bind pieces to their commitments. Preserving the first mechanism does not repair the second after its security assumption fails. This is why the data layer requires its own migration, beyond changing account signatures.

Trace a proof all the way to the verifier that accepts it

A post-quantum signature can be verified inside a circuit and then compressed through another proof. The verifier at the end of that chain determines what an attacker must forge to make Ethereum accept a false statement.

If the final acceptance step relies on a curve-based commitment or pairing system vulnerable under the same quantum model, the inner hash-based signature does not establish post-quantum soundness for the complete path. This is a dependency analysis, not a claim that every SNARK uses the same assumptions. Hash-based succinct arguments exist; the name “SNARK” does not by itself identify the primitive.

The same review must cross application boundaries. A rollup can have a post-quantum execution proof and retain an exposed upgrade administrator, a classical bridge-signature path, or a vulnerable L1 consensus dependency. Each has a different consequence. An upgrade key may replace verification logic; a compromised relayer may merely interrupt delivery if the contract independently validates the message. Follow the permissions rather than counting how many classical keys appear in a diagram.

For a claimed migration, request an acceptance graph: signature scheme, hash function, polynomial commitment, recursion wrapper, final verifier, upgrade authority, and underlying chain assumptions. Then try to construct a valid acceptance through every alternative branch under the stated adversary.

Cutover makes ownership a temporal question

For a planned migration authorized by the old credential, the ordering matters. Bind replacement authority while that credential still establishes ownership. Activate the new policy under explicit replay and domain rules. Finally, disable or constrain every obsolete path that can still control the same state. The precise mechanisms differ between accounts and consensus, but this dependency remains. Emergency recovery using an independent secret has a different ownership argument, considered below.

After the old key is derivable, proving knowledge of that key no longer proves historical ownership. This is the difficult case for inactive accounts and rushed recovery.

Vitalik Buterin's 2024 emergency-fork proposal explores disabling traditional EOA transactions and using a STARK to prove knowledge of a private derivation preimage, while binding replacement validation code. Recovering a private key with Shor does not, by itself, recover the seed or other derivation secret that produced it.

That proposal depends on which witness the owner actually retains and which derivations the recovery mechanism supports. An imported key is not automatically unrecoverable: its original seed and derivation path may still exist. Conversely, possessing only the same naked key that the adversary can derive supplies no distinguishing evidence by itself. The proposal is research, not a currently deployed universal rescue facility.

There are unavoidable decisions outside the proof: identifying the attack boundary, selecting a rollback checkpoint, treating legitimate transfers near it, and coordinating bridges or custodial ledgers that already acted on those transfers. A proof can validate a chosen ownership rule. It cannot choose that rule or undo an external system's completed actions.

The evidence that would make the migration credible

An algorithm announcement answers which primitive a team intends to use. A credible cutover needs evidence at four additional boundaries:

• Authority: adversarial tests show that old owners, recovery keys, delegated roots, and upgrade paths cannot bypass the new policy.
• State: restored signers preserve one-time-key constraints, and independent implementations agree on identity, domain separation, and replay protection.
• Verification: the final accepted proof and commitment share the claimed quantum security model, with explicit parameters and proof scope.
• Coordination: clients can meet deadlines under failures, and the activation rules specify how old identities become new identities without trusting an already broken credential.

These are falsifiable requirements. A permission graph exposes a bypass. A restore drill exposes index reuse. A pinned benchmark exposes the hardware and parameter assumptions. A cutover specification exposes which dormant identities remain unresolved.

Ethereum's research program is tackling a large, interdependent transition. Its strongest result would be a protocol whose remaining authority can be explained after the old mathematics stops protecting it. That is the standard against which a post-quantum roadmap, wallet demonstration, or proof-system benchmark should be judged.