The Plan Sounds Good

Vitalik Buterin and the Ethereum Foundation have laid out a post-quantum roadmap that targets 2029 for a comprehensive migration. The plan has three pillars:

  1. Replace ECDSA with STARKs for wallet signatures, moving user authentication to a hash-based proof system that is quantum-resistant by design.
  2. Move the consensus layer to PQC, replacing the BLS12-381 signatures that validators use to attest to blocks with post-quantum alternatives.
  3. Make the EVM quantum-safe, ensuring that the execution environment itself does not assume classical cryptographic primitives.

On its face, this is exactly the right approach. STARKs are hash-based and quantum-safe. PQC algorithms are NIST-standardized. The timeline aligns with NIST’s 2035 deprecation deadline for classical-only cryptography. It is proper and solid.

The problem is not the plan. The problem is what the plan does not say about the four things that make Ethereum fundamentally harder to migrate than Bitcoin.

Bitcoin Has One Problem. Ethereum Has Four.

Bitcoin’s quantum vulnerability is concentrated in a single point: ECDSA transaction signatures. Fix the signature scheme and you fix Bitcoin. It is a hard problem — we wrote a complete technical guide on it — but it is a single problem with identifiable solutions.

Ethereum has that same ECDSA problem plus three more that Bitcoin does not have at all.

PROBLEM 1

Hundreds of Millions of Exposed Wallets

Every Ethereum address that has ever sent a transaction has its ECDSA public key permanently recorded on-chain. Shor’s algorithm derives the private key from the public key. This means every address that has ever transacted is quantum-vulnerable the moment a cryptographically relevant quantum computer exists.

Getting hundreds of millions of individual wallet holders to migrate to new PQC addresses requires every single one to take action. They must generate a new keypair, transfer their assets, update every service that references their address, and do this before quantum arrives. The users who don’t migrate — because they lost access, forgot, died, or simply didn’t hear about it — lose everything.

Vitalik knows this is a disaster. The proposed solution involves an emergency hard fork that would freeze vulnerable accounts and force-migrate them — essentially seizing control of user funds to protect them. This is technically necessary and legally terrifying. It is the crypto equivalent of Eminent Domain, and no one has worked out the legal framework for it.

PROBLEM 2

The EVM Was Never Designed for Post-Quantum Signatures

The Ethereum Virtual Machine processes transactions that include signatures. Every gas calculation, every contract interaction, every precompile assumes signature sizes and verification costs that are calibrated for ECDSA’s 64-byte signatures.

Post-quantum signatures are dramatically larger:

AlgorithmSignature Sizevs ECDSA (64B)Gas Impact
ECDSA (current)64 bytes1xBaseline
ML-DSA-65 (Dilithium)3,309 bytes52x largerMassive increase
FALCON-512~690 bytes11x largerSignificant increase
SLH-DSA (SPHINCS+)17,088 bytes267x largerImpractical
STARK proof~45,000 bytes703x largerRequires aggregation

Every block has a gas limit. If signatures consume 52 to 700 times more space, the number of transactions per block drops proportionally unless the gas model is completely redesigned. This is not a parameter change. It is a fundamental rethinking of how Ethereum processes transactions.

The STARK approach Vitalik proposes addresses this through proof aggregation — bundling many individual proofs into a single succinct proof that the block producer verifies once. This is elegant in theory. In practice, it introduces a new trusted role (the aggregator), changes the transaction inclusion model, and requires every wallet and toolchain in the ecosystem to adopt a new signature format simultaneously.

PROBLEM 3

900,000 Validators Need Simultaneous Key Rotation

Ethereum’s proof-of-stake consensus relies on BLS12-381 signatures from over 900,000 validators. BLS is not quantum-safe — it falls to Shor’s algorithm just like ECDSA.

Migrating the consensus layer means every validator must generate new PQC keys, register them on-chain, and begin signing attestations with the new scheme. This must happen in a coordinated transition window. Validators who don’t rotate get slashed or excluded. Validators who rotate to incompatible key formats break consensus.

Bitcoin does not have this problem. Bitcoin has no validator set. Miners use SHA-256, which is quantum-resistant. Ethereum chose proof-of-stake with BLS signatures, and that choice created a quantum dependency that Bitcoin’s proof-of-work does not have.

PROBLEM 4 — THE WORST ONE

Millions of Immutable Smart Contracts

This is the problem nobody has a good answer for.

Ethereum has millions of deployed smart contracts. Many of them store, verify, or depend on ECDSA signatures. Multisig wallets verify ECDSA signatures to authorize transactions. Governance contracts verify signatures for proposal voting. DEXs verify signatures for order execution. Bridges verify signatures from other chains. DeFi protocols verify signatures for everything.

Many of these contracts are intentionally immutable — they were deployed without upgrade mechanisms because immutability is the trust guarantee. A Gnosis Safe multisig that stores $500 million verifies ECDSA signatures because that was the only option when it was deployed. It cannot be upgraded. It cannot be patched. When quantum breaks ECDSA, a quantum attacker can forge signatures that the multisig will accept as valid, draining the funds.

Bitcoin does not have smart contracts. Bitcoin’s Script language is intentionally limited and does not store persistent state or verify signatures in application logic. The entire quantum surface area is the transaction signature. On Ethereum, the surface area includes every contract that has ever called ecrecover.

The scale of this problem is staggering. There is no mechanism in the Ethereum protocol to retroactively modify immutable contracts. Proposing one would undermine the fundamental value proposition of smart contract immutability. Not proposing one means billions of dollars in contract-controlled assets are quantum-vulnerable with no path to protection.

Bitcoin vs Ethereum: Quantum Attack Surface Comparison

Attack SurfaceBitcoinEthereum
Transaction signatures (ECDSA)VulnerableVulnerable
Consensus signaturesN/A (SHA-256 PoW)Vulnerable (BLS12-381)
Smart contract signature verificationN/A (no smart contracts)Millions of contracts
Immutable contract stateN/ACannot be patched
User migration requirementIndividual action neededIndividual action needed
Validator/miner migrationNot required (SHA-256 safe)900K+ validators must rotate
Gas/fee model impactMinimal (witness discount)Fundamental redesign needed

The Honest Assessment

Ethereum cannot be made fully quantum-safe without one of two outcomes:

  1. A hard fork that breaks backward compatibility with every existing contract that verifies ECDSA signatures. This protects the network going forward but destroys the security guarantees of billions of dollars in existing contracts. The legal and financial consequences are incalculable.
  2. A two-tier network where new contracts use PQC and old contracts remain vulnerable. This preserves compatibility but creates a permanently bifurcated security model where some assets are quantum-safe and others are not. Users and protocols must individually assess which tier they are on.

Neither outcome is clean. Both involve losses. The question is not whether Ethereum will suffer from the quantum transition — it will. The question is how much and who bears the cost.

Everything else is timeline theater.

What Can Be Done Today

The honest answer is that protocol-level fixes are years away and may never be complete. But individual holders and protocols do not need to wait for the Ethereum Foundation to protect them.

H33 Protection — Available Now

H33-3-Key Transaction Attestation: Every Ethereum transaction can be signed with a triple-nested post-quantum signature — Ed25519 (classical) → Dilithium (FIPS 204, MLWE lattice) → FALCON (NTRU lattice, independent family). The PQ signature is stored as an off-chain attestation. If quantum breaks ECDSA before Ethereum upgrades, the attestation provides cryptographic proof that the transaction was authorized by the legitimate key holder. This works on the current Ethereum network today.

H33 Protection — Available Now

H33-Vault for Private Key Protection: Store Ethereum private keys under BFV fully homomorphic encryption. Even if ECDSA is broken and the private key is theoretically derivable from the public key, the key is encrypted with lattice-based FHE. An attacker needs to break both ECDSA and BFV — two independent mathematical problems, one classical and one quantum-resistant.

H33 Protection — Available Now

STARK-Attested State Migration: When migration does happen, H33’s ZK-STARK engine can prove the validity of a wallet migration without revealing the private key during the transition. The proof confirms: this new PQ address is controlled by the same entity that controlled the old ECDSA address, verified cryptographically, without exposing any key material.

The Bottom Line

Bitcoin has a hard problem. Ethereum has a harder one. Bitcoin needs to change its signature scheme. Ethereum needs to change its signature scheme, its consensus signatures, its virtual machine gas model, and somehow address millions of immutable contracts that verify a signature algorithm that will not survive the decade.

The Ethereum Foundation is aware of this. Their roadmap is honest about the scope. But the roadmap is a plan, not a solution. The contracts are deployed. The signatures are on-chain. The clock is running.

Waiting for the protocol to save you is not a strategy. The tools to protect yourself today exist. They work on the current network. They do not require a hard fork, a validator rotation, or the cooperation of millions of other users. They require one API call.

H33 Post-Quantum Infrastructure

H33 provides post-quantum cryptographic protection for blockchain assets today: H33-3-Key triple signatures, FHE-encrypted key vaults, and STARK-attested migration proofs. Works on Ethereum, Bitcoin, Solana, and any chain using ECDSA or EdDSA. Learn more →