Is Ethereum Safe From Quantum Computers? A Deep Dive into Ethereum’s Post-Quantum Roadmap and Migration Strategies

01Executive Summary & Quick Reference Glance

No cryptographically relevant quantum computer exists today, so nothing about Ethereum is under active attack. But Ethereum’s exposure has a different shape than Bitcoin’s, and that shape matters more than the timeline. Every externally owned account (EOA) publishes its secp256k1 public key to the world the first time it sends a transaction, and that publication is permanent. Bitcoin holders can retreat to fresh, never-spent addresses where the public key stays hidden behind a hash. Ethereum holders can’t, because the account model binds your balance, your DeFi positions, your ENS name, and your staking credentials to a single address you can’t quietly abandon.

The migration lever is account abstraction. ERC-4337 lets a smart account define its own signature validation, which means a wallet can swap ECDSA for a hash-based scheme without waiting for a network-wide hard fork. That's the structural difference from Bitcoin, and it's the reason Ethereum's path is more about wallet engineering than about protocol politics.

Attribute	Detail
Cryptographically relevant quantum computer today	None demonstrated. This is preparation, not an emergency.
Vulnerable primitive (execution layer)	ECDSA over secp256k1. Shor’s algorithm recovers the private key from a public key in polynomial time.
Vulnerable primitive (consensus layer)	BLS12-381 signatures from validators. Pairing-based, so also Shor-vulnerable.
Vulnerable primitive (data layer)	KZG commitments used for blobs. Pairing-based.
Who is exposed	Any EOA that has ever sent a transaction, plus every validator. That’s most active accounts.
Bitcoin contrast	Roughly 30.2% of supply sits in outputs with exposed keys, and the rest can move to fresh addresses. Ethereum has no equivalent carve-out.
Migration lever	ERC-4337 account abstraction, with EIP-7702 delegation as a bridge for existing EOAs.
Stated target	Lean Ethereum roadmap, with ethereum.org citing 2029 for full post-quantum protection.
Complexity for a holder	Low today. Nothing to execute, several things to watch.
Complexity for protocol and wallet teams	High. Signature sizes, gas costs, stateful key management, and address preservation all bite.
Biggest single risk	Address-preserving migration. The cryptography is the easy part.

02Foundational Architecture & Mechanism Deep Dive

The root cause is the same as Bitcoin’s, but the trigger is different

Shor’s algorithm solves the discrete logarithm problem on elliptic curves efficiently, given enough fault-tolerant qubits. Ethereum signs with ECDSA on secp256k1, so a private key is recoverable from its public key. If you want the mechanism without the linear algebra, Shor’s Algorithm Explained Without the Math walks through it.

The trigger is where the two chains diverge. In Bitcoin, a legacy P2PKH output stores HASH160(pubkey), so the public key stays hidden until you spend. In Ethereum, the address is the last 20 bytes of keccak256(pubkey), and a transaction signature is recoverable: it carries enough information for any node to reconstruct the signer’s public key and check it against the address. That recoverability is a design convenience, and it means the first outgoing transaction from an EOA writes the public key into calldata forever.

Receiving ETH doesn’t expose you. Sending does. And once you’ve sent, you can’t un-send.

Why Ethereum has no fresh-address workaround

This is the part that gets glossed over in most comparisons. A Bitcoin holder worried about key exposure can generate a new address, sweep funds there, and never spend from it. The public key stays hidden. It’s an imperfect workaround, since you eventually have to spend, but it buys time and it’s free.

Ethereum’s account model removes that option in practice:

• State is bound to the address. Your token balances, LP positions, lending collateral, and NFT holdings live in mappings keyed by your address. Moving them is a sequence of transactions, each of which reveals a key.
• Identity is bound to the address. ENS names, POAPs, onchain reputation, and allowlist memberships point at a specific address. Rotating means re-establishing all of it.
• Staking credentials are bound to the address. A validator’s withdrawal credentials commit to a 20-byte execution address. The deposit contract is immutable, and the credential types it accepts are a closed set.
• The old address stays exposed regardless. Even after you migrate, the abandoned account still has a published public key. If any asset ever lands there, it’s claimable.

So the honest framing is this: Bitcoin’s quantum exposure is a subset of the supply that you can measure and partially route around. Ethereum’s exposure is the default state of any account that has done anything. That’s a worse starting position, and it’s why the migration conversation on Ethereum is about account architecture rather than about address hygiene.

The four layers that need replacing

Vitalik Buterin’s February 2026 roadmap post, covered by CoinDesk and summarized on ethereum.org’s quantum resistance page, breaks the work into four areas. Each has a different owner and a different difficulty.

Consensus layer. Validators sign attestations and blocks with BLS12-381. Forging those signatures would let an attacker finalize conflicting chains, which is arguably worse than theft. The research direction under the Lean Ethereum banner leans toward hash-based validator signatures, and leanroadmap.org tracks that work. Nothing is shipped.

Data layer. EIP-4844 blobs are committed to with KZG, which relies on pairings over BLS12-381. Pairings fall to Shor’s algorithm. Replacing KZG means either a hash-based commitment scheme or a STARK-friendly alternative, and both change the proving economics that rollups depend on.

Execution layer. This is the ECDSA problem, and it’s the one users feel. It’s also the one account abstraction can address without a fork.

Application layer. zk-SNARKs built on pairing-friendly curves (Groth16 being the classic example) are quantum-vulnerable. STARKs are hash-based and aren’t. That asymmetry is why Starknet’s positioning is credible and why “our rollup uses zero-knowledge proofs” is not by itself a quantum claim.

Justin Drake’s bunker mode warning

In a post on X, Ethereum Foundation researcher Justin Drake argued that AI-accelerated mathematics could weaken ECDSA before a full quantum computer arrives, and that safely exiting what he called “bunker mode” will require post-quantum cryptography. His stated inclination was to go all-in on hash-based cryptography and avoid structured lattices. QNews covered the warning in Ethereum Researcher Warns AI Could Break Crypto Signatures.

The claim deserves precision. Drake isn’t predicting that a language model will factor a 256-bit curve order next quarter. He’s flagging that cryptanalysis is a search problem, that AI is very good at search, and that the security margin on ECDSA is a number nobody has bounded from below. Treat it as a reason to shorten timelines, not as evidence of a break. The distinction between “AI might help find a weakness” and “a weakness exists” is the whole ballgame, and it’s worth stating once and moving on.

03The Migration Lever: Account Abstraction

How ERC-4337 decouples signatures from the protocol

An ERC-4337 smart account is a contract. The EntryPoint contract calls validateUserOp on it, and whatever that function returns determines whether the operation is authorized. The account decides what counts as a valid signature. That’s the entire trick.

// Sketch: a pluggable-validator account. Not production code.
function validateUserOp(
    PackedUserOperation calldata userOp,
    bytes32 userOpHash,
    uint256 missingAccountFunds
) external returns (uint256 validationData) {
    require(msg.sender == ENTRY_POINT, "not entrypoint");

    bytes calldata sig = userOp.signature;
    uint8 scheme = uint8(sig[0]);
    bytes calldata body = sig[1:];

    if (scheme == 0x01) {
        // Legacy ECDSA path, kept for compatibility during migration
        if (!_verifyECDSA(userOpHash, body)) return 1;
    } else if (scheme == 0x02) {
        // Hash-based verifier, deployed as a separate contract
        if (!IPQVerifier(PQ_VERIFIER).verify(pqPubKeyHash, userOpHash, body)) return 1;
    } else {
        return 1; // SIG_VALIDATION_FAILED
    }

    if (missingAccountFunds > 0) {
        payable(msg.sender).call{value: missingAccountFunds}("");
    }
    return 0;
}

The practical consequence: a wallet team can ship a hash-based validator, let users opt in, and never touch a hard fork. Compare that to Bitcoin, where adding a new output type with a new signature scheme means a BIP, a soft fork or hard fork, miner signaling, and years of coordination. Ethereum’s version of that coordination problem exists too, but it applies to the consensus and data layers, not to your wallet.

EIP-7702 is a bridge, not a fix

EIP-7702, live since Pectra, lets an EOA set code that delegates execution to a contract. That gives an existing address programmable behavior, including custom validation logic, without changing the address.

Here's the limitation people miss. The authorization tuple that installs a 7702 delegation is signed with the EOA's own ECDSA key. If that key is already recoverable by an attacker, the attacker can sign a competing delegation. So 7702 helps you prepare before an attack. It doesn't rescue you during one. It's a migration on-ramp, and treating it as a defense is a category error.

Starknet as the demonstrated case

Starknet is the clearest evidence that address-preserving signature migration is buildable rather than theoretical. Accounts on Starknet are contracts, and the protocol exposes a replace_class syscall that lets an account upgrade its own class. The Starknet community forum has a thread specifically on moving existing accounts to post-quantum signatures without changing the address, describing a _migrate entry point that verifies the owner can sign with the new keys before swapping the class.

Working Falcon-512 account implementations from OpenZeppelin and S2morrow have been demonstrated on Starknet mainnet. And Starknet’s proof system is STARK-based, which is hash-based and therefore not Shor-vulnerable. StarkWare is explicit that this is a two-layer story and that Starknet’s full-stack quantum safety still depends on Ethereum completing its own transition, since Starknet settles to Ethereum. That caveat is the honest one, and it’s the right way to read any L2 quantum claim.

04Step-by-Step Operational Protocol

Track A: What an ETH holder can actually do

1. Inventory your exposed accounts. Any address with a nonce above zero has a published public key. Check with Foundry:

cast nonce 0xYourAddress --rpc-url $ETH_RPC_URL
        # nonce > 0 means you have sent at least one transaction
        # and your secp256k1 public key is permanently onchain
    

Expected output is a decimal integer. Zero means the key is still hidden behind the address hash. Anything else means it’s exposed.

1. Check whether an address is a contract or an EOA. Smart accounts have a migration path that EOAs don’t.

cast code 0xYourAddress --rpc-url $ETH_RPC_URL
        # "0x" means EOA. Any bytecode means a contract account.
    

1. Prefer smart accounts for new holdings. A Safe or an ERC-4337 account with a modular validator can rotate its signature scheme later. A raw EOA cannot. This is the single highest-leverage decision available to a holder today, and it costs you nothing in security if you configure the owners correctly.

2. Don’t buy anything marketed as quantum-proof. No token, no hardware wallet, and no wallet app makes an EOA’s exposed key safe. The QNews guide How to Protect Your Crypto from Quantum Computers covers the vendor landscape and the specific claims to distrust.

3. Watch for validator support, not announcements. The signal that matters is a shipped, audited validator contract with a published verifier address, not a roadmap blog post.

Track B: What a wallet or protocol developer should build

1. Separate validation from custody. If your account hardcodes ecrecover, you’ve built an EOA with extra steps. Route validation through a registry so the scheme is a parameter.

2. Pick a scheme and measure it. Deploy a verifier for one hash-based scheme and benchmark it on a fork. Don’t estimate.

# Fork mainnet locally and measure verification cost
        anvil --fork-url $ETH_RPC_URL --block-time 12
        cast estimate 0xVerifierAddress "verify(bytes32,bytes32,bytes)" \
          0xpubkeyhash 0xuserophash 0xsignature --rpc-url http://localhost:8545
    

1. Budget for calldata, then double it. At 16 gas per non-zero byte, a 7,856-byte SLH-DSA signature costs 125,696 gas before any verification. EIP-7623’s calldata floor makes the real number higher. Verification in the EVM is the binding constraint, not the bytes.

2. Handle statefulness explicitly. WOTS+ and XMSS are one-time or few-time schemes. Reusing a leaf leaks the key. If your wallet restores from backup and replays a leaf index, you’ve broken your own security. Persist the index in a way that survives restore, and refuse to sign if the index is ambiguous.

3. Test the address-preservation path. Deploy a fresh account with a PQ validator, then try to migrate an existing account to it. The second part is where projects stall.

05Comparative Analysis & Trade-Off Matrix

Signature schemes an Ethereum account could adopt

Scheme	Family	Signature size	Public key	Stateful?	Standard	Calldata gas at 16/byte
ECDSA secp256k1	Elliptic curve	65 B	33 B	No	De facto	1,040
BLS12-381	Pairing	96 B	48 B	No	IETF drafts	1,536
Falcon-512	Lattice (NTRU)	666 B	897 B	No	Draft FN-DSA	10,656
ML-DSA-44	Lattice (module)	2,420 B	1,312 B	No	FIPS 204	38,720
WOTS+ (n=32, w=16)	Hash	2,144 B	32 B	Yes, one-time	Building block	34,304
XMSS (RFC 8391)	Hash	~2,500 B	64 B	Yes, few-time	RFC 8391	~40,000
SLH-DSA-SHA2-128s	Hash (stateless)	7,856 B	32 B	No	FIPS 205	125,696

The trade-off is stark. Falcon-512 is the cheapest post-quantum option by calldata, but it’s still in draft standardization and its floating-point reference implementation is notoriously hard to make constant-time. ML-DSA is standardized and well-analyzed, at roughly 2.4 KB per signature. SLH-DSA is the most conservative choice, resting only on hash function security, and it’s also the most expensive. WOTS+ and XMSS are the cheapest to verify in some constructions but impose state management that most wallets aren’t built for. WOTS+ and XMSS covers the internals.

Drake’s stated preference for hash-based cryptography over structured lattices is a real position with real costs, and it’s worth understanding rather than dismissing. Hash-based schemes have a smaller assumption surface. They also have larger signatures and, in the stateful variants, an operational burden that has caused real-world failures in other systems.

Bitcoin versus Ethereum migration paths

Read that table carefully, because it cuts both ways. Ethereum’s consensus layer is _more_ exposed than Bitcoin’s, since proof of work is hash-based and proof of stake is not. But Ethereum’s account layer is _more_ migratable, because account abstraction makes the signature scheme a per-account choice. Bitcoin is safer to wait with and harder to change. Ethereum is riskier to wait with and easier to change. That’s the trade.

The emergency recovery proposal

Buterin’s ethresear.ch post, “How to hard-fork to save most users’ funds in a quantum emergency,” lays out a rescue path rather than a permanent fix. The mechanism has a few moving parts:

• Revert the chain to the block before the first observed quantum theft, undoing the attacker’s gains.
• Invalidate legacy ECDSA-authorized transactions so the attacker can’t simply replay.
• Introduce a new transaction type where the sender proves knowledge of the private key using a STARK, which is hash-based and therefore not forgeable by the same attacker.

The STARK proof is the clever bit. It lets you demonstrate control of a key without revealing it, which is exactly what you need when the key is already compromised but the attacker hasn’t acted yet. The proposal is candid about its limits: it requires fast social coordination, it only works if the revert happens before funds move, and it’s a one-shot rescue rather than a durable architecture. It’s a fire exit, not a building code.

06Real-World Gotchas, Failure Modes & Edge Cases

**Address preservation is the hard problem, not the math.** Deploying a Falcon verifier is a weekend. Migrating an existing EOA with a decade of state attached to it, without changing the address, is the thing that will consume the timeline. Starknet solved it because accounts were contracts from day one. Ethereum didn’t have that luxury.

**Stateful signatures break on backup restore.** WOTS+ and XMSS lose all security if a one-time key is reused. A user who restores a seed phrase onto a second device and signs from both has just leaked their key. Any wallet shipping a stateful scheme needs a leaf-index persistence design that survives restore, and most wallets today have no such concept.

**Gas costs compound in ways estimates miss.** A 7,856-byte signature is 125,696 gas in calldata alone. Verification of SLH-DSA in the EVM, absent a precompile, runs into the hundreds of thousands of gas. At mainnet gas prices that’s a meaningful per-transaction cost, and it hits high-frequency users hardest. Precompiles would fix it, and precompiles require a fork.

**EIP-7702 doesn’t protect a compromised key.** The delegation is authorized by the ECDSA key. If the key is recoverable, so is the delegation. Use 7702 to prepare, never to respond.

**The deposit contract is immutable.** Validator withdrawal credentials commit to a 20-byte address and the accepted credential types are a closed set. Expressing a post-quantum withdrawal key requires a protocol change, and that’s a fork, not a wallet update.

**L2 quantum claims inherit L1 risk.** Starknet says this plainly. A rollup that verifies post-quantum signatures on the account layer still settles to Ethereum, and Ethereum’s settlement layer is ECDSA and BLS today. Any L2 marketing that omits this is incomplete.

**Smart contract wallets with a single ECDSA owner are not safer.** A Safe with one ECDSA signer has the same exposure as an EOA, plus contract risk. The benefit only materializes when the validator is actually swappable and the owner set is configured for it.

**Revert-based rescue has a race condition.** The attacker sees the same chain you do. A revert fork only helps if it lands before the stolen funds move, and coordination at that speed is not something anyone has demonstrated.

07Interactive Checklist & Readiness Verification

• I’ve listed every address I control and checked which have a nonce above zero.
• I know which of my holdings sit in raw EOAs versus smart accounts.
• I’ve moved new long-term holdings into an account with a swappable validator, or I’ve documented why not.
• I’ve verified my wallet vendor has published a validator architecture, not just a roadmap post.
• I’ve confirmed my staking withdrawal credentials and understand they can’t express a PQ key today.
• I’ve checked whether my L2’s quantum claim covers settlement or only accounts.
• I’ve read the vendor claims I’m relying on and confirmed each one names a specific scheme.
• I’ve avoided any product marketed as making an existing EOA quantum-proof.
• I’ve noted the Lean Ethereum target date and set a reminder to re-check progress annually.
• I’ve confirmed I’m not reusing a stateful signature leaf across devices, if I’ve adopted one.

08Comprehensive Technical FAQ

Is Ethereum safe from quantum computers right now?

Yes, in the sense that no cryptographically relevant quantum computer has been demonstrated. The cryptography Ethereum uses today is believed secure against all known classical and quantum attacks at currently achievable scales. That’s a statement about present capability, not a permanent guarantee.

Why is Ethereum more exposed than Bitcoin at the account level?

Because Ethereum transaction signatures are recoverable, so the first outgoing transaction publishes your public key permanently. Bitcoin’s P2PKH and P2WPKH outputs hide the public key behind a hash until you spend, and a holder can move funds to a fresh unspent address. Ethereum’s account model ties balances, positions, and identity to a single address, so that retreat isn’t practical.

Does account abstraction actually solve the problem?

It solves the coordination problem, not the cryptography problem. ERC-4337 lets an account define its own signature validation, so a wallet can adopt a hash-based scheme without a network-wide fork. You still need a secure, audited verifier, and you still need to migrate existing accounts, which is where the difficulty lives.

What is Justin Drake’s bunker mode warning actually saying?

He’s arguing that AI-accelerated cryptanalysis could weaken ECDSA before a full quantum computer exists, and that exiting that posture safely requires post-quantum cryptography, with a stated preference for hash-based schemes over structured lattices. It’s a call to shorten timelines, not a claim that a break has occurred.

What would Vitalik Buterin’s hard-fork recovery actually do?

It would revert the chain to before the first observed quantum theft, invalidate legacy ECDSA-authorized transactions, and add a transaction type where users prove knowledge of their private key with a STARK. Because STARKs are hash-based, the same attacker can’t forge the proof. It’s an emergency rescue that depends on fast coordination, not a permanent architecture.

Why does Starknet keep coming up in this conversation?

Because it demonstrates the thing everyone else is theorizing about. Starknet accounts are contracts, so an account can upgrade its own class and change signature scheme while keeping its address. Falcon-512 account implementations from OpenZeppelin and S2morrow have run on mainnet, and the proof system is STARK-based. Starknet is also explicit that its full-stack safety depends on Ethereum finishing its own transition.

Should I move my ETH to a new address?

Not as a quantum defense. A new EOA gets exposed the moment you spend from it, and moving assets means sending transactions. If you’re moving for general hygiene or to consolidate into a smart account with a swappable validator, that’s a different and reasonable decision.

What’s the realistic timeline?

ethereum.org cites 2029 as the target for full post-quantum protection under the Lean Ethereum roadmap, and the Ethereum Foundation maintains a dedicated post-quantum research team. Treat that as a target rather than a commitment. The honest answer is that nobody knows when a cryptographically relevant quantum computer arrives, which is exactly why the work is happening now.

09Author Perspective & Practical Verdict

Here’s the framing I’d push back on hardest: the question “is Ethereum safe from quantum computers” invites a yes or no, and the useful answer is a comparison. Ethereum is structurally worse positioned than Bitcoin on exposure and structurally better positioned on migration. Most coverage gets one half of that and stops.

The exposure half is genuinely uncomfortable. Bitcoin’s roughly 30.2% figure is a number you can point at, and the remaining supply has a retreat option. Ethereum doesn’t have a comparable carve-out. If you’ve used an address, its key is public, and the account model means you can’t walk away from it cleanly. Anyone telling you that a hardware wallet upgrade fixes this is selling something. The migration half is where I’m more optimistic than the consensus. ERC-4337 is the most underrated piece of infrastructure in this entire discussion. It converts a protocol-level coordination problem into a per-wallet engineering problem, and engineering problems get solved on schedules. Bitcoin’s equivalent requires a BIP, a fork, and years of signaling. Ethereum’s requires a good verifier contract and a wallet team that ships. Starknet has already shown the address-preserving version works.

What I’d avoid: buying anything marketed as quantum-proof, treating EIP-7702 as a defense rather than a bridge, and assuming an L2’s quantum claim covers settlement when it usually covers accounts. What I’d watch: shipped validator contracts with published verifier addresses, progress on a PQ verifier precompile, and whether the 2029 target survives contact with the consensus and data layer work. What I’d do today: nothing urgent, and that’s the point. The preparation window is open, and the highest-leverage move available to a holder is putting new long-term holdings into an account whose signature scheme can change.

The verdict, stated plainly: Ethereum’s cryptography is believed secure today, its exposure is broader than Bitcoin’s, and its migration path is more tractable. That combination argues for steady progress rather than panic, and for paying attention to wallet architecture rather than to Q-Day countdowns.