Post-Quantum Cryptography

Post-quantum cryptography (PQC) is the set of public-key encryption and signature algorithms believed to remain secure even if an attacker has access to a large, fault-tolerant quantum computer. PQC is no longer hypothetical research; the first PQC algorithms are standardized, shipping in widely used software, and already protecting significant fractions of real Internet traffic.

While much of the digital asset industry treats quantum risk as a future concern, the rest of the technology ecosystem is already deploying post-quantum protections at scale. PQC is already deployed at scale across the Internet. The gap between the Internet’s pace of PQC adoption and the blockchain industry’s pace of PQC adoption is not a gap in awareness. It is a gap in urgency.

Generally speaking, there are two different migration problems to address when talking about a PQC transition: key establishment (key exchange) for protocols like TLS and SSH, where “harvest now, decrypt later” (HNDL) risk shows up; and digital signatures for authentication and authorization, which Project Eleven calls a “harvest now, forge later” (HNFL) attack. If a CRQC can derive private keys from public keys for elliptic curve signatures, then it can forge signatures — especially relevant where signatures are meant to be long-lived and directly protect real value, which is precisely what blockchains do.

“Key establishment migration explains why the Internet moved quickly on PQ key exchange while signature migration — the part that matters most to digital assets — has yet to see wide adoption.”

NIST PQC Algorithm Comparison

In August 2024, NIST published three finalized PQC standards.

• ML-KEM (FIPS 203) [27] — The NIST-standard key encapsulation mechanism (KEM) for establishing shared symmetric keys over an insecure channel. Derived from CRYSTALS-Kyber, designed to replace RSA key transport and ECDH in protocols like TLS and SSH. Wire size: ~800–1,568 bytes for ciphertext.

• ML-DSA (FIPS 204) [28] — The NIST-standard lattice-based digital signature scheme, derived from CRYSTALS-Dilithium. The primary standard intended to replace ECDSA and EdDSA for general-purpose signing. Signature size: 2,420–4,627 bytes — 38 to 72 times larger than a 64-byte Ed25519 or Schnorr signature.

• SLH-DSA (FIPS 205) [29] — The NIST-standard stateless hash-based signature scheme, derived from SPHINCS+. Viewed as the most conservative option because its security relies on the well-understood properties of hash functions. The trade-off is size: signatures range from 7,856 to 49,856 bytes depending on variant and security level.

Additional Standards in Progress

• FN-DSA (FIPS 206). Based on FALCON, FN-DSA offers smaller signatures and public keys than ML-DSA — a meaningful advantage for bandwidth- and storage-constrained systems. The trade-off is implementation complexity: FALCON-style schemes require floating-point arithmetic during signing, raising engineering cost and the risk of subtle bugs across platforms.

• HQC. Selected by NIST in March 2025, HQC is a second KEM intended to diversify underlying hardness assumptions. Unlike ML-KEM, it is not lattice-based, reducing ecosystem dependence on a single mathematical family. The trade-off is performance: HQC has larger messages and generally higher computational cost, so it is unlikely to replace ML-KEM as the default for high-volume protocols.

Practical Takeaway

ML-KEM solves key establishment with manageable wire sizes, around 1 KB for the commonly deployed ML-KEM-768 ciphertext. ML-DSA is the general-purpose signature standard, but signatures are roughly 2.4-4.6 KB, about 38-72× larger than a 64-byte Ed25519 or Schnorr signature. SLH-DSA offers a conservative hash-based option, but signature sizes are measured in tens of kilobytes. For systems where every byte is metered, priced, or propagated across a global network, especially blockchains, these numbers are the central engineering constraint.

ML-KEM (FIPS 203): Key Size Parameters by Security Level

Parameter Set	Security Category	Public Key (bytes)	Private Key (bytes)	Ciphertext (bytes)
ML-KEM-512	1	800	1,632	768
ML-KEM-768	3	1,184	2,400	1,088
ML-KEM-1024	5	1,568	3,168	1,568

ML-DSA (FIPS 204): Key Size Parameters by Security Level

Parameter Set	Security Category	Public Key (bytes)	Private Key (bytes)	Signature (bytes)
ML-DSA-44	2	1,312	2,560	2,420
ML-DSA-65	3	1,952	4,032	3,309
ML-DSA-87	5	2,592	4,896	4,627

Existing Deployments

PQC is no longer only in the standardization phase. It is being shipped into production systems at scale. The rollout pattern is consistent across the industry: deploy PQ key exchange first (often as a hybrid with classical ECDHE), then tackle signatures more slowly because PKI and code-signing ecosystems take longer to migrate. This pattern should be instructive for anyone planning a blockchain PQC transition: the easy part is done, and even the easy part took years.

Internet & Browsers (TLS)

Hybrid key exchange in TLS 1.3 is being standardized in the IETF TLS working group [30], including a general construction for combining classical and post-quantum key exchange so that the session remains secure if at least one component holds. In practice, this means combining X25519 with ML-KEM-768 into a single key agreement. Cloudflare enabled post-quantum hybrid key agreement across its network by default in October 2022 [31], and by December 2025, Cloudflare reported that 52% of human web traffic was post-quantum encrypted, nearly doubling from 29% at the start of the year [32]. On the client side, Google shipped support for ML-KEM hybrid post-quantum TLS in Chrome 131 [33]. Apple enabled hybrid post-quantum TLS support in iOS 26 [34], producing an immediate and measurable jump in PQ-encrypted traffic from mobile devices: within four days of the iOS 26 release, PQ support from iOS devices jumped from under 2% to 11%, and exceeded 25% by early December [32].

SSH (Key Establishment)

OpenSSH has offered post-quantum key agreement by default since OpenSSH 9.0 (April 2022). OpenSSH 10.0 (April 2025) adopted an ML-KEM-based hybrid (mlkem768x25519-sha256) as the new default [35]. For any organization running current SSH infrastructure, post-quantum key agreement is already the baseline, with no configuration changes required.

Cloud Platforms & OS Crypto

AWS and Google Cloud have both announced support for post-quantum KEMs in their KMS products [36, 37]. Apple has added PQC to CryptoKit as of iOS and macOS 26, including support for both ML-DSA and ML-KEM [34]. These are not experimental previews; they are production APIs that signal the expectation that downstream applications will begin integrating PQC into their own cryptographic workflows.

The State of Play

The Internet’s key exchange infrastructure is already well into its post-quantum transition. Signatures are the unsolved problem. And signatures are exactly what blockchains depend on.

Impact on Blockchains

Blockchains are disproportionately exposed to the signature side of the PQC transition. Every transaction is an authorization, and authorization is signature verification. That means the dominant costs are not KEMs or handshake overhead, but signature size, verification cost, mempool and block propagation, and block capacity. The key exchange migration already underway across the Internet does not address this risk. Blockchains need signature upgrades, which carry fundamentally different costs and coordination requirements.

The Wire Size Constraint

The first hard constraint is wire size. A typical Ed25519 or Schnorr signature is 64 bytes. An ML-DSA-44 signature is 2,420 bytes, roughly 38× larger. An ML-DSA-65 signature is 3,309 bytes. Moving from compact elliptic curve signatures to multi-kilobyte post-quantum signatures increases transaction size, bandwidth consumption, and storage requirements. In any system where transaction size affects fees, propagation latency, block capacity, and validator hardware requirements, that increase propagates into every layer of the economic and operational model.

The Validation Cost Constraint

The second hard constraint is validation cost. Benchmarks [38] show that ML-DSA signing is roughly 8 to 15× slower than ECDSA secp256k1, but ML-DSA verification is comparable or faster: ML-DSA-44 verification is approximately twice as fast as ECDSA. Since blockchains verify far more signatures than they produce, the verification profile of ML-DSA is surprisingly favorable for on-chain use. SLH-DSA tells a different story: signing ranges from milliseconds to over a second depending on the parameter set, and verification, while much faster than signing, is still 12 to 50× slower than ECDSA. ML-DSA is the fastest of the NIST PQ signature standards. If a network chooses SLH-DSA for its more conservative security assumptions, the compute overhead becomes a binding constraint alongside size. But for ML-DSA specifically, the dominant cost of post-quantum signatures on-chain is wire size, not verification time.

In practice, PQ signature adoption almost always implies protocol-level changes rather than a simple algorithm swap, because existing transaction formats, script limits, and fee models were designed around compact elliptic curve signatures.

Chain-Specific Engineering Constraints

Post-quantum signatures create different engineering constraints across chains, but the core problem is universal: transaction formats, consensus rules, and fee models were designed around compact elliptic curve signatures, not multi-kilobyte post-quantum alternatives.

Bitcoin

Bitcoin’s scaling model is built around SegWit weight accounting: a 4,000,000-WU block limit where non-witness bytes cost 4 WU and witness bytes cost 1 WU. The witness discount helps, but it does not eliminate the cost of larger signatures — the bytes still flow through the network and must be stored by nodes. BIP-360 [39] introduces a new output type, P2MR (Pay-to-Merkle-Root), that functions like Taproot but with the quantum-vulnerable key-path spend removed. A companion proposal, QBIP [40], builds on BIP-360 by defining a phased sunset of legacy ECDSA and Schnorr signatures: first disallowing new spends to quantum-vulnerable address types, then, after a multi-year transition window, disallowing spends from them entirely.

A 2,420-byte ML-DSA-44 signature consumes roughly 605 vbytes of witness data alone, several times larger than a typical single-input P2WPKH spend today. Bitcoin Script also imposes a 520-byte maximum stack element size, retained by BIP 342, meaning a multi-kilobyte signature cannot be pushed and checked in the current model.

Adopting PQ signatures likely requires new witness program versions, new opcodes, and revised fee and propagation assumptions. BIP-360 introduces P2MR, a Taproot-style output type with the quantum-vulnerable key-path spend removed. QBIP builds on this with a phased sunset of legacy ECDSA and Schnorr signatures.

Ethereum

Ethereum’s migration is more complex because it embeds three distinct quantum-vulnerable primitives: ECDSA for externally owned accounts, BLS signatures for Proof-of-Stake consensus, and KZG commitments for data availability.

Account abstraction provides a viable path for user-account migration by decoupling transaction validation from a hardcoded signature scheme. But the consensus layer is harder: BLS aggregation is what makes Ethereum’s large validator set practical, and there is no production-ready post-quantum analogue today.

Lean Ethereum and the Strawmap are the main coordinated efforts, with research focused on replacing BLS with hash-based signatures, exploring zkVM-based aggregation, and migrating accounts through account abstraction. None of these paths are trivial or production-ready yet.

The most significant post-quantum effort for Ethereum is Lean Ethereum [41], a coordinated research and engineering program tackling both consensus-layer and account-layer migration. The overarching proposal of this process planning for post-quantum migration is the Strawmap [42].

Solana

Solana’s transaction format is tightly optimized for Ed25519’s 32-byte public keys and 64-byte signatures, with a default transaction size limit of 1,232 bytes. A single ML-DSA-44 signature is 2,420 bytes, and its public key is 1,312 bytes, exceeding the limit even for a basic transfer.

EdDSA with RFC-8032 key derivation computes the signing scalar from a seed via a hash function [43]. Recent research has shown that this property enables post-quantum-secure zero-knowledge proofs of seed knowledge, potentially allowing EdDSA accounts to bind their existing address to a new post-quantum key without moving funds [44].

Project Eleven’s post-quantum Solana testnet confirmed that the bottleneck is not verification speed, but data movement. The roughly 16× increase in per-transaction size propagates through packet ingestion, deserialization, batching, and block production, reducing sustainable throughput proportionally. A production deployment would require a purpose-built transaction format, a new address primitive, redesigned packet handling, and updated fee models.

Other Chains

Every chain using elliptic curve signatures faces the same broad issue: PQ signatures are much larger, and every layer that touches signature data must be redesigned around that reality. EdDSA HD wallets using SLIP-0010 derivation extend this advantage: every node in the hierarchy is a seed derived by HMAC from the parent seed, meaning the entire key tree remains quantum-safe even if individual signing scalars are compromised [43].

The migration path also depends on the signature scheme. EdDSA chains — including Solana, Sui, Aptos, Near, and Stellar — may have a cleaner path because RFC-8032 derives the signing scalar from a seed via a hash function. Even if a CRQC recovers the signing scalar, it cannot reverse the hash to recover the seed. This may allow accounts to prove seed ownership and bind an existing address to a new PQ key without moving funds.

ECDSA chains generally lack this property. ECDSA wallets typically derive or sample private scalars directly, so the same zero-knowledge migration path does not apply cleanly. Some BIP-32/BIP-85 wallets may support bespoke ZK approaches, but proving those derivations is expensive and does not help dormant accounts with unknown derivation paths.