What ML-DSA and SLH-DSA Are Designed For
NIST standardised two signature schemes with very different design goals. ML-DSA is the general-purpose workhorse; SLH-DSA is the conservative fallback. Knowing which fits which job matters more than the names.
- Reading time
- 8 min read
- Last reviewed
- 1 Oct 2026
ML-DSA: the general-purpose choice
ML-DSA (FIPS 204) is built on the Module Learning With Errors problem over structured lattices. It comes in three parameter sets, ML-DSA-44, ML-DSA-65 and ML-DSA-87, targeting NIST security categories 2, 3 and 5. NIST and most guidance treat category 3 (ML-DSA-65) as the sensible default.
Its appeal is balance: key generation, signing and verification are all fast in optimised implementations, and sizes, while large compared with Ed25519, are manageable for most server-side and desktop use. It is the scheme most likely to appear in certificates, software signing and protocol handshakes first.
SLH-DSA: the conservative choice
SLH-DSA (FIPS 205) is a stateless hash-based signature scheme. Its security depends only on the properties of the underlying hash function (SHA-2 or SHAKE), which are among the most studied assumptions in cryptography. There is no lattice structure that a new mathematical insight could unravel.
The cost is size and speed. Signatures range from about 7.8 KB to nearly 50 KB, and signing with the small ('s') variants can take hundreds of milliseconds in software. The 'f' (fast) variants trade larger signatures for quicker signing. For that reason SLH-DSA is positioned for use cases where signatures are produced rarely and verified often: firmware, root certificates, long-term archives and other roots of trust.
Choosing between them
The question is rarely 'which is more secure' and more often 'what is the shape of the workload'. A system that signs millions of small messages wants ML-DSA. A system that signs a handful of high-value artefacts and must still be trustworthy decades from now might prefer SLH-DSA or use both.
Some deployments carry both a lattice and a hash-based signature for critical artefacts, accepting the size cost in exchange for independence of assumptions.
- High volume, interactive, size-sensitive: ML-DSA-65 (or ML-DSA-44 when category 2 is acceptable).
- Rare signing, long-lived trust, tolerant of large signatures: SLH-DSA (choose 's' for size or 'f' for signing speed).
- Maximum assurance on critical roots: consider both, or a hybrid with a classical scheme.
What this means for blockchains
Neither scheme fits inside today's compact transaction formats without protocol changes. ML-DSA is the more plausible candidate for transaction signing because of its size and speed, but even ML-DSA-44 exceeds Solana's 1,232-byte transaction limit on its own. Hash-based schemes are more plausible for infrequent, high-value operations such as validator identity, upgrade authorities or recovery mechanisms.
This is an area of active research and experimentation rather than settled practice. Community prototypes have explored hash-based one-time signatures at the program level; these are valuable experiments, not production patterns.
Practical implication
- Default to ML-DSA-65 for general-purpose signing experiments unless there is a specific reason not to.
- Reserve SLH-DSA for rare, high-value signatures where size is acceptable.
- When prototyping on Solana, treat both as application-level experiments that must fit within existing byte budgets.
Limitations
- The Lattice playground uses a pure-JavaScript implementation that does not claim constant-time behaviour. It is suitable for learning, not production signing.
- FN-DSA (Falcon) is not covered here because its standard was not final at the time of review.
Sources
- [1]FIPS 204: Module-Lattice-Based Digital Signature Standard (opens in a new tab) · NIST
- [2]FIPS 205: Stateless Hash-Based Digital Signature Standard (opens in a new tab) · NIST
- [3]noble-post-quantum: auditable JavaScript implementation used by the Lattice playground (opens in a new tab) · Paul Miller