Two founders at a WeWork communal table planning DeFi strategy, laptops open, notebooks with sketches, afternoon light from tall windows, candid startup vibe.
Glossary

Stateless Hash-Based Signature

A stateless hash-based signature is a quantum-resistant digital signature scheme that does not require the signer to maintain secret state between signatures, simplifying key management at the cost of larger signature sizes.
definition
CRYPTOGRAPHIC PRIMITIVE

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.

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.

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-it-works
CRYPTOGRAPHIC PRIMITIVE

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
STATELESS HASH-BASED SIGNATURE

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.

01

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.

02

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.

03

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.

04

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

Verification Process

Verification is a deterministic, state-free process:

  1. Verify OTS: Check the one-time signature against the revealed leaf public key.
  2. Verify Merkle Proof: Use the provided authentication path to hash up to the root.
  3. 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.
06

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.
Chains We Build On

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 logo
    Ethereum
  • Arbitrum logo
    Arbitrum
  • Optimism logo
    Optimism
  • Polygon logo
    Polygon
  • Avalanche logo
    Avalanche
  • Cronos logo
    Cronos

Non-EVM ecosystems

  • Solana logo
    Solana
  • Sui logo
    Sui
  • Aptos logo
    Aptos
  • Hedera logo
    Hedera
  • Stellar logo
    Stellar
  • NEAR logo
    NEAR

Additional ecosystems

  • Polkadot logo
    Polkadot
  • Cosmos logo
    Cosmos
  • TON logo
    TON
  • Cardano logo
    Cardano
  • Algorand logo
    Algorand
  • Tempo logo
    Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

POST-QUANTUM CRYPTOGRAPHY

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 / MetricStateless 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)

STATELESS HASH-BASED SIGNATURES

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.
Trusted by Industry Leaders

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

ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
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.
L
Lee Erswell
CEO, Telos Foundation
how to get started

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.

01

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

02

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

03

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

04

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Start a build

Need a blockchain engineering team?

Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.