ML-DSA, SLH-DSA and STARKs: what replaces ECDSA, BLS and KZG

In late September 2026, the IACR ePrint paper 2026/2222, "SoK: The Landscape of Post-Quantum Multi-Party Signature Aggregation", surveyed more than 30 post-quantum signing schemes published between 2021 and 2026 and found that most of them target blockchain validator consensus. Any team that signs, aggregates or proves with ECDSA, Schnorr, BLS, KZG or pairing-based SNARKs should list those uses now and plan for much larger signatures.

This guide is for protocol, wallet, bridge and ZK engineers. By the end you will have a map of which schemes a large quantum computer breaks, what replaces each one, the published timelines, and a checklist you can start this week. You need a working knowledge of digital signatures and SNARKs. The standards referenced are NIST FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), the FIPS 206 draft (FN-DSA) and the NIST IR 8547 initial public draft.

What breaks and why

Shor's algorithm solves discrete logarithms in elliptic-curve groups. Every scheme whose security reduces to that problem fails once a large enough fault-tolerant quantum computer exists:

ECDSA on secp256k1 signs Bitcoin and Ethereum transactions. ethereum.org notes that for any account that has sent a transaction, the public key is exposed onchain, so a quantum attacker could derive the private key from it.
Schnorr signatures (for example Bitcoin's Taproot keys) rely on the same elliptic-curve discrete-log problem and fall to the same attack.
BLS signatures use elliptic-curve pairings. Ethereum's consensus layer uses them to aggregate votes from hundreds of thousands of validators.
KZG commitments use pairings too. Ethereum uses them for blob data availability.
Pairing-based SNARKs (Groth16, and PLONK-style systems with KZG) rest on the same curves. A quantum attacker could forge proofs, so the verifier's soundness guarantee is gone.

Hash functions and lattice problems are different. ethereum.org describes hash-based signatures as relying only on hash functions, "which quantum computers weaken but do not break". Lattice schemes such as ML-DSA rely on Module-LWE and Module-SIS, which are believed to resist quantum attacks.

Comparison table: today's schemes and their replacements

The ML-DSA, Falcon, SLH-DSA and aggregation figures come from ePrint 2026/2222. The BLS and leanXMSS figures come from ethereum.org. ECDSA sizes are the standard secp256k1 encodings.

Scheme	Typical blockchain use	Hard problem	Quantum status	Size (public key / signature or proof)
ECDSA secp256k1	Bitcoin and Ethereum accounts	EC discrete log	Broken by Shor	33 B / 64-65 B
Schnorr (secp256k1)	Bitcoin Taproot	EC discrete log	Broken by Shor	32 B / 64 B
BLS12-381	Ethereum validator votes	Pairings	Broken by Shor	signature 96 B
KZG	Blob commitments, PLONK-style SNARKs	Pairings	Broken by Shor	small, constant
Groth16	Onchain proof verification	Pairings	Broken by Shor	small, constant
ML-DSA-65 (FIPS 204)	General-purpose PQ signatures	Module lattices	Considered post-quantum	1,952 B / 3,309 B
FN-DSA / Falcon-512 (FIPS 206 draft)	Compact PQ signatures	NTRU lattices	Considered post-quantum	897 B / ~666 B average
SLH-DSA (FIPS 205)	Conservative, stateless	Hash functions only	Considered post-quantum	32-64 B / ~8-50 KB
leanXMSS	Planned Ethereum validator signatures	Hash functions	Considered post-quantum	signature ~3,000 B
STARK (FRI)	Rollups, hash-signature aggregation	Hash functions	Considered post-quantum	100-200 KB for thousands of signatures

The last row explains why aggregation matters. ePrint 2026/2222 cites a 2021 construction in which a STARK proves the validity of many one-time hash-based signatures, giving a proof of "roughly 100 to 200 KB" whether it aggregates hundreds or thousands. Per ethereum.org, Ethereum's planned leanVM compresses leanXMSS signature data by 250x, compared with a 96-byte BLS signature today.

Published migration timelines

These are the dates that standards bodies and major infrastructure have published. Treat roadmap items as plans, not commitments.

Who	What	Date or status
NIST	FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) finalized	August 2024
NIST	FIPS 206 (FN-DSA / Falcon)	Still a draft, per ePrint 2026/2222
NIST	IR 8547 initial public draft: 112-bit quantum-vulnerable algorithms (RSA-2048, ECC P-256 and similar) deprecated after 2030, disallowed after 2035	Draft published 12 November 2024; not finalized as of mid-2026
Google	Internal deadline to move its own systems to post-quantum cryptography	2029 (as reported by ethereum.org)
Ethereum Foundation	Milestone I*: PQ key registry next to BLS keys	Planned
Ethereum Foundation	Milestone J*: PQ signature verification precompiles	Planned
Ethereum Foundation	Milestone L*: PQ attestations and real-time consensus proofs via leanVM	Planned
Ethereum Foundation	Milestone M*: full PQ signature aggregation and PQ-safe blob commitments	Core work targeted for about 2029
Ethereum	EIP-8141 account abstraction for per-account signature agility	Being considered for Hegotá, second half of 2026 (ethereum.org, updated 8 September 2026)

ethereum.org also cites a March 2026 Google Quantum AI estimate that breaking 256-bit elliptic-curve cryptography could need roughly 1,200 logical qubits. Current hardware has a few thousand noisy physical qubits, so the threat is not immediate. The Ethereum Foundation formed its Post-Quantum Security team in January 2026. Its reference code (leanSpec in Python, leanSig in Rust, leanMultisig) lives in the leanEthereum GitHub organization. For the zkVM side of these plans, see Lattice Jolt Makes Post-Quantum zkVMs a Systems-Choice Problem.

Step-by-step: what to do now

List every use of quantum-vulnerable cryptography. Search your code, contracts and infrastructure for ECDSA (ecrecover, secp256k1 libraries), Schnorr, Ed25519, BLS, KZG and Groth16 or PLONK verifiers. Include bridges, multisigs, oracle signers, session keys and off-chain attestations.
Rank each item by exposure. Keys whose public half is already onchain are the most exposed, as are long-lived keys and anything that protects funds. ethereum.org points out that accounts which have only received funds expose just a hash of the public key, which gives some extra protection.
Remove hard-coded signature assumptions. Authorization logic that only accepts ecrecover cannot migrate without a redeploy. Add a scheme identifier to signed payloads and route verification through a replaceable verifier module. Ethereum's EIP-8141 approach gives each account this kind of signature agility.
Plan for the size increase. An ML-DSA-65 signature is 3,309 bytes, about 50 times a 65-byte ECDSA signature. SLH-DSA can reach about 50 KB. Check calldata costs, storage layouts, message size limits, mempool rules and any fixed-size buffers.
Choose the scheme for the job. ML-DSA is the finalized general-purpose lattice standard. SLH-DSA is the conservative choice that depends only on hashes. Falcon has the smallest signatures, but FIPS 206 is still a draft. XMSS-style schemes such as leanXMSS fit signers that sign once per slot and can track key state.
Use hash-based proofs for new ZK work. STARKs built on FRI rely on hashes. ethereum.org notes that several rollups already use them. For lattice alternatives, see Lattice Jolt Turns Post-Quantum Proofs Into a Deployment Tradeoff.
Plan aggregation early. If you verify many signatures, decide whether you need threshold signing, proof-based aggregation or STARK aggregation. ePrint 2026/2222 shows these use very different key models, interaction rounds and accountability.
Track standards and EIPs. Watch the final FIPS 206 text and the final NIST IR 8547, and follow the Ethereum I*/J*/L*/M* milestones before you lock a design.

Pitfalls and troubleshooting

A STARK wrapped in Groth16 is not post-quantum. Many zkVM pipelines compress a STARK into a Groth16 or PLONK proof over a pairing-friendly curve for cheap onchain checks. The final proof that the chain accepts is pairing-based. Also check the statement being proven: a hash-based proof that verifies an ECDSA signature still depends on ECDSA. A ZK Proof Can Be Hash-Based—and Still Carry a Quantum-Vulnerable Claim covers this case.

Falcon versions differ. ePrint 2026/2222 notes that the FIPS 206 draft differs from the earlier Falcon specification in parts of the signing transcript, "including salt sampling and public-key hashing". Several aggregation schemes were built on the older specification. Check which version a library implements.

Stateful hash signatures can fail badly. In XMSS-family schemes, each one-time key index must be used only once. Restoring a validator from an old backup, or running two signers on one key, can reuse an index and leak key material. Keep the signing state in durable, single-writer storage.

Rogue-key attacks in aggregation. When signers choose their own keys, an aggregation scheme needs an explicit defense such as proof-of-possession or key-set binding. The SoK notes that one lattice half-aggregation line had to be corrected after publication for this reason.

Threshold signing has setup costs. Threshold ML-DSA results often report online signing only. The SoK's third hypothesis warns that the one-time distributed key generation cost may not be negligible for small signer groups.

KZG's trusted setup is a separate issue. ethereum.org explains that the KZG setup ceremony stays secure as long as one participant was honest, even against quantum attackers. The commitments themselves are still pairing-based and need replacing, with STARK-based or lattice-based commitments as the candidates.

FAQ

Can a quantum computer steal funds from an address that never sent a transaction?

It is harder. Such an address shows only a hash of the public key, and ethereum.org says this gives extra protection. Once the account signs a transaction, the public key is onchain, and ethereum.org says all accounts should eventually migrate.

Are STARKs post-quantum?

STARKs built on FRI and hash commitments are considered quantum-resistant because they rely only on hash functions. That stops being true if the STARK is wrapped in a pairing-based SNARK for onchain verification, or if the proven statement checks a quantum-vulnerable signature.

When does NIST stop allowing ECDSA?

The NIST IR 8547 initial public draft (12 November 2024) proposes deprecating 112-bit quantum-vulnerable public-key algorithms after 2030 and disallowing them after 2035. ethereum.org applies these dates to ECDSA. The draft was not final as of mid-2026, so treat the dates as a planning baseline.