# How to choose SPHINCS+ Parameters for blockchain

- URL: https://research.projecteleven.com/articles/how-to-choose-sphincs-parameters-for-blockchain
- Published: 2026-09-25
- Authors: Alessandro Baiocchi
- Categories: Cryptography, Hash-based

A brief discussion on what SPHINCS+ parameters mean and how to change them in a sensible way to make SPHINCS+ a viable cryptographic signature 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](https://csrc.nist.gov/pubs/fips/205/final) with some predetermined sets of parameters, which grant security at different [NIST security levels](https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization/evaluation-criteria/security-\(evaluation-criteria\)) 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^64` 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](https://csrc.nist.gov/pubs/sp/800/230/ipd) specifies six additional SLH-DSA parameter sets that trade the `2^64` capacity for a hard limit of `2^24` 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.

| Parameter  | Description                                           | SLH-DSA 128s value |
| ---------- | ----------------------------------------------------- | -----------------: |
| `n`        | Hash-output and tree-node size in bytes.              |         `16` bytes |
| `h`        | Total hypertree height.                               |               `63` |
| `d`        | Number of XMSS layers in the hypertree.               |                `7` |
| `h' = h/d` | Height of each XMSS tree.                             |                `9` |
| `K`        | Number of FORS trees opened for each message.         |               `14` |
| `A`        | Height of each FORS tree. Each tree has `2^A` leaves. |               `12` |
| `w`        | WOTS+ Winternitz parameter.                           | `16` (`log w = 4`) |
| `len`      | Number of hash chains in each WOTS+ signature.        |               `35` |

## 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`.

![NIST SPHINCS+ profile](https://research.projecteleven.com/images/sphincs-parameter-selection/nist-sphincs-plus.png)

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^64` signatures.

That is valuable when the signer must remain completely stateless and may sign
at an unknown scale for a long time, but `2^64` 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^64` 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^64`. The usage modality remains the same as normal SPHINCS+, with the chosen budget acting as a fixed capacity limit. Cutting that limit from `2^64` to, for example, `2^16`, `2^18`, or `2^19` 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^64`, 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

![Gas-saver profile](https://research.projecteleven.com/images/sphincs-parameter-selection/gas-saver.png)

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^18` 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

![Balanced profile](https://research.projecteleven.com/images/sphincs-parameter-selection/balanced.png)

This is a balanced option: `h = 20`, two XMSS layers, FORS+C
`K = 11, A = 13`, WOTS+ `w = 8`, and a `2^19`-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

![Fast signing profile](https://research.projecteleven.com/images/sphincs-parameter-selection/fast.png)

The fast profile optimises for signing latency: `h = 15`, three XMSS layers,
FORS+C `K = 25, A = 8`, WOTS+ `w = 8`, and a `2^16`-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.

## Using an asymmetrical hypertree

SPHINCS+ uses a symmetrical hypertree, which is not necessarily a constraint one has to follow. While it is true that having similar depth between levels gives the most favourable tradeoff between number of hypertree leaves and signature size, it also restricts `h` to be the product of `h' * d`, both integers. Values such as `h = 23` are impractical with a symmetrical hypertree, while are easy to obtain if levels have independent depths.
Furthermore, in more advanced scenarios, the first tree in the hypertree could be cached on the verifier, since it's a single tree that is used by all signatures. Having the possibility to tune that tree's depth independently allows for more freedom when optimizing a signature scheme to given constraints.

## 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.