HashSigs RHDL
A contributor's guide to a profile-separated WOTS+ implementation authored in Rust/RHDL, emitted as Verilog, and evaluated one evidence tier at a time.
This workspace implements the non-Solana WOTS+ technology behind a pinned
HashSigsRS revision. The software oracle and hardware models share the same
parameters—n = 32, w = 16, and 67 chains—but they expose two intentionally
incompatible hash profiles.
Compatibility
Byte-compatible with the pinned upstream vectors. It uses legacy Keccak-256 padding, not SHA3-256.
Hardware performance
The active three-lane signer and verifier use SHA-256. Their keys and signatures are not compatible with the legacy profile.
One private key signs one message
WOTS is a one-time signature. Reusing a private key can reveal enough chain material to enable a forgery. Consuming Rust types reduce accidental reuse, but durable key lifecycle remains a system responsibility.
What is active now
The production SHA-256 signer is three lane-local clusters with four live WOTS contexts per cluster: three lanes × four contexts = twelve contexts. The production SHA-256 verifier has the same 3×4 topology and adds fail-closed tag, timing, framing, and peer-abort handling.
An earlier nine-context/three-lane transport fabric remains useful as a tested prototype and library component. It is not the active production signer or verifier topology.
The hardware verifier supports only HASHSIGS_SHA256_GENERIC_V1. Legacy
Keccak verification is provided by the software reference implementation; the
site does not imply a legacy hardware verifier.
Choose a path
Contribute code
Read the active system map, then follow the leaf-to-top workflow.
Review security
Start with the cryptographic contract and security policy.
Audit a claim
Use the evidence ladder, then open the generated evidence matrix.
The Rust API documents every supported public API item. The evidence matrix is generated from a checked manifest so a number, source revision, tier, claim, and nonclaim stay together.