hashsigs-solidity: on-chain verifiers for WOTS+, SHRINCS and SPHINCS+C hash-based signatures

The contracts verify signatures and leave the signer to you

The production contracts under contracts/ cover on-chain verification only. Signer-side recovery state, seed restore logic and wallet lifecycle management are out of scope. There are Solidity signer helpers, but they live under test/helpers/, exist for tests, and are not deployable. For a builder this means the hard operational part of hash-based signatures, never reusing a one-time key and recovering safely after a signer loses state, has to be solved off chain by your own code. Deploying these verifiers gives you a correct check of whatever signature arrives; it does not stop a careless signer from producing a dangerous one.

WOTS+ is a standalone one-time scheme with fixed parameters

contracts/WOTSPlus.sol implements the Winternitz one-time signature scheme from Hülsing's W-OTS+ paper. Its parameters are fixed: Keccak-256, 32-byte hashes and messages, Winternitz parameter w = 16, and 67 chains made of 64 message chains and 3 checksum chains. It has no dependency on SHRINCS. The public API, verify, verifyWithRandomizationElements, sign, generateKeyPair, generateRandomizationElements, chain and the public constants, is stable and vector-tested. The signer-side functions are reference code marked "do not use on-chain", because generating keys inside a public contract exposes them. A WOTS+ key signs one message; using it twice is the user's problem, not the contract's.

SHRINCS pairs a cheap stateful path with a stateless fallback

SHRINCS, the hybrid construction by Kudinov and Nick specified in ePrint 2025/2203, has two verification paths. The stateful path is the normal case and the cheaper one: a compact WOTS-C signature plus an unbalanced XMSS-style authentication path. The stateless path is the fallback for a restored or degraded signer, using a SPHINCS-style FORS-C plus hypertree plus WOTS-C structure. Each SHRINCS verifier exposes the stateful verify and a verifyStateless that delegates to a pinned SPHINCS+C sibling contract. The verifier checks signatures and rotation authorizations but does not track signer state, so it cannot tell you that a stateful leaf has already been used elsewhere.

Only the 256s profile is reviewed; the 128s profiles are experimental

SHRINCS is compiled per profile. 256s is the default: keccak-256, 32-byte hashes, h = 64, d = 8, a = 14, k = 22, 64 WOTS-C chains and a 2^20 stateless budget, reviewed and anchored to Rust-generated signature vectors. 128s-q18 uses 16-byte truncated hashes, a single-layer h = 18 hypertree, a = 24, k = 6, 32 WOTS-C chains and a 2^18 stateless budget. 128s-q20 matches it with a 2^20 budget and shares the 128s vectors except the profile-bound commitment. Both 128s profiles are labelled experimental. Choosing one of them for smaller hashes means accepting a profile that has vector tests but not the review status of 256s.

verifyAndAttest saves a one-time leaf within a transaction

Each SHRINCS verifier also exposes verifyAndAttest and wasVerified. A successful verifyAndAttest records the verification for the calling account in EIP-1153 transient storage. Other contracts called later in the same transaction can ask wasVerified instead of demanding a fresh signature. That matters because a fresh stateful signature consumes another one-time leaf. The record lives in transient storage, so it does not outlast the transaction; a check in a later transaction needs a new signature.

Every profile is a pair of deployed contracts

Deployment is per profile and in pairs. SHRINCS256sKeccak, SHRINCS128sQ18Keccak and SHRINCS128sQ20Keccak are the stateful verifiers, each carrying a PROFILE_TAG and pinning its stateless sibling: SPHINCSPlusC256sKeccak, SPHINCSPlusC128sQ18Keccak or SPHINCSPlusC128sQ20Keccak. The standalone SPHINCS+C verifiers check the stateless recovery path directly. Underneath, SHRINCS.sol is the pure verification core; Hash.sol holds profile-independent primitives shared by every suite; contracts/hash/keccak/HashSuite.sol is the compile-time seam for tagged scheme hashes, selected through the shrincs-hash/ remapping; UXMSS.sol, FORSMinusC.sol, Hypertree.sol and WOTSPlusC.sol hold the component logic. Verifiers implement the ERC-7913 interface.

A Foundry project with an npm name and no tagged releases

The repository is a Foundry project, with foundry.toml, foundry.lock and lib/, and its package.json maps both build and prepare to the same command and test to another:

forge build
forge test

The package is named @quip.network/hashsigs-solidity at version 0.3.0, and its files list ships only contracts, package.json, README.md and COPYING. GitHub shows no releases, so there is no tagged version to pin from the repository itself. The licence is AGPL-3.0, AGPL-3.0-or-later in package.json, which carries obligations that a permissive licence would not. Top-level entries also include audit/, DEPLOYMENTS.md, slither.config.json and medusa.json. The last push to main was on 31 October 2026.

Editorial conclusion

hashsigs-solidity suits Ethereum developers who need on-chain verification of hash-based, post-quantum signatures and who already have, or will build, a signer that manages one-time keys and recovery state. It does not suit anyone expecting a wallet or signer library, and its 128s profiles are marked experimental. Before deploying, pick the 256s profile unless you have reason not to, check the AGPL-3.0 terms against your project, and confirm deployed addresses against DEPLOYMENTS.md.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. QuipNetwork/hashsigs-solidity on GitHub
4. README