hashsigs-ts: TypeScript WOTS+ Post-Quantum Signatures for Node.js and the Web

What hashsigs-ts Is and Who Needs It

Standard public-key cryptography in JavaScript, whether through the Web Crypto API or Node.js crypto module, relies on elliptic curve algorithms. Elliptic curve signing is efficient and widely deployed, but its security depends on the hardness of the discrete logarithm problem on the curve. Shor's algorithm, run on a large enough quantum computer, can solve that problem. Hash-based signature schemes like WOTS+ are considered quantum-resistant because their security comes from hash function preimage resistance, which Grover's algorithm weakens but does not break as completely.

hashsigs-ts packages WOTS+ for the JavaScript ecosystem as an npm module. It is aimed at developers building protocols that want to evaluate post-quantum signing today, before quantum hardware of sufficient scale exists, or that need to work alongside the companion hashsigs-solidity library for Ethereum contract verification. The author listed in package.json is Richard T. Carback III, and the repository is maintained by quip.network as part of a broader hash-based signatures effort that spans Solidity and TypeScript.

The WOTS+ Construction in TypeScript

WOTS+ is a one-time signature scheme. A single key pair generates a valid signature for exactly one message. Signing a second message with the same key leaks private key material. The plus variant improves over the base Winternitz scheme by adding bitmask XOR operations during the chaining function, which provides stronger security against chosen-message attacks.

The package.json lists @noble/hashes at version ^1.7.1 as a runtime dependency, which supplies the hash function primitives. tsup at version ^8.4.0 handles bundling. The package produces dual output: a CommonJS build at dist/index.js and an ES module build at dist/index.mjs, with TypeScript declarations at dist/index.d.ts. This dual-format output means the library works in both Node.js CommonJS projects and modern ESM environments or bundlers.

Installing and Importing hashsigs-ts

Install the package from npm:

npm install hashsigs-ts

The npm package name is hashsigs-ts. The published package name in package.json is @quip.network/hashsigs at version 0.1.0, so both identifiers appear in different contexts. The package.json entry point is dist/index.js for CommonJS consumers, dist/index.mjs for ESM consumers, and dist/index.d.ts for TypeScript type checking. The files field in package.json restricts the published package to the dist/ directory only, which keeps the published tarball small.

Building and the Development Workflow

The build uses tsup, a TypeScript bundler built on esbuild. A single build command compiles the TypeScript sources in src/ to both output formats:

npm run build

During development, watch mode rebuilds on file changes:

npm run dev

This runs tsup with the --watch flag. The tsconfig.json and tsup.config.ts files at the repository root control the TypeScript compiler options and the bundle output configuration respectively. The clean script removes the dist/, coverage/, and node_modules/ directories:

npm run coverage

Testing with Vitest and Coverage Thresholds

Tests use Vitest, configured in vitest.config.ts. The README documents specific minimum thresholds for code coverage: functions at 80%, branches at 80%, and statements at 80%. Falling below any of those thresholds causes the coverage run to fail, which means contributors must maintain adequate test coverage as a condition of merging changes.

The test commands are:

npm test

For watch mode during development, npm run test:watch runs Vitest in interactive mode. The coverage command generates four report formats: console output, an HTML report in coverage/index.html, a JSON report, and an LCOV report for CI/CD integration. The LCOV format is compatible with most CI coverage tracking services. Test dependencies are devDependencies: vitest at version ^3.0.9 and @vitest/coverage-v8 at 3.0.9 provide the runtime and the V8-based coverage instrumenter.

Limitations of WOTS+ in a Production Context

The one-time-use constraint is the most important limitation. Any application that allows a WOTS+ key to sign more than one message creates a forgery vulnerability. The library itself does not track or enforce single-use; the consuming application must manage a key registry or derivation scheme that guarantees each key is used exactly once.

For high-volume signing, this is a significant overhead. Each signing operation requires generating a fresh key pair, storing it, using it once, and retiring it. Long-lived applications that sign thousands of messages need a hierarchical key management scheme on top of WOTS+, such as a Merkle tree structure that aggregates many one-time keys under a single root.

The README does not document a formal security audit of the implementation. The repository is at version 0.1.0, which indicates it is not yet a stable release. There are no GitHub releases. The last push to the repository was on 2026-07-27. The AGPL-3.0 license requires that modified versions deployed as network services publish their source code, which is a consideration for any commercial product that wants to fork the library.

hashsigs-ts vs ECDSA in Node.js

The built-in Node.js crypto module provides ECDSA signing through the Web Crypto API and the native crypto.sign and crypto.verify functions, using curves like P-256 or Ed25519. ECDSA is fast, widely audited, supported by hardware security modules, and is the default approach for nearly every signing use case in the JavaScript ecosystem today.

hashsigs-ts takes a different approach: it trades elliptic curve assumptions for hash-only assumptions, at the cost of one-time key management and larger signature sizes. ECDSA produces compact signatures and allows key reuse across any number of messages. WOTS+ produces signatures that reveal part of the private key on each use, which is why the scheme only allows one signing operation per key. The case for WOTS+ is specifically the long-term argument: if elliptic curves become breakable, hash-based schemes remain secure because breaking them requires solving a different, harder computational problem. For applications where a 10 or 20 year security horizon matters, or for developers building infrastructure that must survive a post-quantum migration, evaluating post-quantum primitives like those in hashsigs-ts is a concrete first step rather than a theoretical exercise.

Editorial conclusion

TypeScript developers who need to experiment with hash-based post-quantum signing will find hashsigs-ts the most direct starting point in the npm ecosystem from quip.network. The one-time-use constraint of WOTS+ means any production protocol must solve key rotation before shipping, and the AGPL-3.0 license restricts how modified versions can be deployed in network-facing services. Review the coverage reports in coverage/index.html after running npm run coverage to confirm which code paths are exercised before integrating.

Frequently asked questions

Official sources

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