Lattice-Based vs Hash-Based Signatures: Which is Better for a Blockchain?

Pick any post-quantum chain, and you’ll hit the same fork pretty quickly. Signatures come in two families, lattice-based and hash-based, and the forums treat it like a contest.

Which one’s better? For lattice-based vs. hash-based signatures, it comes down to how often the key signs. A wallet that signs all day needs something small and quick. A treasury key that signs twice a year and has to stay safe for decades can afford to be big and cautious. Plenty of setups need both. ARMchain supports both, on different kinds of accounts.

ML-DSA Rests on Lattices, SLH-DSA Rests on a Hash Function

ML-DSA is the lattice one. It’s FIPS 204 now, and older posts still call it CRYSTALS-Dilithium. Its security comes from lattice problems. People have studied those for decades, though not for as long as hash functions, which have been around since the 1990s.

SLH-DSA is the hash one, FIPS 205, formerly SPHINCS+. It builds a signature out of a hash function and nothing else. If the hash holds up, the signature holds up. That’s why people call hash-based signatures the cautious choice, and Ledger’s CTO Charles Guillemet makes the same point: with SPHINCS+, developers don’t have to trust a new hardness assumption. 

Both came out of the NIST competition that began in 2016. NIST, the US National Institute of Standards and Technology, published them in August 2024, alongside the ML-KEM key-exchange standard.

SLH-DSA Signatures Run From About 8 KB to 50 KB

Size bites first on a blockchain, because every node stores every byte. The table uses sizes from the Project Eleven registry and the ARMchain documentation.

SLH-DSA comes in 12 parameter sets. Each has an “s” version with small signatures and slow signing, and an “f” version that signs faster and produces bigger signatures. The gap is obvious once you look. The smallest SLH-DSA signature size plus its key is a little over twice what ML-DSA-44 needs, and the biggest is more than thirteen times as large.

One thing softens it a bit. ML-DSA can’t recover a public key from a signature, so the key rides along with every transaction. That’s how a simple ARMchain transfer ends up around 3,930 bytes, against roughly 110 for ECDSA. A hash-based public key is only 32 to 64 bytes, so with those schemes you’re paying almost entirely for the signature.

Why XMSS Needs a Counter, and SLH-DSA Does Not

Not all hash-based schemes work alike. XMSS is stateful. Every one-time key signs exactly once, so whoever holds it has to keep a counter and never reuse an index. Reuse one and the security is gone. A professionally run validator can manage that. A smart contract or an automated service probably can’t, at least not without losing sleep over it. SLH-DSA is stateless, so there’s no counter at all. That was QRL’s reason for moving its Zond project toward SPHINCS+. You pay for it in signature size. If you’re looking for stateless hash-based signatures for a chain, SLH-DSA is what you’re looking at. 

SLH-DSA Is Slow to Sign and Cheaper to Verify

SLH-DSA signs slowly, particularly in the small-signature versions. Verifying it is more reasonable. ML-DSA is quick at both. A hot wallet signing every few seconds will notice the slowness. A treasury key signing once a month won’t. A service signing thousands of times an hour definitely will. A chain adds another cost. Verifying inside a smart contract uses gas, and how much depends on the scheme, the parameter set and how the verifier is written. We’d measure the gas on your own account contract before picking a parameter set, because a table won’t tell you.

Matching Each Key to a Scheme: Wallets, Treasuries and Admin Keys

Here’s how it works out with some made-up numbers. Picture a custody setup with a hot wallet signing about 2,000 transactions a day and a cold treasury key that signs four times a month. On ML-DSA-44, the hot wallet adds roughly 7.5 MB a day of signature and key data, at 3,732 bytes each. Move that wallet to SLH-DSA-128s, the smallest hash-based set, and you’re at about 15.8 MB a day. That’s around 8 MB extra, every day. The SLH-DSA signature size is the entire cost of the switch. Now put the treasury key on SLH-DSA-256f, the biggest set. Four signatures a month come to about 200 KB, and nobody will ever notice. So ML-DSA vs SLH-DSA is rarely one choice for a whole system. The busy key and the rare key want different answers. These figures count only the signature and key, and a real transaction carries more.

What Buterin’s October Warning Means for ML-DSA

In October, Vitalik Buterin warned that AI-driven maths could put pressure on lattice schemes within about two years. Reports differ on how strongly he said it, and nobody has shown a break of ML-DSA. It did bring back an old argument for diversity, though. If lattice maths does take a hit, a key protected by a hash-based scheme isn’t exposed to it. Our longer take is in Can AI Break ECDSA or ML-DSA?

Using ML-DSA and SLH-DSA Side by Side on ARMchain

ARMchain is a Layer 1 that signs user transactions and validator messages with ML-DSA. It’s EVM-compatible, so your Solidity contracts carry over, and every transaction uses the Type 3 format, which carries the signature and public key together. Smart contract accounts can pick other validation schemes through account abstraction. SLH-DSA is one, so a treasury or admin account can run on the hash-based option while everyday accounts stay on ML-DSA. Passkeys and MPC for ECDSA are supported too, but neither is post-quantum. Custom validation logic has to be written in Yul, so budget for an audit. And check the documentation for which SLH-DSA parameter set an account can use before you size anything.

All of this happens at the account level. The base chain still signs with ML-DSA. Developers sign through ARMchain’s SDK, and a local Fakenet is the safest place to try both on your own contracts.

ML-DSA for Busy Keys, SLH-DSA for the Ones That Cannot Fail

There’s no defined winner in ML-DSA vs SLH-DSA. ML-DSA gives the keys that work hard small, quick signatures. SLH-DSA gives the few keys that can’t be allowed to fail a more cautious foundation. Deciding which to use on a chain you’re building? Get in touch with the ARMchain team.

FAQs

Is SLH-DSA the same thing as SPHINCS+?

Nearly. NIST made some small changes to SPHINCS+ and renamed it SLH-DSA in FIPS 205, so a library written to the original spec may not match the standard. Check which version your library implements, and search for both names.

Are hash-based signatures safer than lattice-based ones?

They rest on a simpler foundation, since SLH-DSA only needs its hash function to hold up. That’s why people call them more conservative. Neither family has a practical attack against it today, and a bug in your contract’s verifier will hurt either way.

Why are hash-based signatures so big?

SLH-DSA has no counter, so each signature carries the proof that its one-time key belongs under your public key. That proof is where the kilobytes come from.

Can one chain use both?

Yes. On ARMchain, standard accounts sign with ML-DSA and a smart contract account can use SLH-DSA through account abstraction. The validation logic is written in Yul, so get it audited. The base chain itself still signs with ML-DSA.

Will bigger signatures raise my fees?

Yes, since every signature is more data on the chain. Give SLH-DSA to the keys that sign rarely, like treasury and admin accounts, and keep busy accounts on ML-DSA.