Why post-quantum cryptography matters for blockchains

Almost every blockchain in production today rests on two cryptographic assumptions: that it is hard to factor large numbers, and that it is hard to compute discrete logarithms on an elliptic curve. Bitcoin, Ethereum, and most proof-of-stake chains authorize transactions with ECDSA or EdDSA signatures, both of which stand on the second assumption. A sufficiently large, error-corrected quantum computer running Shor's algorithm dissolves both.

What Shor's algorithm actually breaks

Shor's algorithm, published in 1994, solves integer factorization and discrete logarithms in polynomial time on a quantum computer. That is precisely the class of problems that public-key cryptography assumes are intractable. If you can solve the discrete log problem efficiently, you can derive a private key from its corresponding public key. For a blockchain, that means deriving the spending key from any address whose public key is known.

It is worth being precise about the exposure. Hash functions like SHA-256 and Keccak are not broken by Shor's algorithm. Grover's algorithm offers only a quadratic speedup against them, which is comfortably handled by doubling output sizes. The exposure is signatures. The scheme that proves you authorized a transaction is the part that fails.

Harvest now, decrypt later

The uncomfortable part is that the threat does not wait for the hardware to arrive. A blockchain is a permanent, public, append-only ledger. Every public key that has ever signed a transaction is recorded forever. An adversary can copy the entire chain today, store it cheaply, and simply wait. The day a capable quantum computer exists, every exposed key on that historical ledger is retroactively vulnerable. This is the "harvest now, decrypt later" model, and it is why the migration deadline is effectively earlier than the hardware deadline.

The migration deadline for a public ledger is not when quantum computers arrive. It is now, because the data an attacker needs is already published and permanent.

Why chains are the hardest case

Migrating a web server to a post-quantum TLS handshake is a coordinated software update. Migrating a blockchain is harder for three reasons. First, keys are long-lived and often reused, so exposure accumulates. Second, consensus itself is signature-driven: validators sign blocks and finality votes, so the security of the network, not just individual wallets, depends on the signature scheme. Third, changing the signature scheme is usually a consensus-breaking change that the whole network must adopt at once.

This is why designing for post-quantum signatures from the start is a meaningfully different engineering posture than bolting them on later. A chain that is post-quantum at the base layer signs blocks, votes, and transactions with quantum-resistant schemes from genesis, so there is no window of exposed history to migrate away from.

What replaces ECDSA

The U.S. National Institute of Standards and Technology ran a multi-year competition and, in 2024, standardized a first set of post-quantum algorithms. For signatures, the primary standard is ML-DSA (FIPS 204), derived from the CRYSTALS-Dilithium submission, a lattice-based scheme whose security rests on the hardness of problems over module lattices rather than discrete logarithms. Lattice problems are not known to be efficiently solvable by quantum computers.

The trade is size. A post-quantum signature is larger than a 64-byte ECDSA signature, and public keys grow too. For node operators this shows up as more bandwidth per block and more storage over time, which is a design consideration rather than a blocker. The next article looks at exactly what those size changes mean in practice.

The takeaway is simple: the cryptography that protects value on a public ledger has a shelf life, and for a permanent ledger the clock is already running. Building on a chain that is quantum-resistant at the base layer removes an entire category of future risk from the operator's plate.