hashsigs-solidity: WOTS+ Post-Quantum Signature Contracts for Ethereum

What hashsigs-solidity Solves and Who Needs It

Ethereum contracts currently rely on ECDSA (specifically secp256k1) for signature verification, which is the same elliptic curve cryptography used by Ethereum wallets. Sufficiently powerful quantum computers are theorized to break elliptic curve cryptography using Shor's algorithm. WOTS+ is a hash-based signature scheme that derives its security from hash function preimage resistance rather than from the hardness of elliptic curve discrete logarithms, making it a candidate for post-quantum security.

hashsigs-solidity brings WOTS+ into Solidity so that smart contract developers can write signature verification logic that does not depend on elliptic curve assumptions. The target audience is blockchain engineers building protocols that need long-term security guarantees or that want to experiment with post-quantum cryptographic primitives on EVM chains.

How WOTS+ Works as a Signature Scheme

WOTS+ is a one-time signature scheme. That term has a specific technical meaning: a single WOTS+ key pair is designed for exactly one signature. Signing a second message with the same key reveals enough information about the private key to allow forgery. This is the core trade-off of the scheme: in exchange for simple, hash-only cryptography, the protocol requires strict key management to ensure each key is used at most once.

The plus in WOTS+ refers to improvements over the base Winternitz scheme that provide better security against chosen-message attacks through the use of bitmask XOR operations during key generation and signing. The scheme is deterministic: given the same private key material and message, it produces the same signature, which is useful for on-chain verification where reproducibility is required.

Installing Foundry and Building the Contracts

hashsigs-solidity uses Foundry as its development and testing framework. To get started, install Foundry with the official installer:

curl -L https://foundry.paradigm.xyz | bash
foundryup

This installs forge and the other Foundry tools. With Foundry installed, compile the contracts:

forge build

The build reads the contracts in the contracts/ directory and compiles them to ABI and bytecode. The repository also ships a package.json with name @quip.network/hashsigs-solidity at version 0.0.2, so the contracts can be distributed as an npm package. The package includes the .sol files in contracts/, the package.json, the README.md, and the LICENSE file. Running forge build is also called automatically during the npm prepare step.

Running the Test Suite

Tests live in the test/ directory and run through Foundry's test runner. The README gives two verbosity levels:

forge test -vv

The -vv flag increases verbosity to show more test details. The README notes that -vvv adds even more detail including stack traces, which is useful when a test fails and the revert reason is not obvious. The tests exercise the WOTS+ contract logic directly, covering key generation, signing, and verification flows.

The repository also includes a .gitlab-ci.yml, indicating that CI/CD is configured to run tests automatically on push, alongside the standard GitHub Actions integration visible in the .github/ directory.

The One-Time-Use Constraint as a Deployment Limitation

The most significant limitation of WOTS+ is the one-time-use requirement. Any on-chain protocol built with this library must ensure that the same WOTS+ key is never used to sign two different messages. On a public blockchain where all transactions are visible, key reuse is catastrophic: an observer who sees two signatures from the same key has enough information to reconstruct the private key and forge signatures.

This means that any contract system using hashsigs-solidity must implement a key rotation mechanism and enforce single-use keys at the application layer. The library itself does not enforce or track key usage; that is the protocol designer's responsibility. For high-throughput signing scenarios, the management overhead of generating, tracking, and retiring large numbers of one-time keys is a real cost.

The README does not document gas costs for the WOTS+ operations. On-chain hash operations consume gas, and WOTS+ involves multiple rounds of hashing per signature and verification. Protocols that expect to verify many signatures per transaction should benchmark gas consumption before committing to this approach.

hashsigs-solidity vs ECDSA on Ethereum

Standard Ethereum signature verification uses ecrecover, a precompile that recovers the signer's address from an ECDSA signature over secp256k1. It is inexpensive in gas terms, widely supported across all EVM-compatible chains, and has been used in production since Ethereum's launch. The tooling ecosystem, including wallet support, is built entirely around ECDSA.

hashsigs-solidity takes a different approach: it brings hash-only signing to Solidity at the cost of key management complexity and higher verification cost. The motivation is quantum resistance. ECDSA's security depends on the difficulty of solving the elliptic curve discrete logarithm problem, which Shor's algorithm can solve on a large enough quantum computer. WOTS+ security depends on hash preimage resistance, which quantum attacks (specifically Grover's algorithm) weaken but do not break as completely. For contracts that must remain secure over a decade or longer, this distinction matters to some protocol designers today, even before large-scale quantum computers exist.

AGPL-3.0 License Implications

hashsigs-solidity is licensed under AGPL-3.0. The AGPL (Affero General Public License) extends the copyleft requirements of GPL to network use. Under AGPL-3.0, if you modify the contracts and deploy a service that users interact with over a network, including a blockchain, you must make the source code of the modified version available. This is a stronger copyleft requirement than MIT or Apache 2.0, and it has direct implications for commercial projects.

A protocol that incorporates hashsigs-solidity without modification does not need to release its own source code under AGPL. But any fork or modification that ends up deployed as part of a network-accessible service must comply with the license's source disclosure terms. The copyright holder is listed as quip.network, and the copyright year is 2024 per the README. The last push to the repository was on 2026-09-09.

Editorial conclusion

Blockchain developers adding post-quantum signature verification to Ethereum contracts will find hashsigs-solidity the most direct available path to WOTS+ on EVM. The one-time-use constraint of WOTS+ is a real design consideration: any protocol built on this library must manage key rotation carefully. The AGPL-3.0 license requires any service that runs modified versions of the contracts as network-facing software to publish those modifications.

Frequently asked questions

Official sources

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