# SPHINCS+ Parameter Explorer companion guide

- URL: https://research.projecteleven.com/articles/sphincs-parameter-explorer-companion-guide
- Published: 2026-11-01
- Authors: Alessandro Baiocchi
- Categories: Cryptography, Hash-based

A companion guide to the SPHINCS+ Parameter Explorer: understand its parameters, signature budget, hash costs and visualizations, then compare and share your own profiles.

---

Last week we released the [SPHINCS+ Parameter Explorer](https://research.projecteleven.com/tools/sphincs-parameter), a research tool that lets researchers and developers experiment with SPHINCS+ parameters and variants to better understand the benefits and trade-offs of each choice. With the explorer you can also compare your custom sets against existing, well-known sets, and share your parameters with others.

This article is a companion guide: it explains how to use the tool and what each parameter and visualization means.

## What is SPHINCS+?

SPHINCS+ is a stateless hash-based signature scheme, standardized by NIST as SLH-DSA in [FIPS 205](https://csrc.nist.gov/pubs/fips/205/final). Its security rests only on the hash function, which makes it one of the most conservative post-quantum choices. The price for this is size and compute: the standardized sets produce signatures of 7,856 to 49,856 bytes, and take 112k to 3.8M hash calls to sign and 3.9k to 17.5k to verify.

A signature combines two structures:

- A FORS few-time signature signs a digest of the message.
- An XMSS hypertree: $d$ layers of XMSS Merkle trees whose leaves are WOTS+ one-time keys. Each layer's WOTS+ key signs the root of the tree below it, and the root of the top tree is the public key.

To sign, the signer hashes the message together with a fresh randomizer R, the output splits into a $k \cdot a$-bit FORS digest and an $h$-bit leaf index. The index selects one of the $2^h$ FORS instances hanging below the bottom layer, and no state is kept between.

The FIPS 205 sets are sized for $2^{64}$ signatures per key. Draft [SP 800-230](https://csrc.nist.gov/pubs/sp/800/230/ipd) (April 2026) adds six sets limited to $2^{24}$ signatures, aimed at firmware, software and certificate signing. Even though this helps in many applications, blockchains have strict constraints that make additional work on these parameters required.

Our explorer tool helps by computing size, hashing cost and safe signature budget for any parameter set, so you can choose how to balance the tradeoff between different metrics.

## Parameters

### $n$: hash output size

The size in bytes of every hash output, and so of every element in a signature. It sets the security level: 16, 24 and 32 bytes for 128, 192 and 256 bits. Signature size grows linearly with $n$. Currently, most proposals target 128 bits of security, selecting $n = 16$.

### $w$: Winternitz parameter

The base in which WOTS+ encodes the value it signs, with one hash chain per digit. A larger $w$ means fewer, longer chains: smaller signatures, more hashing to sign and verify. FIPS 205 fixes $w = 16$.

### $h$: hypertree height

The total height of the hypertree, set in the tool as $h = h' \times d$, where $h'$ is the height of each XMSS tree. It gives $2^h$ FORS instances at the bottom, so a larger $h$ spreads signatures more thinly and raises the budget. Signing rebuilds one tree per layer, so its cost grows exponentially in $h'$.

### $d$: hypertree layers

The number of XMSS trees stacked between FORS and the public key. For a fixed $h$, more layers mean smaller trees and cheaper signing, but each layer adds a WOTS+ signature, meaning larger signatures.

### $k$: FORS trees

The number of Merkle trees in FORS; each signature opens one leaf in every tree. More trees strengthen the few-time signature and raise the budget, at the cost of a larger FORS section.

### $a$: FORS tree height

Each FORS tree has $2^a$ leaves, and $a$ bits of the message digest pick one. A larger $a$ strengthens FORS, but signing builds every leaf of every tree, so FORS cost doubles with each step.

### Signature budget

The budget is derived from $h$, $k$ and $a$, not chosen. With $q$ signatures spread uniformly over $2^h$ FORS instances, the probability that some instance used $r$ times covers a fresh digest is bounded by:

$$
\Pr[\text{forgery}] \le \sum_{r=1}^{q} \binom{q}{r} \left(\frac{1}{2^h}\right)^{r} \left(1-\frac{1}{2^h}\right)^{q-r} \left(1-\left(1-\frac{1}{2^a}\right)^{r}\right)^{k}
$$

The tool reports the largest $q = 2^B$ for which this stays below $2^{-8n}$, capped at $2^{64}$. For SLH-DSA-128s at $q = 2^{64}$ the bound gives about 133 bits, above the 128-bit target. This is a classical bound: quantum speedups and attack terms independent of $q$ are not modeled.

## Variants

Both variants produce signatures that a FIPS 205 verifier rejects. They fit settings where you also control the verifier, such as a smart contract.

> Note: both variants are being added to the tool, and will be available soon.

### WOTS+C

WOTS+ writes the signed value as $\mathrm{len}_1$ base-$w$ digits, one hash chain each, plus $\mathrm{len}_2$ checksum chains. At $n = 16$ and $w = 16$, $\mathrm{len}_1 = 8n / \log_2 w = 32$ and $\mathrm{len}_2 = 3$. WOTS+C ([Hülsing, Kudinov, Ronen and Yogev](https://eprint.iacr.org/2022/778)) removes the $\mathrm{len}_2$ checksum chains. The signer hashes the value to sign together with a counter, incrementing the counter until the $\mathrm{len}_1$ base-$w$ digits of the result sum to a fixed target $S$. The verifier recomputes that hash and rejects any digest whose digits do not sum to $S$.

A forger can only advance chains, so a forgery needs digits that are each at least the signed ones. Two digit vectors with the same sum meet that condition only if they are equal.

Per layer at $n = 16$, $w = 16$ ($\mathrm{len}_1 = 32$, $S = 240$):

- Size: 32 chains instead of 35, minus 48 bytes, plus the counter (4 bytes in the reference implementation).
- Verification: constant at $\mathrm{len}_1 \times (w - 1) - S = 240$ chain hashes plus one digest hash, against 525 in the WOTS+ worst case.
- Signing and keygen: each tree leaf costs $\mathrm{len}_1 \times w + 1$ hashes instead of $\mathrm{len} \times w + 1$. The counter search adds about 66 expected hashes per layer.

Two extra knobs trade signing for verification. Raising $S$ above the mean shortens verification and requiring the first $z$ digits to be zero drops $z$ more chains, at $w^z$ times the search cost.

### Irregular hypertree

Standard SPHINCS+ gives every layer the same height $h'$. An irregular hypertree gives layer $i$ its own height $h'_i$ (layer 0 at the bottom), with $h = h'_0 + \cdots + h'_{d-1}$. Any $h' \in \mathbb{N}^{d}$ is valid: the leaf index splits into one field of $h'_i$ bits per layer, and nothing else changes.

- Signature size and verification depend only on $h$ and $d$, so they are unchanged.
- Keygen builds the top tree only, $2^{h'_{d-1}}$ WOTS+ keys.
- Signing rebuilds every layer:

$$
\text{hypertree signing hashes} = \sum_{i=0}^{d-1} \left( 2^{h'_i} \left(\mathrm{len} \cdot w + 2\right) - 1 \right)
$$

At fixed $h$ and $d$ this sum is smallest for heights as equal as possible, because $2^x$ is convex. Irregular splits help in two cases.

1. $h$ not divisible by $d$. With $d = 7$, $h = 64$ becomes six layers of 9 and one of 10, instead of forcing $h = 63$ or 70.
2. Cached upper trees. The top tree is the same for every signature, so a signer that keeps it in memory pays for it once, at keygen.

The cache is derived from the secret key, so losing it costs time, never security. The scheme stays stateless.

## Metrics

Costs are counted in hash calls, as the tool reports them. Compute cost and time are beyond the scope of this tool, as they depend on several factors beyond the signature parameters: hash function choice, specific implementation optimizations and hardware.

### Signature size

$$
|\sigma| = n\left(1 + k(a+1) + h + d \cdot \mathrm{len}\right)
$$

The terms are the randomizer R, the FORS leaves and paths, the hypertree authentication paths and the $d$ WOTS+ signatures. The public key is $2n$ bytes and the secret key $4n$.

### Verification hashes

$$
V_{\max} = k(a+1) + 1 + d\left(\mathrm{len}(w-1) + 1 + h'\right)
$$

- Per FORS tree: one leaf hash and $a$ path hashes, then one hash compresses the $k$ roots.
- Per layer: $\mathrm{len}(w - 1)$ chain steps in the worst case, one hash to compress the WOTS+ key, $h'$ path hashes. The average case halves the chain term. The single $H_{\mathrm{msg}}$ call is not counted.

### Signing hashes

$$
S = k\left(3 \cdot 2^{a} - 1\right) + d\left(2^{h'}\left(\mathrm{len} \cdot w + 2\right) - 1\right)
$$

- The FORS term builds $k$ trees: one PRF and one F per leaf, plus $2^a$ − 1 internal nodes.
- The hypertree term rebuilds one XMSS tree per layer: each leaf costs len PRF calls, len($w - 1$) chain steps and one compression, plus $2^{h'}$ − 1 internal nodes. The $d$ WOTS+ signing passes and the message hashes add under 0.1% and are left out above.

### Keygen hashes

$$
K = 2^{h'}\left(\mathrm{len} \cdot w + 2\right) - 1
$$

Keygen builds the top tree only, the same cost as one layer of signing.

## Using the tool

A typical session:

1. Set Budget Limits to the number of signatures the key must support.
2. Pick $n$ for the security level and load the nearest preset.
3. Adjust $d$, $h'$, $k$ and $a$ until the derived budget clears your minimum and the panel shows no warning.
4. Tune $w$ and the split between $d$ and $h'$ for the balance of size, signing cost and gas you need.
5. Save the result with Add Profile and compare it against the presets and continue exploring.

### Interpreting the plots

**Trade-off.** A radar chart with five axes: signature size, total gas, signing hashes, verification hashes and signature budget. Each axis is normalized on its own and log-scaled where values spread widely, so compare shapes, not areas. Toggle presets or profiles to overlay them on the current configuration.

![Trade-off radar chart: Gas Saver vs SLH-DSA-128s vs SLH-DSA-128f](https://research.projecteleven.com/images/sphincs-companion-guide/01-tradeoff-radar.png)

Example: 128f reaches further on size and gas (17,088 B, 986k) and pulls in on signing (112k hashes against 2.19M). Both sit at $2^{64}$ on budget. Gas Saver (3,392 B, 83.6k gas) shrinks size and gas by giving up budget.

**Hypertree.** Draws the structure for the current parameters: $d$ XMSS layers of $2^{h'}$ leaves above $k$ FORS trees of $2^a$ leaves. Use it to check that a change did what you meant.

![Hypertree structure for the current parameters](https://research.projecteleven.com/images/sphincs-companion-guide/02-hypertree-structure.png)

**Parameters.** A scatter of every configuration on two metrics you choose, by default signature size (x) against signing hashes (y, log scale). Lower left is better. A configuration is probably worth keeping only if no other point sits both left of it and below it.

![Parameters scatter: signature size vs signing hashes](https://research.projecteleven.com/images/sphincs-companion-guide/03-parameters-scatter.png)

Example: SLH-DSA-128s sits at 7,856 B and 2.19M signing hashes. SLH-DSA-128f moves right to 17,088 B and down to 112k: more layers of smaller trees make signing about 20 times cheaper for 2.2 times the bytes. Gas Saver sits furthest left at 3,392 B but highest, at about 119M: with the extreme value of $d = 1$, every signature rebuilds one $2^{18}$-leaf tree plus seven FORS trees of $2^{20}$ leaves. None of the three beats another on both axes, so all three sit on the frontier.

**Results.** The size breakdown shows where the bytes go. For 128s: WOTS+ 3.92 KB, FORS 2.91 KB, authentication paths 1.01 KB. If WOTS+ dominates, look at $d$ and $w$; if FORS dominates, look at $k$ and $a$.

### Share your best sets

Share → Copy link encodes the parameters, chart axes and pinned configurations; opening the link restores the exact view. Share on X posts the same link. Profiles saved with Add Profile live in your browser only and disappear when browser data is cleared, so keep the link.

When you post a set, state the budget it targets and what it optimizes (bytes, gas or signing time), so others can compare it with sets built for the same goal.