ML-DSA vs SLH-DSA: Choosing the Right PQC Algorithm for Blockchain
Detailed comparison of NIST-standardized post-quantum signature algorithms ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) with benchmarks, signature sizes, and blockchain-specific tradeoffs.
What Are ML-DSA and SLH-DSA?
ML-DSA (Module-Lattice Digital Signature Algorithm, defined in NIST FIPS 204) and SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, defined in NIST FIPS 205) are the two NIST-standardized post-quantum digital signature algorithms. Both are designed to resist attacks from quantum computers, but they use fundamentally different mathematical approaches and have very different performance characteristics.
Choosing between them is not a matter of "better or worse" — it is a matter of understanding the tradeoffs and selecting the right tool for your specific blockchain use case.
Algorithm Foundations
ML-DSA: Lattice-Based Cryptography
ML-DSA is based on the Module Learning With Errors (MLWE) problem, a hard mathematical problem in structured lattices. It was formerly known as CRYSTALS-Dilithium during the NIST standardization process. Lattice-based cryptography has been studied extensively since the 1990s and is considered to have strong security foundations.
SLH-DSA: Hash-Based Cryptography
SLH-DSA is based entirely on hash functions — specifically, it uses a hypertree of many-times signature schemes built from one-time signature primitives. Formerly known as SPHINCS+ during standardization, its security relies only on the properties of the underlying hash function (SHA-256 or SHAKE-256). This makes it the most conservative choice from a security assumptions perspective.
Head-to-Head Comparison
| Property | ML-DSA-65 | SLH-DSA-128s | ECDSA (secp256k1) |
|---|---|---|---|
| NIST Standard | FIPS 204 | FIPS 205 | Pre-quantum |
| Security Level | NIST Level 3 (192-bit) | NIST Level 1 (128-bit) | ~128-bit (quantum-vulnerable) |
| Public Key Size | 1,952 bytes | 32 bytes | 33 bytes (compressed) |
| Signature Size | 3,293 bytes | 7,856 bytes | 64 bytes |
| Key Generation | ~0.1 ms | ~0.5 ms | ~0.05 ms |
| Signing Speed | ~0.3 ms | ~50–100 ms | ~0.1 ms |
| Verification Speed | ~0.2 ms | ~2–5 ms | ~0.15 ms |
| Security Assumption | MLWE (lattice) | Hash function only | ECDLP (quantum-broken) |
| Quantum Resistant | Yes | Yes | No |
When to Choose ML-DSA-65
ML-DSA-65 is the recommended default for most blockchain applications. QuantumSafe uses ML-DSA-65 as its primary algorithm for the following reasons:
- Compact Signatures: At 3,293 bytes, ML-DSA signatures are less than half the size of SLH-DSA signatures. For blockchain transactions where every byte costs gas, this translates directly to lower transaction costs.
- Fast Signing and Verification: ML-DSA key generation, signing, and verification are all sub-millisecond operations. This is critical for real-time blockchain applications, high-throughput DApps, and batch processing.
- Higher Security Level: ML-DSA-65 provides NIST Level 3 security (equivalent to 192-bit classical security), compared to SLH-DSA-128s at Level 1.
- NIST's Primary Recommendation: NIST has designated ML-DSA as the primary standard for general-purpose digital signatures, with SLH-DSA as a backup based on different mathematical assumptions.
When to Choose SLH-DSA
Despite ML-DSA's performance advantages, SLH-DSA has unique properties that make it the better choice in specific scenarios:
- Maximum Conservative Security: SLH-DSA's security depends only on the collision resistance of hash functions — a well-understood property with decades of analysis. If a breakthrough were to weaken lattice-based cryptography, SLH-DSA would remain secure. This makes it ideal for long-term archival attestation and regulatory compliance.
- Tiny Public Keys: At just 32 bytes, SLH-DSA public keys are nearly identical in size to ECDSA keys. This is advantageous for on-chain storage where public keys are recorded permanently.
- Hedging Against Lattice Attacks: While no practical attack on MLWE is known, lattice cryptography is newer than hash-based schemes. Organizations that need to plan for a 30+ year security horizon may prefer SLH-DSA as a hedge.
Blockchain-Specific Considerations
Gas Costs and On-Chain Storage
On Ethereum, storing data on-chain costs approximately 16 gas per byte of calldata (post-EIP-4844). The cost difference between ML-DSA and SLH-DSA per signature:
| Algorithm | Signature + PubKey Size | Approx. Gas Cost (calldata) |
|---|---|---|
| ML-DSA-65 | 5,245 bytes | ~83,920 gas |
| SLH-DSA-128s | 7,888 bytes | ~126,208 gas |
| ECDSA | 97 bytes | ~1,552 gas |
ML-DSA-65 signatures cost roughly 33% less gas than SLH-DSA-128s on Ethereum. Both are significantly more expensive than ECDSA, which is why Layer 2 solutions and off-chain verification patterns are important considerations for PQC adoption.
Batch Operations
For applications that process many signatures (e.g., airdrop claims, DAO voting), ML-DSA's 100–300x speed advantage over SLH-DSA in signing operations makes it the clear winner. A batch of 10,000 signatures takes approximately 3 seconds with ML-DSA versus 500+ seconds with SLH-DSA.
The Hybrid Approach
For maximum security during the transition period, a hybrid approach combines ECDSA with a PQC algorithm. A transaction is signed with both ECDSA and ML-DSA (or SLH-DSA), and verification requires both signatures to be valid. This protects against both classical and quantum attacks.
QuantumSafe's Recommendation
For most blockchain developers, we recommend the following approach:
- Default to ML-DSA-65 for all new PQC key generation and signing operations. It offers the best balance of security, performance, and cost.
- Use SLH-DSA for long-term attestation where the signed data must remain verifiable for 20+ years and you want maximum conservative security assumptions.
- Implement hybrid ECDSA + ML-DSA during the transition period to maintain backward compatibility while building quantum resilience.
Ready to generate PQC keys? QuantumSafe supports both ML-DSA-65 and SLH-DSA through our API and SDKs. Get started free with 500 API calls/month.