Marin Ivezic
No quantum computer can recover a Bitcoin or Ethereum private key today, and none is close. The best published estimate for factoring RSA-2048 puts the requirement below one million noisy physical qubits running for roughly a week (Gidney, 2025), and the largest machines built so far operate far below that scale. Elliptic-curve keys, which is what almost every blockchain signs with, are generally estimated to need fewer resources than RSA, but the gap remains enormous. We put the bar for a cryptographically relevant quantum computer, meaning one large and reliable enough to derive a private key from a published public key, well beyond anything running today.
The dates do exist, and they’re what bind. NIST’s IR 8547 initial public draft proposes deprecating ECDSA after 2030 and disallowing it after 2035. The NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) timeline expects national security systems to be using post-quantum algorithms exclusively by 2033 (NSA post-quantum resources). Financial regulators, insurance underwriters, and institutional counterparties will carry those dates into their own questionnaires long before any hardware milestone arrives. Cryptographic migrations take years. That is the whole argument for starting now.
We sort the work by what it depends on. Some of it needs nobody’s permission. Some of it waits on a protocol upgrade. Some of it waits on an entire community reaching consensus, and that last category is where teams tend to park work that belongs in the first.
What needs nobody’s permission
Address hygiene
Bitcoin hides your public key behind a hash until you spend. The moment a transaction is signed, the key becomes visible on-chain and stays visible forever. Reusing an address means every coin still sitting there is protected by a key an attacker can already read.
That gives holders a real distinction to act on. Funds received to a fresh SegWit address (the bc1q prefix) and never spent from have no public key on the chain. Funds in a Taproot address (bc1p) do, because the output commits to a key directly rather than to a hash of one. The very oldest pay-to-public-key outputs, from Bitcoin’s first years, have always been exposed. Legacy 1... and 3... addresses sit in between: hash-protected until first spend, exposed after it.
Stop reusing addresses. Every modern hierarchical-deterministic wallet generates a fresh receive address by default, and Bitcoin’s UTXO model (each transaction consumes whole prior outputs and creates new ones) routes change to a new address automatically. The exposure comes from overriding that behaviour, or from publishing one address as a static payment endpoint.
For custody operators, this is the highest-impact fix available without a single protocol change. Enforce single-use deposit addresses, audit existing pools for reuse, and consolidate anything exposed into fresh outputs. Treat extended public keys as sensitive material: an xpub handed to a portfolio tracker exposes a whole branch of the derivation tree.
Ethereum offers no equivalent lever. The account model publishes your public key on your first outbound transaction and there’s no hash to hide behind afterwards. Accept the exposure as known, and put the effort into the migration path instead.
Hybrid transport encryption
Peer-to-peer traffic between nodes is encrypted with classical key exchange, which means it’s collectible now and decryptable later. That’s the harvest-now-decrypt-later problem, or HNDL: an adversary records ciphertext today and stores it against the arrival of a machine that can break the key exchange. For blockchain networks the payload is metadata, and metadata deanonymises.
The fix ships today, on any chain, without touching consensus. Derive the session key from both a classical Diffie-Hellman secret and an ML-KEM (FIPS 203, formerly Kyber) secret concatenated together. That is what hybrid means here: the session stays secure as long as either primitive holds. Bitcoin and Lightning teams can apply it to the Noise handshake in BOLT 8. Ethereum client teams can apply it to devp2p. No fork, no coordination, no waiting.
A cryptographic inventory
Nobody migrates what they haven’t listed. Before choosing algorithms, write down where signing and key exchange actually happen across the estate: cold storage signing workflows, hot wallet rotation, HSM firmware, TLS terminators, code signing, internal service authentication. Note the primitive, the key size, the owner, and how the primitive would be replaced.
That last column is the one that matters and the one usually left blank. The PQC Migration Framework sets out a structured way to run this assessment, including financial-services extensions that map onto custody infrastructure.
Crypto-agility as a design constraint
Crypto-agility means a system can change its cryptographic primitives without rewriting the layer above. It’s a property you design in, not a patch you apply.
It matters here because the algorithm set isn’t settled. FN-DSA remains in draft. Lattice assumptions will keep attracting cryptanalysis. Hash-based signatures are the conservative fallback precisely because they rest on different mathematics. A custody platform that can swap a signature scheme through configuration will absorb the next decade’s news. One that has ECDSA compiled into its transaction construction will not.
What waits on your platform
Bitcoin’s route to a quantum-resistant output type is BIP-360, which commits to a Merkle root of scripts rather than to one key. Different leaves can carry different algorithms, which is crypto-agility written into the consensus layer. It’s a proposal, not an activated soft fork. Track it, and plan a migration of holdings once quantum-resistant outputs are spendable.
Ethereum’s route runs through account abstraction. EIP-7702, delivered in the Pectra upgrade, lets an externally owned account delegate execution to contract code, and that’s the practical mechanism for verifying a non-ECDSA signature without changing an address. Wallet and custody teams should be testing against it now, because the migration window will be short and crowded. Validators are a separate problem: BLS signing keys sit published in the registry, and the replacement path is still an open research question. Argue for fast key rotation inside your staking pool as the interim measure.
Size the change before you schedule it
Post-quantum signatures are not drop-in. They’re one to two orders of magnitude larger, and that lands on fee estimation, UTXO management, block space, gossip bandwidth, and every hardware signing device in the cold storage path.
| Scheme | Signature | Public key |
|---|---|---|
| Schnorr, BIP-340 (secp256k1) | 64 bytes | 32 bytes (x-only) |
| ECDSA (secp256k1) | 64–72 bytes (DER) | 33 bytes (compressed) |
| ML-DSA-44 (FIPS 204, formerly Dilithium) | 2,420 bytes | 1,312 bytes |
| ML-DSA-65 | 3,293 bytes | 1,952 bytes |
| FN-DSA-512 (FIPS 206 draft, formerly Falcon) | 666 bytes | 897 bytes |
| SLH-DSA-SHA2-128s (FIPS 205, formerly SPHINCS+) | 7,856 bytes | 32 bytes |
Read the table as a scheduling input. Testing PQ signature handling on a testnet is cheap this year and expensive the year a deadline lands. The same applies to hardware wallet roadmaps: ask vendors what they support and when, and treat a vague answer as an answer.
For anything new, the choice is already made. ML-KEM for key establishment, ML-DSA for general signing, SLH-DSA where a conservative hash-based option is wanted, and a hybrid classical-plus-PQ construction during transition. There’s no defensible reason to launch a new protocol or custody stack on quantum-vulnerable cryptography in 2026. Legacy systems have a migration problem. Don’t manufacture another one.
The questions your counterparties will ask
We see institutional clients and their auditors asking custodians five things: what address types cold storage uses, whether addresses are reused, what the post-quantum migration plan says, whether PQ signature handling has been tested, and what the timeline is for adopting quantum-safe output types once they exist. Every one of those is answerable today with work described above. A custodian who can’t answer them is disclosing something about operational maturity, not just cryptography.
One problem has no technical answer. A significant quantity of Bitcoin sits in addresses that are both key-exposed and long dormant, and those coins can’t be migrated because nobody holds the keys. Whether recovery ever becomes a regulated activity is a policy question, and it’s worth watching rather than solving.
Where to go next
The deeper technical treatment of each platform, including the Bitcoin and Lightning migration roadmaps, lives in the full series on PostQuantum.com. The migration methodology behind the inventory and assessment steps is at pqcframework.org.
If your team needs to build the capability rather than read about it, Quantum Academy’s post-quantum migration training covers cryptographic inventory, algorithm selection, hybrid deployment, and migration governance, with assessments built around the decisions engineers and security leads actually make. Details and enrollment are at quantumacademy.com/.