Ethereum’s Five Quantum Vulnerabilities and Who Owns Each Fix

Ethereum makes a good teaching case because one system uses at least three distinct cryptographic primitives across five functional layers, each layer fails in a different way, and each fix belongs to a different group of people. Most enterprise cryptographic inventories we see have the same shape. Ethereum’s is published, in full, on a ledger anyone can audit.

So we’ll use it as a worked example in reading an inventory. The most transferable lesson comes from the fifth layer, not the first.

Three ways an attacker arrives

Before the layers, three terms. A cryptographically relevant quantum computer (CRQC) is a machine large and stable enough to run Shor’s algorithm against key sizes in production use. None exists publicly today. What separates the five vulnerabilities below is what an attacker could do with an hour on one.

On-spend. The public key appears only when a transaction is broadcast, and the attacker has to derive the private key before that transaction confirms. This needs a fast machine and one run per target, under time pressure.

At-rest. The public key is already published and stays published. The attacker has unlimited time, chooses the order of targets, and still needs one quantum run per key.

On-setup. The protocol’s public parameters were generated once from a secret. Break that secret once and you hold a classical exploit that works indefinitely, costs nothing to reuse, and can be handed to someone with no quantum hardware at all.

Harvest-now-decrypt-later, the term most people know from the PQC migration debate, is the confidentiality version of the at-rest class. Blockchains have no encrypted traffic to harvest. They have signatures, and the signature version is worse in one respect: intercepted ciphertext eventually loses its value, and a public key on an immutable ledger never does.

The five layers

Accounts

Every externally owned account (EOA) authorizes transactions with an ECDSA signature on the secp256k1 curve. The address is a hash of the public key, so before the first outgoing transaction the key is hidden and only the on-spend attack applies. The first signature publishes the key permanently, and the account sits in the at-rest class for the rest of its life.

There’s no rotation path for a legacy EOA. The address derives from the key, so a new key means a new address, and abandoning the old one costs everything attached to it: DeFi positions, governance roles, allowances granted to contracts, and whatever counterparties recognize about that address. Exchange hot wallets and DAO voting keys are the sharpest cases, because the value at risk is the authority the account holds rather than the balance it happens to hold that morning.

The mitigation is account abstraction. ERC-4337, live since 2023, introduced smart accounts that separate the authorizing key from the account identity. EIP-7702, shipped in the Pectra upgrade in May 2025, let EOAs temporarily behave as smart contracts. The deeper fix removes the hardcoded ECDSA dependency from transaction validity at the protocol level, so an account can choose its own verification logic, including ML-DSA, the NIST signature standard formerly called Dilithium. That work is under active discussion rather than shipped.

Administrative keys

Here Ethereum has a class Bitcoin doesn’t. High-value contracts reserve privileged functions for designated accounts: pause, upgrade, mint, freeze, and change parameters. Those keys get used in public and rarely rotate, which puts them in the at-rest class, and the damage is not bounded by the balance the admin account holds.

Four categories account for most of it.

• Token issuance. Stablecoin and tokenized-asset contracts let an owner key mint, burn, freeze accounts, and upgrade the contract logic. Minting unbacked supply breaks the peg, and the peg is the entire value proposition.
• Bridges. Multisig administrators lock assets on one chain and mint wrapped equivalents on another. Compromise drains the pool behind every wrapped token.
• Oracles. Accounts that publish price feeds. False prices trigger automated liquidations across lending protocols that never interact with the attacker directly.
• Guardians. Emergency pause and timelock-bypass accounts. Compromise converts the safety mechanism into the attack.

These effects compound, because contracts call one another and execute as designed. An oracle compromise liquidates positions, liquidations move collateral, and the contracts on the other side do exactly what they were written to do. We would treat admin key inventory as the first task for any team building on Ethereum, ahead of user signatures.

Contract code

Smart contracts get their cryptography from precompiles, which are native implementations of common operations exposed at fixed addresses. Signature recovery, hash functions, pairing operations on the bn254 curve, KZG point evaluation. None of them is post-quantum.

The consequence is easy to miss. A base-layer migration doesn’t reach deployed contracts. If a contract verifies an ECDSA signature in its own logic, that logic stays quantum-vulnerable until someone deploys a replacement and migrates the state. A developer who needs a quantum-safe check today can write one in EVM bytecode, and the cost is punishing. Signature recovery through the precompile costs 3,000 gas, and a hash-based verification written in bytecode costs orders of magnitude more. Adding post-quantum signature verification as a precompile has been proposed, and proof aggregation would cut the per-signature cost further.

Layer 2 makes this sharper. Rollups execute transactions off the base layer and post proofs back to it, and many production systems rely on digital signatures or elliptic curve pairings that are quantum-vulnerable. Systems built on STARKs use hash-based proofs instead, which gives them a real head start. Everyone else needs a migration plan for the verifier contract.

One accident protects them meanwhile. Most rollups still operate at Stage 0 or Stage 1 maturity, with a security council able to pause the bridge or override the proof system when something looks wrong. A forged proof would meet a human before it finalized. That safeguard is itself an admin vulnerability, and it disappears as rollups decentralize, which is where every roadmap points.

Consensus

Validators attest to blocks with BLS signatures on the BLS12-381 curve, and thousands of those signatures aggregate into a single compact object, which is what keeps attestation volume manageable. BLS12-381 uses larger coordinates than secp256k1, so it costs a quantum attacker somewhat more, though not enough to require a different generation of machine. Validator public keys appear in deposit data and the validator registry, so consensus is at-rest vulnerable like everything else.

What an attacker gains depends on how much stake they control. Above one third, they can withhold attestations and stall finality until the inactivity leak restores an honest supermajority. Above one half, they control the fork choice and can reorganize the chain. Above two thirds, they can finalize conflicting chains, and no in-protocol recovery exists. That last case ends in a coordinated social fork, which the protocol survives and institutional trust in it may not.

The number of independent validator keys is a real defense, because each key needs its own quantum computation. Concentration erases it. A staking pool that manages keys for a large share of the network is one infrastructure target instead of many separate ones, and we would watch pool share as a quantum risk metric, not only a decentralization one.

The replacement under research is a hash-based signature scheme, chosen because hash-based security rests only on hash functions, which Grover’s algorithm weakens without breaking. The hard part is aggregation. Hash-based signatures don’t compress the way BLS does, and current throughput assumes compression. The migration also needs an exit path for validators who never rotate.

Data availability

Rollups post their data to the base layer as blobs, introduced with the Dencun upgrade in March 2024. Each blob is committed with a KZG polynomial commitment on BLS12-381, and validators check the commitment rather than downloading everything, which is what makes cheap rollup data possible.

KZG commitments depend on public parameters produced by a trusted setup ceremony. The ceremony generated a secret scalar, and the security argument is that no participant kept a copy. A CRQC doesn’t need a dishonest participant. It can recover the secret from the published parameters by solving the discrete logarithm on the curve, and whoever holds that secret can open a commitment to data that was never committed.

That is the on-setup class, and its arithmetic differs from everything else on this list. One quantum computation, once. After it, the attacker holds a classical exploit against the commitment scheme that works indefinitely and transfers to anyone. Replacing KZG means moving to hash-based commitments, and the candidates cost validators more bandwidth and storage. That trade isn’t optional.

Why the setup class changes the order of work

Now, this is the part that reorders a migration plan: an on-setup weakness has to be replaced before a CRQC exists, not after.

For the other four classes, a fast migration once a machine appears still saves most of the value, because the attacker needs a fresh quantum run for every key. For a setup weakness, the machine has to appear once, the exploit outlives the machine, and it spreads. Any protocol whose security rests on fixed public parameters derived from a discarded secret has this property, and blockchains have no monopoly on the pattern. We’d put a line for setup ceremonies in every cryptographic inventory we build, and ask the same question of any enterprise system running on parameters generated once and trusted since.

What coordination buys, and what it doesn’t

We rate Ethereum’s coordination on this as the strongest of any large public chain. Post-quantum readiness is a named research priority at the Ethereum Foundation, the work runs across consensus signatures, proof systems, hash-function hardening, and contract-layer migration, and the published research direction points at hash-based signatures for consensus and STARK-based proofs in place of pairing-based ones. Hash function hardening has its own cryptanalysis effort behind it.

Coordination shortens the timeline. It doesn’t remove the work, and two of the five layers sit outside its reach. Deployed contracts migrate one team at a time. Rollup verifier contracts, bridge admin keys, and council keys answer to their own governance. No protocol upgrade can rekey a contract that a company deployed three years ago and has since staffed down.

What to do now, by role

Validator and staking operations. Track the hash-based signature research and plan for credential rotation as a supported operation rather than an emergency. Push for interim rotation mechanisms inside your pool now.

Contract owners. Inventory your admin keys before you look at user signatures. Raise multisig thresholds, since each additional key is another quantum derivation an attacker has to complete. Decide today how you would deploy and migrate to a replacement verifier.

Stablecoin and tokenized asset issuers. Admin key compromise reaches your peg, not just your treasury. Your migration plan needs a governance path, not only an engineering one.

Rollup teams. Classify your proof system first, pairing-based or hash-based. Then the bridge contract, then the council keys. Assume the council override disappears on the schedule your decentralization roadmap already published.

Holders. Any account that has sent a transaction has published its key, and there’s nothing you can do about that today. When protocol-level signature choice ships, move early rather than in the queue.

Where to take this next

Everything above is one exercise. Read a system’s cryptographic inventory, classify each primitive by how it fails and how many times an attacker has to succeed, then name the team that owns each fix. Ethereum is a hard instance because the answers span five layers and five sets of owners. Most corporate estates look easier only because nobody has published theirs.

Our post-quantum certification programs teach that exercise against production systems: building the inventory, classifying exposure by attack class rather than by algorithm name, and sequencing migration around what cannot be rotated later. You can see the current programs at quantumacademy.com/. For methodology at organizational scale, the PQC Migration Framework at pqcframework.org sets out the phases, and the longer technical analysis behind this piece is on PostQuantum.com.