How to choose SPHINCS+ Parameters for blockchain

In the context of post-quantum signatures, the hash-based family is one of the most established and well known. SLH-DSA, commonly known as SPHINCS+, is one of the most renowned members of that family in the context of blockchain signatures, as it is being evaluated as one of the possible replacements for elliptic curve signatures as Q-Day approaches.

SPHINCS+ has been standardized by NIST in FIPS-205 with some predetermined sets of parameters, which grant security at different NIST security levels and assure the stateless property of the signature through an enormous set of few-time signatures, namely Forest Of Random Subsets (FORS), big enough that collisions remain under the few-time budget of each FORS.

The parameter sets that are included in FIPS-205 are conservative choices that assure negligible degradation of the security for up to 2⁶⁴ signatures with the same key pair, which correspond to roughly 5 billion years of signing at a constant rate of a hundred times per second. This is obviously not needed by any reasonable use case in the context of blockchain signatures, and results in a signature larger than needed; while in other contexts this may not be relevant, in the context of blockchain transaction signatures this is extremely important, as signature size directly impacts the number of transactions that fit in a block and the compute time necessary for verification onchain is often far more expensive and constrained than offchain compute.

Since the standardization of SPHINCS+, NIST itself has considered additional parameter sets for different use cases: a public draft specifies six additional SLH-DSA parameter sets that trade the 2⁶⁴ capacity for a hard limit of 2²⁴ signatures per keypair, reaching 3,856 bytes at security category 1 against 7,856 for the smallest FIPS 205 set. They are explicitly not approved for general purpose use, and they are aimed at signing firmware, software and certificates, which are sign-once, verify-many workloads.

If we want to use SPHINCS+ in the context of blockchain transaction signatures, we need to consider replacing the standardized parameter sets with better suited ones, that cater to the needs of the specific use case they're needed for. We believe there is no universally best profile: a wallet that signs infrequently from a constrained device has different requirements from a high-throughput service, a smart-account signer, or a protocol where verification gas is the binding constraint.

In this article we're going to explore the SPHINCS+ parameters and some specific sets we found interesting to showcase as a demonstration of how large a difference parameter selection makes on the characteristics of this signature.

What each parameter is

The table uses the SLH-DSA-128s parameters as the reference. The s profile is the better baseline for this comparison because it is designed for smaller signatures: 7,856 bytes, compared with 17,088 bytes for 128f. The f profile instead prioritises faster signature generation.

Why the NIST Parameters Are Not Always the Answer

The NIST SLH-DSA/SPHINCS+ parameter sets are designed to be general-purpose, conservative, and stateless. While that is a sensible design goal, it is not automatically the most efficient one for every application.

Consider the familiar small-signature profile shown below: n = 16, hypertree height h = 63, seven XMSS layers, FORS K = 14, A = 12, and WOTS+ with w = 16.

It produces a 7,856-byte signature and, in our EVM measurements, costs roughly 361,000 gas to verify. The profile is engineered so a signer does not need to track a practical per-root usage budget, as the reuse budget is over 2⁶⁴ signatures.

That is valuable when the signer must remain completely stateless and may sign at an unknown scale for a long time, but 2⁶⁴ is an enormous budget, which many applications will not ever reach in their lifetime.

Of course the NIST parameters are not wrong, but they are meant to be a strong generic baseline. The point is that generic capacity has a price: longer authentication paths, larger signatures, and more expensive verification than many bounded-use applications need.

Make the Budget Explicit

The signature budget is where general-purpose SLH-DSA contains the most reducible slack. The NIST parameter sets are designed to remain secure for up to 2⁶⁴ signatures under one key: roughly 18.4 quintillion signatures. Even at ten billion signatures per second, exhausting that budget would take more than 58 years. For a wallet or application signer, that capacity is astronomically beyond any credible lifetime requirement.

Once the application has a realistic upper bound, the hypertree and FORS parameters can be selected for that bound rather than for 2⁶⁴. The usage modality remains the same as normal SPHINCS+, with the chosen budget acting as a fixed capacity limit. Cutting that limit from 2⁶⁴ to, for example, 2¹⁶, 2¹⁸, or 2¹⁹ signatures preserves far more capacity than most applications will use while enabling substantially smaller signatures, cheaper verification, or faster signing.

Three Profiles for Three Different Constraints

The diagrams below show three deliberately different parameter selections. All retain n = 16, and cut the signing budget significantly from the initial 2⁶⁴, but each spends its "optimization budget" differently on the other metrics. We highlight these three parameter sets because we believe they showcase three interesting use cases, but any parameter set is legitimate as long as it retains security and fits the necessary use case.

Gas Saver

The gas-saver profile uses a single XMSS layer, h = 18, with K = 7, A = 20 FORS+C and WOTS+ w = 8. It has an explicit root budget of 2¹⁸ signatures.

Its verification cost is about 68,700 gas and its signature is 3,028 bytes: both much smaller than the NIST-style profile. The trade-off is signing cost: generating the large FORS trees is expensive, around 112.6 million hash operations in our model.

This profile fits a setting where verification happens onchain and often, while signing happens offchain on powerful devices. Think service-operated accounts, batch authorizations, or protocols where execution gas is more expensive than signer CPU time.

Balanced

This is a balanced option: h = 20, two XMSS layers, FORS+C K = 11, A = 13, WOTS+ w = 8, and a 2¹⁹-signature root budget.

It verifies for roughly 94,700 gas, uses a 3,976-byte signature, and requires about 2 million hash operations to sign.

For a general smart-account wallet or application signer, this profile gives a large operating lifetime without treating a practically unlimited budget as a requirement. It is a reasonable middle ground when neither signer latency nor EVM gas dominates the design.

Fast signing

The fast profile optimises for signing latency: h = 15, three XMSS layers, FORS+C K = 25, A = 8, WOTS+ w = 8, and a 2¹⁶-signature root budget.

Signing takes about 63,700 hash operations in our model, dramatically less than the gas-saver and standard variants. The cost is paid by the verifier and the network: verification is roughly 144,800 gas and the signature is 5,804 bytes.

This is the right direction for interactive signing, constrained devices, or flows where a user must approve an action promptly, use cases where reducing signing latency is worth the larger proof.

What this means for blockchains

Using SPHINCS+ in the context of blockchain transaction signatures is not impossible, and doesn't have to be impractical. The standardized parameter sets are a conservative baseline, and we've seen that other parameter sets can be tailored to fit specific use cases. For this reason we believe it's best to leave room for operators to choose which parameter set suits their workload best. To do so, it is required to have a way to verify SPHINCS+ signatures onchain with different parameter sets: rather than deploying verification logic optimized for a single set of parameters, we should develop flexible verification logic capable of working with multiple predetermined sets and of supporting the addition of said sets.

There's also a possible downside of picking a niche parameter set: privacy could be harmed, as the chosen signature is publicly visible information tied to the user's transaction. If the chosen parameter set is used only by a handful of accounts, this information could be used to tie that transaction to that group of people.