Quantum Wallet Backups: Stateful XMSS vs Stateless SPHINCS+

By SynergyX · Published September 20, 2026 · Sources checked on this date

XMSS vs SPHINCS+: what must a wallet remember?

The distinction concerns the signature scheme’s secret state, not whether a wallet synchronizes a blockchain. A stateless signer can still live inside an application that stores balances, transaction history, nonces and configuration.

RFC 8391 explains why XMSS implementations must prevent state reuse. FIPS 205 specifies the stateless SLH-DSA construction derived from SPHINCS+. The choice changes operations as well as cryptography.

Why a stale backup can matter to an XMSS wallet

Consider two copies of a wallet created before an outgoing transaction. The first copy signs and advances its state. If the second copy later signs using the old state, the same one-time key may be exposed again. Restoring the seed successfully is therefore only one part of restoring an operational signer.

QRL’s official OTS documentation describes this constraint for its XMSS wallets. It documents a default tree with 1,024 signing indexes; receiving funds does not consume the recipient’s OTS index. Other tree configurations and wallet workflows exist, so follow the instructions for the exact wallet release.

Do not assume a rejected or unconfirmed transaction means a one-time signing key can be reused. Signing may already have exposed information. Use the wallet’s documented state management and recovery workflow rather than manually lowering a counter.

Does stateless mean a backup can be copied without consequences?

No. Stateless signatures remove one particular synchronization requirement. Every extra copy of a secret remains another place it can be stolen. An old backup can also lack account metadata, custom derivation settings, contacts or application changes needed for a complete recovery.

The upstream SPHINCS+ implementation offers parameter sets emphasizing smaller signatures or faster generation. Neither choice eliminates malware, poor randomness or a broken verifier. Read the wallet cryptography roles guide to separate signing from encryption and recovery.

A recovery drill before funding a quantum wallet

Use a new, unfunded test wallet and the official documentation for the exact application. Record the release version alongside the backup format so that a future recovery starts with useful information.

1. Identify every required recovery item. Determine whether the wallet needs a phrase, file, password, derivation settings or additional metadata. Do not assume another wallet accepts the same format.
2. Confirm state handling. For a stateful signer, establish how the restored application avoids reuse of previously consumed signing keys. Avoid running competing active copies.
3. Test the documented restore. Use trusted software in an appropriate test environment. Confirm the expected receiving address before using the wallet for real funds.
4. Check backup access. Verify that the backup remains readable and that any required password is available through your recovery process.
5. Document the result without secrets. Record the date, software version, expected public address and success or failure. Keep seed words and private keys out of notes, screenshots and support messages.

SYNX backup and recovery documentation

SynergyX identifies its signing parameter as SPHINCS+-SHAKE-128s. The stateless design is relevant when evaluating backup workflows, but the application’s recovery format still determines what users must preserve.

Use the SYNX wallet backup guide and the restore guide for product instructions. Compare those instructions with the version on the official release page.