Post-Quantum Lattice or Hash-Based: One Question, Two Right Answers

Cryptography
1

A field guide to choosing between lattice and hash-based signatures

Part one if focused on the internet and part two on blockchains and Ethereum but it’s interesting to know both to find out why the choices are different.

If you’re migrating a real system to post-quantum cryptography, you’ve probably framed the signature question the way everyone frames it: lattice or hash-based? ML-DSA or SLH-DSA? Speed or paranoia?

I spent the last two weeks asking that question to some of the people who actually build, standardize, and benchmark this stuff — Peter Schwabe (co-designer of both ML-DSA and SLH-DSA’s ancestors), Bas Westerbaan (Cloudflare, driving one of the largest PQC deployments on the internet), Filippo Valsorda (maintainer of Go’s crypto libraries), Thom Wiggers (PQShield, keeper of the signatures zoo), and Michael Baentsch (Open Quantum Safe / OpenSSL provider ecosystem). Then I took their answers to the blockchain world I work in — and watched the consensus flip upside down.

The spoiler is a double one. The binary is the wrong question — every expert, coming from a different angle, pushed back on “pick one.” And the two halves of the internet are answering it in opposite directions anyway: the broader internet is converging on lattices, Ethereum on hashes. Neither side is confused. They’re answering different questions — and by the end you’ll be able to tell which question is yours.

This is a guide to how to think about the choice, not a verdict; your constraints decide.

First, thirty seconds of orientation

A quantum computer running Shor’s algorithm breaks RSA and elliptic curves — the signatures underneath TLS certificates, code signing, secure boot, JWTs, blockchains, basically everything. In August 2024 NIST finalized three post-quantum standards, two of which are signatures — FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA); the third signature, FN-DSA (FIPS 206), is still a draft:

Scheme FIPS Family Public key Signature The one-liner
ML-DSA-44 (Dilithium) 204 :white_check_mark: Lattice 1,312 B 2,420 B The general-purpose workhorse
SLH-DSA-128s (SPHINCS+) 205 :white_check_mark: Hash-based 32 B 7,856 B The conservative tank
FN-DSA-512 (Falcon) 206 :memo: draft Lattice 897 B 666 B The compact one with sharp edges

For scale, everything measured against Ed25519’s 64-byte signature: ML-DSA-44 is about 38x larger at 2,420 bytes, and SLH-DSA-128s about 120x larger at 7,856 bytes — roughly three times ML-DSA’s. Signing SLH-DSA is slower than Ed25519 by four orders of magnitude (about three against ML-DSA). Nothing post-quantum wins on every metric at once — there is no all-star.

FN-DSA is the smallest of the three, but NIST only submitted the draft standard for approval on August 28, 2025, and final publication is expected late 2026 or early 2027.

One row deserves a second look, because it quietly drives everything in Part Two: the public-key column runs opposite to the signature column. Lattice schemes have small signatures and large keys relative to hash-based schemes; hash-based schemes have bulky signatures and tiny keys (an SLH-DSA public key is one 32-byte hash). Keep that asymmetry in your pocket.

The security intuition behind the two families:

Lattices (ML-DSA, FN-DSA). Security rests on the hardness of finding short vectors in high-dimensional structured lattices. Enormously studied, but the math is young-ish and cryptanalysis has historically chipped bits off lattice security estimates.

Hash functions (SLH-DSA). Security rests only on properties of SHA-2/SHAKE — assumptions so battle-tested that if they fall, far more than your signature scheme is on fire. The most conservative bet available. The price: SLH-DSA is, in Michael Baentsch’s memorable phrasing, heavy-weight on every dimension — size, signing time, energy.

So the naive framing writes itself: lattices for speed and scale, hashes for long-lived trust anchors, agility so you can change your mind. That’s roughly where I started.

The asymmetry that sets your clock

One thing worth stating plainly, because it explains why the industry did key exchange first and is only now arguing about signatures:

Encryption’s deadline is in the past. Signatures’ deadline is in the future.

Encrypted traffic captured today can be decrypted the day a quantum computer arrives — harvest now, decrypt later. Every ciphertext you’ve already sent is already at risk, which is why ML-KEM shipped first and fastest. Signatures don’t work that way. A quantum computer cannot alter the signature bytes you made in 2026, but it can eventually undermine their authenticity by forging a new valid signature under the same public key. The practical question is therefore how long today’s signatures need to remain trustworthy.

That flips the question from “how much data have I already leaked” to “what am I signing today that still has to be trusted in 2040?” A TLS handshake signature: nothing. A firmware image in a device with a fifteen-year field life: everything.

Which turns into an actual date

The standard tool is Mosca’s inequality, usually written for confidentiality:

x + y > z → you’re already late
x = how long the data must stay secret
y = how long your migration takes
z = time until a cryptographically relevant quantum computer

For signatures, swap x for v, the verification lifetime: how long must a signature you make today still be trusted by somebody?

v + y > z → migrate now

Plug in real cases (taking z ≈ 10 years — a guess, but the ranking barely moves at 8 or 15):

What you’re signing v y Verdict
TLS handshake signature seconds 2 2 < 10 → ship it when convenient
90-day web certificate 0.25 2 2.25 < 10 → comfortable
Code-signing cert, 3-year artifacts 3 3 6 < 10 → start now, finish calmly
Firmware, 15-year field life 15 3 18 > 10 → already late

That table is the entire reason NSA’s CNSA 2.0 puts software and firmware signing on the earliest deadline in the whole suite — all deployed software and firmware on CNSA 2.0 signatures by 2030 — while web, cloud, and operating systems get until 2033. It isn’t that firmware matters more. It’s that v is enormous and you can’t re-sign a chip that’s already in a customer’s basement.

Two consequences to carry into everything below. First, for most signature use cases the honest answer is “not urgent,” and pretending otherwise burns credibility you’ll need for the cases that are. Second, the thing you migrate first is the verifier, not the signer — you cannot sign with ML-DSA until every relying party can verify it, so the work that starts today is shipping verification support and negotiable algorithm identifiers. Cheap, reversible, and the long pole. Signing flips over later.

Part one: the native world

Where signatures are verified on CPUs, travel once, and get thrown away — TLS, code signing, SSH, firmware, JWTs. What matters here: wire bytes, verification speed, and how much you trust the code saying “valid.”

The affordability rule — and its fine print

Peter Schwabe gave me the cleanest starting rule you’ll find anywhere:

If your application can happily afford SLH-DSA signatures, use them. If it can’t, ML-DSA is the obvious choice.

Simple. But every other expert added fine print to the word afford, and the fine print is where real decisions live.

Fine print #1: “afford” includes your verifiers, not just your bandwidth. Filippo Valsorda’s take was the most contrarian and, I think, the most underrated. Choosing SLH-DSA only makes sense if you have the same confidence in the SLH-DSA verifier implementations you’ll rely on as you’d have in the ML-DSA ones. And right now, for any open ecosystem, you almost certainly don’t.

Be precise about what’s missing, because two kinds of test vector get conflated. Conformance vectors for SLH-DSA exist — NIST’s CAVP/ACVP added external-interface testing in early 2025. What doesn’t exist is adversarial coverage: as of September 2026, Project Wycheproof’s published algorithm list includes ML-KEM and ML-DSA but not SLH-DSA. Conformance vectors tell you an implementation agrees with the spec on well-formed inputs; Wycheproof-style vectors catch the edge cases attackers actually use. Filippo’s conclusion: when verifier confidence is that asymmetric, the risk of a verifier bug dominates the risk of lattice cryptanalysis — which quietly inverts the whole “SLH-DSA is the safe choice” intuition. The scheme with the more conservative math can be the less conservative system.

Two caveats, pointing in opposite directions.

Peter’s, when I put it to him: fair point, but implementation maturity is a today problem, and he’d hesitate to lock a decade-scale architectural decision to the temporary absence of test vectors. Both can be true — so the answer depends on whether your decision is reversible.

Mine: date-stamp this one, because it is moving fast. Go 1.27 shipped in August 2026 with a crypto/mldsa package implementing FIPS 204, wired into crypto/x509 and crypto/tls — and Sigstore had made “a trusted implementation in Go’s standard crypto packages” an explicit precondition for adopting post-quantum signing at all. One release closed that gate for a large chunk of the software-supply-chain ecosystem. Wycheproof coverage for SLH-DSA could land the same way, any quarter. If verifier asymmetry is the load-bearing argument for your decision, re-check that it’s still true on the day you decide.

Fine print #2: “afford” includes the rest of your protocol. Bas Westerbaan’s argument attacks the framing at the system level. Say you pick SLH-DSA for its conservative security, but your system touches TLS anywhere. TLS security doesn’t rest on certificates alone — it rests equally on the key agreement, and there is no hash-based key agreement. Post-quantum key exchange means ML-KEM, which means lattices. So if you need TLS to be secure, you are already trusting lattice assumptions, and paying SLH-DSA’s cost on the signature side buys you strictly less than you think. His one-scheme-for-a-decade answer, delivered with zero hedging: ML-DSA-44.

Peter’s counterpoint: trusting ML-KEM is subtly different from trusting ML-DSA — the assumptions are cousins, not twins, and the gap gets less subtle when you look at implementation security. And he offered what might be the single most useful exercise in this guide:

The break drill. Ask what happens to your system if ML-KEM falls and TLS migrates to a backup KEM (like HQC, the structurally independent code-based KEM NIST selected in March 2025) — versus what happens if your signature scheme falls. Key agreement is ephemeral: rotate and move on. Signatures are often not: do you still need to trust things signed years ago? Firmware in the field? Can you re-sign everything you’ve ever issued?

Run that drill and the real question was never “which math do I trust more.” It’s “which of my signatures can I take back?” Encryption failures are recoverable; signature failures on long-lived artifacts often aren’t — the legitimate core of the hash-based case, and the same clock from the orientation section pointed at your specific system.

Where SLH-DSA actually earns its cost

Put the arguments together and SLH-DSA’s honest niche is narrow but real: long-lived, hard-to-replace trust anchors with low signing frequency and a closed verifier ecosystem.

Thom Wiggers pointed at the canonical example: firmware updates. Low-frequency (signing cost is irrelevant), high-impact, and — the key phrase — a context where cryptographic agility is genuinely difficult. You can’t hot-swap the verification key baked into a chip’s ROM. When you can’t change your mind later, you pay for the most conservative assumption available, and you check Filippo’s box because you control (and can exhaustively test) the one verifier that matters.

You don’t have to take the experts’ word for this one, because a government wrote it down.

CNSA 2.0 makes the split official

Scope first, because this is easy to over-generalize: CNSA 2.0 is NSA guidance for National Security Systems, not a rule for commercial software. If you’re not building for NSS, none of the deadlines below bind you. What makes it worth reading anyway is that it’s the best-documented public reasoning about why one signature category splits off from all the others.

CNSA 2.0 is usually cited as a vote for lattices, and for general-purpose signatures it is: ML-DSA-87, the highest parameter set, for all classification levels. But the suite carves out one exception, exactly the one this section just argued for. For software and firmware signing, CNSA 2.0 specifies the stateful hash-based schemes LMS and XMSS (NIST SP 800-208), with the most aggressive timeline in the document. NSA’s own wording: software and firmware signing should begin transitioning immediately; new software and firmware should use CNSA 2.0 signing algorithms by 2025; all deployed software and firmware should be on CNSA 2.0-compliant signatures by 2030. Separately, new NSS acquisitions must be CNSA 2.0-compliant from January 1, 2027.

That is the thesis of this guide, in an official publication, from the agency that also blessed lattices for everything else. NSA didn’t pick a side. It picked per use case.

Three details keep this honest, because the guidance has moved:

Even here, there’s a catch. Thom cautioned that secure boot may be the exception: a small chip has to check a signature in milliseconds every time it powers on, and SLH-DSA’s standard settings can be too slow for that. Which pushes people toward the one family this guide has been carefully avoiding.

The hybrid question: paying once or paying twice

While we’re in CNSA 2.0, it’s worth surfacing a disagreement this guide would otherwise paper over. The standard advice is hybrid now, pure post-quantum later — classical plus PQ, valid only if both verify. Peter recommended it emphatically: a lattice break doesn’t hurt you today, and a quantum computer doesn’t either. Cheap insurance against a young assumption.

NSA’s FAQ argues the opposite, and the reasoning is worth reading rather than dismissing. Hybrid deployments introduce additional interoperability concerns, because the algorithms and the method of hybridization must be common to all parties; they add a second transition later, as users eventually move off classical algorithms entirely; and they make implementations more complex, so you must balance the risk of flaws in an increasingly complex implementation against the risk of a cryptanalytic breakthrough — noting that more security products fail due to implementation problems. NSA permits hybrid for interoperability or technical constraints — IKEv2’s public-key size limits are the example — but doesn’t require it for security.

If that sounds familiar, it should: it’s Filippo’s verifier-confidence point aimed at hybridization instead of at SLH-DSA. Same shape, same conclusion — the more conservative-looking choice can be the less conservative system.

Note that NSA’s timeline is still staged: hybrid is tolerated through the transition, with standalone CNSA 2.0 required by the exclusive-use dates. They aren’t arguing against phasing, but against phasing that costs you two migrations instead of one.

So “migrate now, go fully PQ later” is good advice with a hidden invoice, and the useful version names it:

  • Encryption: no staging question. The deadline is in the past. Hybrid key exchange is already the default in mainstream stacks — Go has had ML-KEM on by default in TLS since Go 1.24. If it isn’t on, the answer is today.
  • Signatures: staging is legitimate, per the v + y > z table — but decide deliberately whether you’re paying Peter’s cost (bytes and a second transition) or NSA’s (exposure to a young assumption, single clean migration). Both are defensible. Drifting into hybrid because it’s the default advice, then discovering in 2032 that you have to do it all again, is not.

The stateful trap

Behind that door: XMSS and LMS, the stateful hash-based schemes. Smaller signatures than SLH-DSA, faster, same conservative security — and, per CNSA 2.0, the mandated choice in exactly the secure-boot niche above. The catch: the signer must never, ever reuse a one-time key. Use the same leaf twice and an attacker can likely forge signatures on arbitrary messages. Your key’s security now depends on a counter surviving backups, restores, VM snapshots, and HSM cloning — forever.

Peter told me a story that should give anyone pause. He used to think smartcards and HSMs were the obvious safe home for stateful schemes — secure hardware can surely keep a counter. Then he talked to people who actually build the hardware, who told him that maintaining a counter against a malicious adversary is hard. Really hard. His revised position: the only setting where he’d recommend XMSS/LMS is when you need forward-secure signatures — because then you’re forced to keep state anyway, so the marginal footgun is already priced in.

Thom, who co-authored the IETF’s guidance on hash-based signature state management (draft-ietf-pquip-hbs-state), called the state “such a huge footgun” that he hates recommending the schemes even for the secure-boot deployments where they’re standard practice. When the person who wrote the safety manual winces at the product, believe the wince.

(File this away — statefulness comes back in Part Two with a twist.)

FN-DSA: the compact one you can’t have yet

FN-DSA (Falcon) looks like a cheat code on paper: 666-byte signatures, 897-byte keys, faster verification than ML-DSA. Two problems.

First, it’s not done. NIST submitted the draft standard for approval on August 28, 2025; FIPS 206 remains in review with final publication expected late 2026 or early 2027 — and only then does the pipeline of protocol integration, library support, and validated modules start. Cloudflare’s estimate is that FN-DSA won’t be widely usable before the early 2030s; DigiCert has said it won’t implement FN-DSA in production until the standard is finalized, having been burned by the naming and OID churn between draft and final on ML-DSA.

Second, the signing path is genuinely treacherous. FN-DSA’s Gaussian sampler naturally wants floating-point arithmetic — a first for a crypto standard, and a nightmare for constant-time guarantees: an implementation that’s side-channel-safe on one CPU may leak on another. That difficulty is the stated reason FIPS 206 lagged the other three standards, and the sampler is still an active optimization target in 2026 research. Peter called the floating-point reliance a show-stopper for many applications, while conceding the tiny sizes may make it the only feasible option for a few others. Thom’s framing was the same trade-off in different words: efficient lattice schemes exist beyond ML-DSA, but they carry side-channel sensitivity that may or may not be easy to mitigate in your application.

Rule of thumb: Falcon, the pre-standard ancestor of FN-DSA, is a plan-and-test algorithm, not a deploy algorithm — and it makes a surprise appearance in Part Two, already live on a blockchain.

Sometimes the answer is: change the system

The most reframing thing anyone said to me came from Thom: for some applications, there is no good route to post-quantum security without significant re-architecting. The signature-picker mindset assumes the system stays fixed and you swap the primitive. Increasingly, the winning move is the opposite.

Exhibit A: the WebPKI. A classical TLS handshake carries five or six signatures and a couple of public keys; swap them all to ML-DSA and you add roughly 15KB to every connection. Rather than eat that, the ecosystem is rebuilding the certificate layer itself. Merkle Tree Certificates (MTC) let a CA batch many certificates into a Merkle tree and sign only the root; a browser then verifies a short inclusion proof instead of a chain of heavyweight signatures. The design now has its own IETF working group — PLANTS (PKI, Logs, And Tree Signatures), spun out of a secdispatch session at IETF 123 — with the spec at draft-ietf-plants-merkle-tree-certs.

It is not a paper design anymore. Cloudflare and Chrome are running a feasibility experiment against real internet traffic, and Chrome has named MTCs its preferred path for post-quantum certificates on the public web. And on June 3, 2026, Let’s Encrypt committed to MTCs as its post-quantum path, targeting a staging environment in late 2026 and a production-ready environment in 2027.

The delightful part: Bas and Filippo — the two loudest ML-DSA advocates in this guide — are both on the MTC author list, alongside David Benjamin, Devon O’Brien, and Luke Valenta. That’s not a contradiction; it’s the playbook. Deploy ML-DSA where signatures must live, and where its size hurts, restructure the system around hash trees so you need dramatically fewer signatures.

Thom pushed me to see MTC as more than a size hack — a from-scratch rethink of WebPKI roles that fuses issuance with transparency logging — and pointed at Signal’s SPQR ratchet as the same philosophy under harsher constraints: a deployable design beats a pure one. His line deserves to be the thesis of the whole migration:

Only cryptography that is deployed gives security. Deployable PQC is much better than inaction or impracticality.

Hold onto “change the system” — Part Two is what happens when an entire ecosystem takes that advice to its logical extreme.

Part two: the proven world

Where signatures live forever, arrive in crowds, and increasingly get verified inside cryptographic proofs instead of on CPUs. Ethereum looked at the same three schemes — and is walking the other way.

Three facts that flip the table

1. Signatures are stored forever, by everyone. A TLS signature crosses the wire once and is discarded. A blockchain signature is written into a block that every node stores permanently. An Ethereum transaction today is on the order of 110 bytes including its ~65-byte ECDSA signature; swap in ML-DSA’s 2,420 bytes and each transaction is over 20x bigger — far fewer fit per block, throughput drops, fees rise. The 2.4 KB that’s a rounding error on a TLS handshake is an existential number on a chain.

2. Public keys stop being free. Today’s Ethereum leans on an ECDSA quirk: key recovery. An Ethereum transaction carries no public key at all — the verifier mathematically recovers it from the signature (ecrecover). No standardized post-quantum signature scheme in the ML-DSA/SLH-DSA/FN-DSA families supports public-key recovery like ECDSA; lattice and hash-based verification both need the key as an input. So a post-quantum chain must deliver the key somehow — carried in the transaction, or stored once on-chain. And now that pocket asymmetry matters: when the key travels with every signature, the honest unit is signature + public key, and hash-based schemes’ 32-byte keys claw back most of their deficit.

3. Signatures arrive in crowds. Ethereum’s consensus layer is a large signature system, and it only works because BLS signatures aggregate — thousands of validator signatures compress to about 96 bytes on BLS12-381. No standardized post-quantum scheme has anything like that. Ethereum’s own EIP text puts current hash-based proposals at roughly 2–3 kB per signature and 150,000–200,000 gas to verify — which, multiplied across a slot’s worth of attestations, is more data than the network can gossip in time. For a proof-of-stake chain, aggregation isn’t an optimization. It’s existence.

How Ethereum’s public roadmap answers

The official post-quantum roadmap lays out a layered plan:

Consensus: hash-based signatures plus proof-based aggregation. The validator scheme becomes leanXMSS — an XMSS-family, hash-based scheme — with aggregation solved by a purpose-built minimal zkVM. As EIP-8292 describes it, post-quantum consensus performs attestation aggregation by generating a succinct proof that many validators’ signatures are valid, using a specialized minimal virtual machine; because producing such proofs is far more expensive than BLS’s elliptic-curve addition, the work is split off to an opt-in, higher-specification aggregator role. The authoritative definitions live in the PQ consensus specification, leanSpec. The scheme has a peer-reviewed foundation (Hash-Based Multi-Signatures for Post-Quantum Ethereum) and a draft keystore standard (EIP-8310).

Note what just happened, given Part One: Ethereum chose a stateful scheme — the family the native world treats as a footgun. It’s the same carve-out CNSA 2.0 made, for the same reason. Validators are professional operators with managed infrastructure and naturally sequenced signing — about the only environment where keeping a counter is survivable. The keystore EIP exists precisely to make that state handling a standard rather than an accident, the blockchain equivalent of SP 800-208’s “you must manage state” clause.

Execution (your transactions): deliberately scheme-neutral. Rather than pick a signature for every wallet, the roadmap routes user migration through account abstraction — programmable smart-wallet validation plus planned precompiles for post-quantum verification, so users opt in gradually, no flag day. For the endgame, EIP-8288 (first proposed June 3, 2026) adds block-level aggregation: transactions declare (scheme, data_hash, verification_key_hash) dependency triples, which are aggregated off-chain into a single recursive STARK that proves the validity of all dependencies in all transactions. Two things worth noticing. It is scheme-agnostic by construction — scheme is a parameter, not a choice baked into the EIP. And it keeps aggregation at the mempool and block-builder layer rather than in consensus, which is what lets it ship without a simultaneous all-node upgrade. If it lands, per-transaction signature size eventually stops mattering at all.

Falcon is already in production — on Algorand

This is the single most useful data point in the whole guide, because it’s the only NIST-selected post-quantum signature scheme with a real chain deployment to study. The details matter, and they aren’t quite what a summary would guess:

One ecosystem is not “blockchains”

Everything above is Ethereum, and Ethereum’s answer falls out of its constraints: a consensus layer that must aggregate or die. Generalize carelessly and you’ll get the next chain wrong. Bitcoin is the counterexample, instructive in three ways.

It declined to answer the question. BIP-360 started life in June 2024 as P2QRH (“Pay to Quantum Resistant Hash”), bundling four post-quantum signature algorithms into a new output type; v0.6.0 in January 2025 dropped SQIsign over verification cost, and by v0.8.0 in July 2025 all PQ signatures had been stripped out entirely and deferred to a future companion BIP. What merged into the official BIPs repository on February 11, 2026 is Pay-to-Merkle-Root (P2MR): an output type committing only to the Merkle root of a script tree, with the post-quantum public key exposed only at spend time and only within the witness data.

Which is the “change the system” move again. Bitcoin’s first quantum BIP doesn’t pick lattice or hash. It restructures the output so the public key stays hidden — attacking fact #2 above rather than fact #1 — and keeps the algorithm slot open. Same playbook as MTC, same playbook as proof aggregation.

And there’s no aggregation story, so the byte math is the native world’s math. BIP-360 defines the output type and does not prescribe a single post-quantum signature algorithm; ML-DSA, FN-DSA, SLH-DSA, and a Bitcoin-native hash-based family from Blockstream Research are all in contention. The stakes are concrete: roughly 6–7 million BTC, about 30–35% of circulating supply, sit in addresses whose public keys are already exposed on-chain, which is why a companion proposal, BIP-361, specifies a pre-announced sunset of legacy ECDSA/Schnorr spends.

So the “great split” isn’t internet-versus-blockchain. It’s a function of two inputs, and Bitcoin happens to sit closer to the native world on both.

The size argument, finally settled

Both worlds claim the size advantage, and both have real numbers. The resolution: there are three legitimate ways to count, and each crowns a different winner. Row two uses the EF’s leanSig figures, the scheme Ethereum’s lean stack — and EIP-8288’s aggregation — is built around.

How you count The numbers (~128-bit security) Winner Whose world
Signature alone (verifier already holds the key) ML-DSA-44: 2,420 B vs SLH-DSA-128s: 7,856 B Lattices ~3x (Falcon-512 ~12x) TLS, firmware, SSH, registries
Signature + public key (key travels every use) ML-DSA-44 pair ~3.7 KB vs (leanSPHINCS ~2–3 KB or leanSig ~1.2 KB) +32 B key hash Hash-based, 1.3–3x* PQ transactions, consensus
Per signature, after proof aggregation one recursive STARK per block → bytes each Hash-based, by default Consensus, rollups, in-circuit

* Read row two carefully. The parity holds at the ~128-bit level chains actually run, and against tuned, non-standard hash constructions. Bounding how many times a key may sign shrinks hash-based signatures dramatically — an established dial. Kölbl and Philipoom’s “A note on SPHINCS+ parameter sets” explores parameter sets supporting fewer than 2^64 signatures but otherwise compatible with the SLH-DSA spec; their proposal targets q = 2^20 (about a million signatures) for a >50% reduction in signature size, with very fast verification and very slow signing. In the follow-on NIST discussion of standardizing additional SLH-DSA parameter sets, the AAA-2 candidate lands at 3,264 bytes — 41.6% of FIPS 205’s 128s signature — at 128-bit security with a 2^20 signature cap. Two honesty notes: this is a candidate under discussion, not a standard, and Thom himself argued in that thread for AAA-3 instead — 3,280-byte signatures with 19x overuse protection and better verification efficiency, on the grounds that AAA-2’s extra 16 bytes of savings aren’t worth the reduced safety margin. Within FIPS parameter sets and at higher NIST levels, the gap reopens several-fold and the comparison is simply won by ML-DSA. Lattice schemes have off-catalog tuning room too, so this isn’t like-for-like so much as “what each family looks like when you leave the catalog.”

Why row three only works for hash-based, and this is the mechanism rather than a footnote: the aggregation proof runs verification inside a circuit, where cost is measured in constraints, not bytes. Hash chains are a few hundred cheap hash calls (when the hash is cheap in the proof field); lattice verification’s modular arithmetic is orders of magnitude more expensive to prove. And the gap is actively widening, because some proof systems are migrating to binary fields, where bit-oriented hashes become nearly native operations. So hash-based doesn’t just happen to be cheap in-circuit; the proof stack is being rebuilt around the assumption that hashing is the cheap thing.

So the claims were never in conflict: lattices have small signatures and large keys; hash-based has bulky signatures and tiny keys; aggregation makes both irrelevant. Which row you live in comes down to: does your verifier already hold the key, and do signatures arrive alone or in crowds?

What blockchains don’t get to skip

One thing the split does not change: Filippo’s implementation-confidence test. If anything, chains face a harsher version. In TLS, a verifier bug breaks a connection; on a chain, signature verification is consensus — every node must reach the bit-for-bit same verdict, or the chain forks. No forgery needed: a mere disagreement between two mostly-correct implementations is enough. Bitcoin had to pin down strict encoding rules (BIP66) because OpenSSL versions disagreed on edge cases; Zcash wrote a whole spec (ZIP-215) just to define which Ed25519 signatures count, because the “same” scheme had different acceptance rules across libraries.

The chains’ answer isn’t to wave the problem away — it’s to pay the bill in-house. Ethereum deployed BLS, which also never had Wycheproof-style vectors, by building its own: consensus spec tests every client must pass, plus differential fuzzing between implementations. The lean stack repeats the pattern — an executable spec with test-vector generation, multi-client devnets, formal verification of the proof machinery on the long-term roadmap. Whether that in-house bill gets paid fully, for a scheme this young, before real value sits on it — that’s the open question this article ends on.

The border, drawn in one paragraph

Everything above compresses into two questions, for any system:

Where does verification happen? On a CPU → wire bytes and verifier maturity rule; the native world’s logic applies, and lattices are the strong default. Inside a proof circuit → constraints rule, hashing is cheap, and hash-based wins even for a single signature.

Does the verifier already hold the key, and do signatures come alone or in crowds? Key stored + solo signatures → compare signatures only (lattices shine). Key travels → compare pairs (near parity). Crowds everyone re-verifies → aggregation is mandatory, and only hash-based rides the proof.

Run those two questions and the split stops being a controversy: the internet answered for CPUs, sparse signatures, and held keys; Ethereum’s consensus layer answered for circuits, crowds, and traveling keys; Algorand uses Falcon, which is lattice-based, but with registered keys and no aggregation. Bitcoin’s BIP-360, as described, is deliberately scheme-neutral and has not picked lattice or hash. Everyone did the same math on different inputs. The only real mistake available is importing an answer across the border without checking which side you’re on — and I say that as someone who did exactly that, in a meeting, out loud.

The decision framework

Suggestions with reasons, not commandments:

Native-world default: ML-DSA-44, today. Final, fast, robustly implemented, verifier-hardened, and “not too large” (Thom). If your protocol lives anywhere near TLS, Bas’s argument applies: you’re trusting lattices via ML-KEM regardless. If you want more than category-2 margin, that’s what ML-DSA-65 and -87 are for.

Hybridize with Ed25519 — if you’ve priced the second migration. Peter’s emphatic recommendation, and the industry default. NSA’s counterargument is that hybrid buys insurance by adding implementation complexity and a second transition later. Pick a side on purpose; don’t inherit one.

Sequence verifiers before signers. Verification support and negotiable algorithm identifiers ship today, everywhere, regardless of which scheme you land on. Signing flips when the relying parties are ready. This is the long pole in every signature migration, and the part you can start before you’ve decided anything else.

Long-lived, rarely-signed, hard-to-replace anchors: SLH-DSA — if verification performance fits and you control the verifier well enough to pass Filippo’s test (verifier-confidence check, checked on today’s date, not a constant factor). Run Peter’s break drill: these are the signatures you can’t take back.

Software and firmware signing: check CNSA 2.0 — and check whether it applies to you. For National Security Systems the choice is made: LMS or XMSS under SP 800-208, single-tree only, state managed and signing in hardware, deployed artifacts due by 2030. If you’re not, none of that binds you — but it’s still the best-documented public reasoning for why this category splits off. Note v2.1 also approves ML-DSA here, with LMS/XMSS preferred near-term largely on implementation availability.

Other stateful niches: XMSS/LMS only with eyes fully open — state management is the project, not a detail of it. The two environments where the public record shows statefulness working as a plan are NSS firmware signing under a standard that mandates hardware state, and professional validator infrastructure with a standardized keystore. Consumer wallets are neither.
LeanSphincs for safer state management and user accounts.

Byte-starved native applications: FN-DSA eventually, if you control the signing environment; plan and prototype now, deploy after FIPS 206 finalizes and hardened implementations exist. Algorand shows it can be done — with the higher Falcon-1024 parameter set, a controlled verifier, and a pre-standard implementation you’d have to migrate again later.

On-chain, per-transaction, verified natively (before native aggregation): small lattice signatures are the honest interim answer, gated by the same maturity test as everywhere else, doubly so when the verifier is consensus-critical.

Anything verified inside proofs, or arriving in crowds: hash-based — and the interesting design work is which: bounded-use and one-time constructions get dramatically smaller when the application already enforces single-use, precisely the trick the parameter-tuning literature exploits.

Restructuring is a first-class option — in both worlds. MTC, proof aggregation, and Bitcoin’s P2MR are the same move wearing three sets of clothes. Check whether it removes your need before paying for exotic primitives.

And wire in agility everywhere — negotiable algorithm identifiers, replaceable trust anchors, rehearsed key rotation. As Bas noted, you need swappable trust anchors anyway because keys get compromised.

What agility buys you: the 2030 option

On May 14, 2026, NIST advanced nine candidates to round three of the additional-signatures (“onramp”) process via IR 8610: FAEST, HAWK, MAYO, MQOM, QR-UOV, SDitH, SNOVA, SQIsign, and UOV. Forty candidates entered round 1, fourteen advanced in October 2024, and nine are left; the third round is expected to last about two years.

Four things worth tracking:

None of them will be standardized before roughly 2028. Waiting for a better scheme is not a migration strategy.

One honest limit, courtesy of Michael Baentsch’s algorithm-neutral corner of this conversation: be suspicious of anyone (including this guide) ranking algorithms with too much confidence, and be careful what code you build on — research frameworks that run every candidate head-to-head are for experimentation, not production; for standardized algorithms, use hardened mainstream implementations. The gap between an algorithm’s spec and the code you actually ship is where most of Filippo’s argument lives.

The one-paragraph version

There is no lattice-vs-hash war; there are two territories with a border. Encryption’s deadline is already behind you and signatures’ is ahead, so ship verification support everywhere first and then let v + y > z tell you when each signer actually has to move. In the native world — signatures verified on CPUs and thrown away — ship ML-DSA now, hybridized if you’ve priced the second migration NSA warns about, because deployed cryptography is the only kind that protects anyone; reserve hash-based schemes for the signatures you can never take back, exactly the carve-out CNSA 2.0 already made for NSS firmware, and audit honestly whether your verifiers deserve the trust the math earns. In the proven world — signatures stored forever, traveling with their keys, verified inside circuits — the same math points the other way, toward hash-based schemes and proof aggregation, and Ethereum’s public roadmap already reflects it, while Bitcoin’s and Algorand’s lack of aggregation lands them back near the native answer. Treat FN-DSA and the onramp schemes as 2030’s upgrade, purchasable today only in the currency of crypto-agility. And when a signature doesn’t fit anywhere, remember the strongest move on the board: change the shape of the system so it needs fewer signatures. Both worlds are already doing it, with the same hash trees. The people building the post-quantum internet aren’t picking a side. They’re picking per system — and the clock they’re racing isn’t the quantum computer’s, it’s their own migration’s.

An open question to leave you with

Both worlds know implementation confidence has to come from somewhere. They’re buying it from different places.

The native world buys it with decades of adversarial test vectors, across a hundred independent libraries. The proven world plans to buy it with executable specs, differential testing between a few clients, and formal verification of small verifier components.

So: if a verifier is formally verified, how much testing does it still owe?

The classical answer is all of it — proofs and tests answer different questions. That lesson was paid for in bugs, like the all-zeros signatures that slipped past ECDSA code whose math was correct but whose range checks were missing. Knuth said it best fifty years ago: “Beware of bugs in the above code; I have only proved it correct, not tried it.”

The proof-centric world is betting that one small proven circuit, replacing a thousand verifiers, changes that math. One of these positions will look obviously right in ten years. Decide which side your system is on — before your users decide for you.

Special thanks to Peter Schwabe, Bas Westerbaan, Filippo Valsorda, Thom Wiggers, and Michael Baentsch for generously sharing their perspectives. Interpretations, and any errors, are mine. Figures verified September 2026.

Further reading
1 Like
3

Thank you for adding a summery.

1 Like