NIST standardized a modified version of SPHINCS+ in 2024 as SLH-DSA in FIPS 205, short for Stateless Hash-Based Digital Signature Algorithm. Read on to learn how its hash-based parts fit together and why NIST treats it as a backup instead of the everyday default.
Built on hashes alone
SPHINCS+ is a hash-based digital signature scheme. Its security rests on preimage resistance and several related properties of its approved SHA-2 and SHAKE256 functions, as opposed to a number-theoretic or lattice problem. So, it stands on its own, apart from the other schemes, as long as the design and the code are sound.
Such narrowness is the appeal. Hash functions are among the most understood elements in cryptography, studied and attacked for decades. A quantum computer doesn't overturn that. The best-known quantum attacks provide generic speedups against hashes, such as Grover's algorithm for preimage search, and SLH-DSA's parameters are sized to retain their security margin against those attacks.
NIST standardized SPHINCS+ in August 2024 and published it as SLH-DSA. As with the lattice standards, the final version makes some technical changes to the original submission, and people use both names for it.
No state to lose
Hash-based signatures aren't new. Schemes like XMSS and LMS have been around for years, and they work well. But there’s a catch. They're stateful, which means whoever does the signing has to keep track of which one-time keys have already been used, usually with a counter that ticks up by one per signature.
Reusing a one-time key can leak enough information for an attacker to forge signatures, which puts that key at risk. If you lose track of that state or restore an old backup, you can undermine your own security without realizing it.
SPHINCS+ keeps no counter at all. Instead of tracking used keys, SPHINCS+ turns each message into a hash, and that hash chooses which key to use and where it sits in the tree. The choice looks random, but comes straight from the message, and the possibilities are so vast that two messages almost never end up in the same place.
Because that space is so massive and the keys tolerate a few uses each, the rare repeat still stays safe, so the signer never has to remember anything between signatures.
Having no state to keep is what makes SPHINCS+ a safer general-purpose choice. NIST still approves XMSS and LMS separately, for narrower settings that can manage their state safely. This convenience of going stateless costs you in size.
Stacking one-time keys
The starting point is a one-time signature. You reveal parts of a secret in a pattern the message decides, and that proves you held the secret. It only stays safe for a single use. SPHINCS+ uses a toughened version of that one-time signature called WOTS+.
One-time keys alone won't do, since you need to sign more than once, so SPHINCS+ arranges its WOTS+ keys into a virtual hypertree, layers of smaller hash trees stacked on top of each other. The keys and nodes get derived from compact seeds when they're needed, so the full tree is never stored or built.
To sign, SPHINCS+ first hashes the message down to a short fingerprint, signs part of that digest with a FORS few-time key, and then links the resulting FORS public key through the hypertree with a chain of WOTS+ signatures and Merkle authentication paths.
This chain ends at the root contained in the public key. A verifier reconstructs a candidate root from the signature and checks that it matches the public-key root. The signature carries the FORS material along with a WOTS+ signature and authentication path at each layer, which is what makes it so large.
Underneath, it’s hash-based operations all the way down.
FORS signs the message digest, then a hypertree links it to the public-key root. That whole bundle is the signature, hence the size.
Tiny keys, huge signatures
The two sizes pull in opposite directions. An SLH-DSA public key is tiny, 32 to 64 bytes depending on the security level, smaller than a lattice key. The signature is the opposite. It runs from about 7,900 bytes to nearly 50,000 depending on the parameter set, which makes it the largest of NIST's finalized general-purpose post-quantum signature standards by a wide margin.
SPHINCS+ pairs a tiny public key (32–64 B) with the largest signature of the bunch (up to 49,856 B). Log scale.
SPHINCS+ also lets you pick your poison between two flavors: ‘s' for ‘small’ and ‘f' for ‘fast’. The ‘s’ sets produce smaller signatures and sign slowly. The ‘f’ sets sign faster and produce larger signatures. Neither matches an elliptic-curve signature for size and speed at once, so SPHINCS+ asks the rest of the system to make room.
Kept in reserve
For most jobs, the lattice signatures win on size and speed, therefore SPHINCS+ isn't the everyday default. Its role is insurance. A breakthrough against the lattice assumptions behind ML-DSA or FN-DSA wouldn't automatically carry over to SLH-DSA.
Attacking SLH-DSA would instead require weakening the underlying hash assumptions themselves, or the construction and implementation built on them. NIST standardized it partly so the world has a signature resting on different math, and we cover the wider set in Post-Quantum Cryptography Explained.
Why chains often skip SPHINCS+
In crypto, SPHINCS+ is a backstop, held in reserve instead of used day-to-day.
A signature that runs tens of thousands of bytes is a hard sell on-chain. Every extra signature byte increases the data that has to be propagated and processed, and archival nodes may keep it indefinitely, so signatures taking tens of kilobytes would cut throughput and push up fees.
The signatures that guard wallets today, ECDSA and Schnorr, are still vulnerable to Shor's algorithm. The compact lattice signatures are among the leading replacements where signature size is the binding constraint. SPHINCS+ is usually too heavy for direct use in every transaction, though it keeps its value as a standards-level fallback if the lattice families ever falter.
qLABS uses the more compact lattice option. It describes itself as a quantum-native Web3 foundation, and it applies a post-quantum layer in qVAULT, a non-custodial vault that uses Falcon-based authorization. Falcon's signatures are far smaller than SLH-DSA's, though qLABS' public materials describe an integration layer around that signature instead of a bare Falcon signature placed on-chain.
qLABS listed qONE and HYPE as supported assets as of August 2026. The platform launched and promotes qVAULT and develops the qONE token. It also regularly publishes the L1 Quantum Vulnerability Index.
For this reason, qLABS has a commercial and reputational interest in the claims listed in this article, so do keep that in mind when reading them. Also, none of this constitutes financial advice.
FAQ
What is SPHINCS+?
SPHINCS+ is a post-quantum digital signature scheme whose security rests on hash-function properties, with no number-theoretic or lattice assumptions. NIST standardized it in 2024 as SLH-DSA. Its reliance on long-studied hash assumptions makes it the deliberately conservative option in NIST's post-quantum signature set, at the cost of large signatures and slower signing.
Is SPHINCS+ the same as SLH-DSA?
Effectively, yes. SPHINCS+ is the original name from the research submission, and SLH-DSA is the version NIST turned into an official standard in 2024, published as FIPS 205, its federal spec for this signature. This standard makes some technical changes, so an older SPHINCS+ build shouldn't be assumed to match it or be FIPS-compliant.
Why are SPHINCS+ signatures so big?
The size comes from its structure. A signature carries a bundle of one-time key data and hash paths through a large virtual tree, which is what lets a 32-to-64-byte public key authenticate a vast number of signatures. That design buys conservative, hash-only security, and the price is signatures from 7,856 to 49,856 bytes across the parameter sets.
Is SPHINCS+ quantum safe?
As far as anyone knows, yes, and it rests on exceptionally solid ground. No Shor-style attack applies, since SLH-DSA doesn't rely on factoring or discrete logs. Quantum algorithms can still speed up some attacks on hashes, but the approved parameter sets are sized to cover the most-recognized classical and quantum attacks. This reflects what cryptanalysis shows today, and it stops short of proving the existence of any future attack.
Why did NIST standardize SPHINCS+ alongside the lattice schemes?
As insurance. Its security rests on completely different math, so an attack that weakened the lattice signatures wouldn't automatically weaken SLH-DSA. NIST wanted a fallback that the same breakthrough couldn’t take down.
qLABS Editorial. Sources are linked inline. See the L1 Quantum Vulnerability Index for our full methodology and conflict-of-interest disclosure.
-1-600x290.jpg)
