Skip to content

Why post-quantum

Ethereum’s security rests on ECDSA over secp256k1. Owning an account means knowing a private key; proving ownership means producing a signature that the protocol can verify by recovering the public key from it.

Shor’s algorithm breaks this. A sufficiently large, sufficiently reliable quantum computer recovers a private key from a public key in polynomial time. The same applies to every elliptic-curve scheme in use today, including the P-256 curve behind WebAuthn and platform keystores, and including BLS signatures. Hash functions are far less affected — Grover’s algorithm gives only a quadratic speedup, which a wider hash absorbs — so the damage is concentrated precisely in the signatures.

Two properties make the timeline worse than “we will migrate when machines arrive”.

Public keys are already exposed. On Ethereum, an address is a hash of a public key, so an account that has never sent a transaction reveals only the hash. But the moment it sends one, the signature reveals the public key permanently, on a public ledger, forever. Every account that has ever transacted is a standing target. There is no way to un-publish it.

Harvest now, decrypt later. An adversary does not need a quantum computer today to benefit from one tomorrow. Recording the chain now and breaking keys later works fine, because the chain is public and permanent by design. The window of exposure opened years ago.

Together these mean the migration must complete before the machines exist, not after — and a migration that requires every user to actively move funds is a migration that never finishes. Some fraction of keys are lost, some holders are inattentive, and the remainder is a very large pot of money sitting behind broken cryptography.

The obvious patch — swap the signature algorithm — runs into Ethereum’s account model.

Post-quantum keys do not fit in an address. An ML-DSA-65 public key is 1,952 bytes. An Ethereum address is 20. You cannot derive one from the other in a way that lets the protocol reconstruct the key.

There is no public-key recovery. ECDSA lets a verifier recompute the public key from the signature and message, which is why ecrecover works and why Ethereum never needs to store or transmit public keys. NIST’s post-quantum signature schemes have no such operation. The verifier must be given the public key, which means something on chain has to hold it.

Verifying in Solidity is unaffordable. A hand-written lattice verifier in EVM bytecode costs millions of gas per signature. Any design that puts post-quantum verification in userland contract code prices ordinary transactions out of existence.

Account abstraction alone is not enough. ERC-4337 moves validation into contract code, which is the right shape — but a bundler still submits the bundle as an ordinary transaction signed with an ECDSA key. The classical signature stays on the critical path, so the system is only as quantum-safe as the bundler’s key. And the gas problem remains.

So the fix needs three things at once: somewhere for the public key to live, a transaction format that carries a signature the protocol does not itself interpret, and native verification cheap enough to use.

The key lives in the account. Each post-quantum account is a contract whose code embeds its own public key, or points at it in storage. Verification checks the signature against that key, which the account itself fixed at creation. Nothing needs to be registered anywhere, and no shared registry becomes a bottleneck or a target. See Keys in accounts, not a registry.

The transaction format carries an uninterpreted witness. EIP-8141 frame transactions name the sender explicitly and carry a list of signature entries. An entry can be marked ARBITRARY, meaning the protocol does not verify it — it simply makes the bytes available to the account’s code, which knows what to do with them. This is what lets a scheme the protocol has never heard of authorise a transaction.

Verification is a precompile. 0x14 and 0x15 verify ML-DSA-65 and ML-DSA-44 natively, priced at throughput parity with ecrecover. A post-quantum spend costs roughly 16,000 gas of verification instead of millions.

Crypto-agility falls out of the design. Because the scheme lives in account code rather than in the protocol’s notion of an account, adding a new algorithm means adding a precompile and a new account type — not changing what an address means. Users adopt it by creating a new account, on their own schedule.

Signatures authorising transactions are the visible half. The chain itself has several other places where a classical primitive would leave a hole, and Frost closes them too:

  • Consensus block signatures are post-quantum, using a compact lattice scheme for the high-volume block tier and stronger long-lived keys for the checkpoint roots. See Two-tier consensus keys.
  • Checkpoint roots are signed with two independent schemes — one lattice based, one hash based — and both must verify. A break in one family does not break the checkpoint chain.
  • Validator transport uses hybrid post-quantum key exchange (X25519MLKEM768) as the only offered group, and post-quantum identities, so recorded traffic cannot be decrypted later.

Frost secures accounts created on Frost. It does not retroactively protect funds on other chains, and it does not make a lost key recoverable. Post-quantum signatures are also simply larger — a spend witness is around 3.3 KB rather than 65 bytes — which turns storage growth into a first-order engineering problem rather than an afterthought. History and storage covers what that costs and how the chain absorbs it.