A stateless hash-based signature is a form of post-quantum cryptography designed to be secure against attacks from both classical and quantum computers. Unlike traditional schemes like ECDSA or RSA, its security is based on the one-way property and collision resistance of a hash function (e.g., SHA-256), not the hardness of problems like integer factorization or discrete logarithms. This makes it a leading candidate for quantum-resistant digital signatures in blockchain and secure communication protocols.

Stateless Hash-Based Signature
What is a Stateless Hash-Based Signature?
A stateless hash-based signature (HBS) is a post-quantum digital signature scheme that relies solely on the security of cryptographic hash functions, requiring no persistent secret state between signing operations.
The "stateless" property is critical: the signer does not need to track which one-time signature keys have been used, eliminating complex state management and synchronization issues present in earlier stateful HBS schemes like XMSS. Stateless schemes, such as SPHINCS+, achieve this by using a few-time signature (FTS) layer and a vast hyper-tree structure, where each leaf is a one-time key. A signature includes a path through this tree and a proof, allowing verification without the signer remembering past signatures.
In practice, stateless HBS schemes trade some efficiency for robustness and simplicity. They typically produce larger signatures and require more computational resources for signing and verification compared to classical algorithms. However, their provable security and resistance to side-channel attacks make them invaluable for long-term cryptographic applications, such as securing blockchain smart contracts, software updates, and foundational internet infrastructure against future quantum adversaries.
How Stateless Hash-Based Signatures Work
Stateless hash-based signatures are a post-quantum secure digital signature scheme that uses a one-time signature key derived from a hash chain, requiring no persistent secret state to be maintained by the signer between signatures.
A stateless hash-based signature (HBS) scheme is a digital signature construction designed to be secure against attacks from both classical and quantum computers. Its core innovation is the generation of a massive set of one-time private keys from a single, compact seed using a hash function, eliminating the need for the signer to track which keys have been used. This stateless property is critical for reliability and scalability in distributed systems, as it prevents signature failure due to lost state synchronization.
The most prominent construction is the Extended Merkle Signature Scheme (XMSS) and its multi-tree variant XMSS^MT. The signer first generates a Merkle tree of one-time verification keys, where the root of this tree becomes the single, long-term public key. Each leaf is derived from a unique Winternitz One-Time Signature (WOTS+) key pair, itself generated from a pseudorandom function seeded by a master secret. To sign, the signer uses a leaf's private key and provides the corresponding authentication path—a set of hashes—to prove the leaf's membership in the Merkle tree.
Verification involves checking the one-time signature against the leaf's public key and then recomputing the Merkle root using the provided authentication path to match the signer's published root. While highly secure, these schemes produce larger signatures and keys compared to ECDSA or EdDSA, and they have a finite cap on the number of signatures that can be issued, defined by the height of the Merkle tree. They are standardized by bodies like NIST and the IETF for use in a post-quantum cryptographic future.
Key Features and Characteristics
Stateless Hash-Based Signatures (SHBS) are a cryptographic primitive that enables transaction validation without requiring validators to maintain any persistent state, relying solely on cryptographic proofs and a one-time-use key structure.
Statelessness & Scalability
The core innovation of SHBS is its statelessness. Validators do not need to store or synchronize a global state (like account balances or nonces) to verify signatures. This eliminates a major scalability bottleneck, as node resource requirements become independent of the number of users or transactions in the system. Validation is performed using only the transaction data and publicly available cryptographic parameters.
One-Time Signature (OTS) Foundation
SHBS schemes are built upon One-Time Signature (OTS) systems like Lamport, Winternitz, or SPHINCS+. A private key can sign a single message securely. To enable multiple signatures, the scheme uses a Merkle tree of many OTS key pairs. The public key is the root of this tree, and each leaf is a one-time key pair. Signing reveals a leaf key and a Merkle proof, proving it belongs to the root.
Hash-Based Cryptography
Security relies solely on the cryptographic strength of hash functions (e.g., SHA-256, SHA-3), not on number-theoretic problems like integer factorization or discrete logarithms. This makes SHBS quantum-resistant, as hash functions are considered secure against known quantum algorithms. The trade-off is larger signature sizes compared to ECDSA or Schnorr signatures.
Merkle Tree Structure & Key Management
A Merkle tree organizes thousands of one-time key pairs.
- Root Public Key: The single, long-term public key.
- Leaf Private Keys: Used sequentially for signing.
- Authentication Path: A Merkle proof included with each signature, proving the leaf's membership. Once a leaf key is used, it must never be reused. The signer must track their current key index locally, but this state is not required by verifiers.
Verification Process
Verification is a deterministic, state-free process:
- Verify OTS: Check the one-time signature against the revealed leaf public key.
- Verify Merkle Proof: Use the provided authentication path to hash up to the root.
- Compare Roots: Ensure the computed root matches the known long-term public key of the signer. No database lookups for nonces or balances are needed, enabling parallel and highly efficient validation.
Trade-offs: Size & State Management
SHBS involves significant trade-offs:
- Large Signature Sizes: Signatures include the OTS and the Merkle proof, often ranging from ~10KB to ~40KB, compared to ~64-72 bytes for ECDSA.
- Forward-Secrecy Local State: The signer must securely manage their current key index to prevent reuse. Loss of this local state can compromise security.
- Finite Signature Capacity: The total number of signatures is limited by the pre-generated leaves in the Merkle tree.
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos

Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
Comparison: Stateless vs. Stateful Hash-Based Signatures
A technical comparison of the two primary operational modes for hash-based signature schemes, focusing on key management, security, and practical deployment trade-offs.
| Feature / Metric | Stateless HBS (e.g., SPHINCS+) | Stateful HBS (e.g., XMSS, LMS) |
|---|---|---|
State Management Requirement | None | Critical |
Private Key Structure | Single, static secret key | Stateful key with an index/counter |
Signature Uniqueness Guarantee | Probabilistic (via randomization) | Deterministic (via monotonic index) |
Signing Key Exhaustion | Effectively unlimited signatures | Finite number of signatures per key pair |
Signature Size | Larger (~8-50 KB) | Smaller (~1-4 KB) |
Signing/Verification Speed | Slower signing, fast verification | Fast signing and verification |
Parallel Signing | Fully parallelizable | Sequential (state update is critical) |
Key Loss/Desync Risk | None | Catastrophic (permanent loss of usability) |
Ideal Use Case | Long-term archival, non-interactive protocols | High-throughput, managed devices (HSMs, IoT) |
Frequently Asked Questions
Stateless Hash-Based Signatures (SHBS) are a foundational cryptographic primitive for scaling blockchain state. This FAQ addresses their core mechanisms, trade-offs, and role in modern blockchain architectures.
A Stateless Hash-Based Signature (SHBS) is a cryptographic signature scheme where a verifier can validate a transaction using only a short cryptographic commitment (a hash) to the signer's state, rather than requiring the full, current state data. The signature itself is a Merkle proof that demonstrates the signer possessed valid credentials (like a specific nonce or token) at the time of signing, as committed to in a known state root. This enables stateless verification, where nodes do not need to store the entire global state to validate transactions, dramatically reducing hardware requirements for network participants.
Key components include:
- State Root: A Merkle root (e.g., in a Sparse Merkle Tree) that commits to all valid accounts/balances/nonces.
- Witness: The Merkle proof included with the signature, proving membership of the signer's data in the committed state.
- One-Time Signature: Often built from a hash-based one-time signature (HBS) like Lamport, Winternitz (WOTS), or SPHINCS+, providing quantum-resistance.
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.


