WOTS-39: A Live Post-Quantum Signature Wallet Across Bitcoin and Ethereum
The Core Problem
Every signature scheme securing crypto today (ECDSA, Schnorr, Ed25519) derives its security from the hardness of the elliptic curve discrete logarithm problem. Shor’s algorithm solves that in polynomial time on a sufficiently powerful quantum computer. This is not a theoretical future concern: NIST finalized its first post-quantum standards in 2024 precisely because the timeline is real. Every address that has ever broadcast a transaction has an exposed public key. Those addresses are the attack surface.
Hash functions do not share this vulnerability. Computing a hash preimage remains exponentially hard even for quantum computers. Grover’s algorithm offers only a quadratic speedup, which doubling the output size neutralizes entirely. Any signature scheme built entirely on hash functions is quantum safe today and into the foreseeable future.
How WOTS Works
Winternitz One-Time Signatures (WOTS+) are a hash-based signature scheme. The construction is straightforward.
Your private key is a set of random values. Your public key is each of those values hashed W times in a chain. In WOTS-39, W=256 using SHA-256, producing 34 hash chains of 256 steps each. To sign a message, you hash each private key element a number of steps proportional to the corresponding chunk of the message digest. The verifier completes the remaining steps in each chain and checks the result against your public key commitment.
The scheme is unconditionally one-time. If you sign two different messages with the same key, you reveal midpoints at different positions in those same chains. An attacker who collects both signatures now has two reference points in each chain. From the lower of the two revealed positions, they can hash forward all the way to the public key, and to any position between the two revealed points as well.
Given enough signatures from the same key, an attacker can reconstruct enough chain material to forge any signature they choose. The security guarantee collapses entirely.
This is why WOTS+ is called a one-time signature scheme. Sign once. Retire the key forever.
The entire challenge of building a practical wallet on WOTS+ is answering one question: how do you sign thousands of transactions over a lifetime without ever reusing a key?
Traditional approaches like XMSS and SPHINCS+ solve this by building large trees of WOTS+ keys. Each leaf in the tree is a separate key used exactly once. The tree structure proves that each key belongs to the same owner without revealing the others. SPHINCS+, the NIST-standardized post-quantum signature scheme, uses a hypertree of such structures and produces signatures of approximately 8,000 bytes.
WOTS-39 takes a different approach. It uses the blockchain itself as the tree.
Every transaction on a blockchain has a unique identifier, its transaction hash or TXID. This identifier is computed from everything that defines the transaction: who is sending, who is receiving, how much, the time, and dozens of other details. No two valid transactions on the same chain will ever share the same TXID.
This uniqueness is not just a convenient property. It is enforced by the collective agreement of thousands of nodes running the blockchain protocol. Producing a duplicate TXID is not merely difficult, it is rejected outright. The blockchain will not accept it.
WOTS-39 uses the TXID as the unique identifier that makes each set of Winternitz keys one-time. Here is how:
anchor = H("hybrid-wots-v1" || TXID)
sk[i] = PRF(mskWOTS, anchor || i) for each of 67 chains
The master secret, mskWOTS, never appears on the blockchain. It lives only in your device’s memory during signing, derived on demand from your seed phrase. For each transaction, a unique anchor is computed by hashing a domain label and the transaction’s unique ID together. Then all 67 independent secret key elements are derived from the master secret and that anchor.
Because the TXID is different for every transaction, the anchor is different. Because the anchor is different, all 67 secret keys are different. Because the keys are different, the chain midpoints revealed in the signature are drawn from completely independent chains with no mathematical relationship to each other.
An attacker who collects every signature you ever produce learns nothing useful about future ones. Each signing event uses keys derived from a unique anchor. Knowing one anchor’s keys tells you nothing about any other anchor’s keys — that is the security guarantee of the pseudorandom function.
SPHINCS+ spends 8,000 bytes constructing a cryptographic tree to enforce key uniqueness. WOTS-39 spends zero bytes on this: the blockchain itself is the tree. The entire signature, including both the classical and post-quantum layers, is approximately 2,200 bytes.
Authorizing Key Uploads: The Lamport Chain
Winternitz signatures solve one half of the problem: proving you authorized a specific transaction. But they create a new challenge. Because each WOTS key can safely sign only one message, your wallet must upload a fresh key for every transaction. That raises an immediate question: how does the blockchain know that you are the one uploading each new key? Without an answer, an attacker could register their own fake key and redirect your funds.
This is what the Lamport chain solves, and it is the second half of WOTS-39’s core insight.
At wallet setup, you build a Lamport chain: a long sequence of hash values derived from your master secret. Imagine hashing your secret once to get value #1, hashing that to get value #2, and so on for thousands of steps. You publish only the final value, the chain tip, in a genesis commitment on the blockchain. Every earlier value stays private.
To authorize your first key upload, you reveal the second-to-last value: the preimage of the published tip. The blockchain runs a single SHA-256 hash. Does this value hash forward to the stored tip? If yes, ownership is proven. The blockchain advances its stored value, consuming that authorization slot permanently. For your next upload, you reveal the preimage before that. The chain runs backward toward your original secret, one step at a time.
Genesis commitment → H(H(...H(secret)...)) stored on-chain
Authorize upload 1 → reveal preimage of tip, prove it hashes forward
Authorize upload 2 → reveal preimage of that, prove it hashes forward
...and so on
An attacker who sees a revealed preimage cannot compute the next one. Doing so requires inverting SHA-256, which costs 2^128 operations even for a quantum computer. Each slot is one-time: once consumed, it is permanently spent. There is no replay, no reuse, no shortcut.
The Core Discovery: Winternitz + Lamport
This combination is the central insight of WOTS-39. Traditional ECDSA does two things simultaneously with a single key pair: it proves you authorized the transaction (signing), and it proves you own the address (key binding). WOTS-39 separates these two responsibilities across two quantum-secure primitives.
Winternitz handles message signing. Each transaction carries a unique WOTS+ signature proving you, and only you holding the master secret, authorized that specific transaction. Forging it without the secret requires 2^128 hash preimage inversions.
The Lamport chain handles key authorization. Every new WOTS public key is accompanied by a Lamport preimage proving it was submitted by the legitimate wallet owner. Submitting a fake key requires computing the next unrevealed preimage in the chain, the same 2^128 barrier.
Neither primitive alone is sufficient. A Winternitz signature without the Lamport chain leaves key uploads unprotected: anyone could swap in a malicious key. A Lamport chain without Winternitz provides authorization but not signing: the signature itself would be replayable. Together, they close every attack vector that quantum computers open against ECDSA, forming a complete drop-in replacement for elliptic curve signing built entirely from SHA-256 operations.
This is what makes WOTS-39 structurally different from earlier post-quantum proposals that simply swap one signing algorithm for another. The wallet does not just sign messages post-quantum: it proves ownership post-quantum, authorizes key transitions post-quantum, and chains all of these operations together without elliptic curve mathematics at any step.
When your Lamport chain runs out of slots, the wallet loads a fresh one. Each new chain is rooted in your master secret combined with a unique nonce, a different number for every chain you ever create.
Chain 1 tip = H^N(mskWOTS || nonce_1)
Chain 2 tip = H^N(mskWOTS || nonce_2)
Chain 3 tip = H^N(mskWOTS || nonce_3)
Because each nonce is unique, each chain tip is completely independent. An observer who collects every Lamport preimage from chain 1 learns nothing about chain 2. The nonces are derived deterministically from your master secret and a counter: you never need to store or remember them. The wallet handles all of this silently, pre-computing authorization values at startup and refreshing automatically when supply runs low.
Tuning the Winternitz Parameter
Every WOTS-39 wallet exposes a single tunable parameter: w. It controls the tradeoff between signature size and verification cost. The security level, 128-bit post-quantum resistance, does not move regardless of where you set it. w is purely an engineering choice.
To sign a 32-byte message hash, WOTS-39 breaks it into a sequence of digit groups. The parameter w sets the size of each digit. At w=16, each digit is 4 bits (values 0-15), so the message splits into 64 groups, each requiring its own hash chain. At w=256, each digit is 8 bits (values 0-255), so the message splits into only 32 groups, producing a smaller signature. But each chain must be longer to cover the full digit range, so the verifier performs more hash steps per chain.
w L chains Sig size Avg verify steps
──────────────────────────────────────────────────
w=4 133 4,256 B ~200
w=8 90 2,880 B ~315
w=16 67 2,144 B ~503 (recommended default)
w=32 55 1,760 B ~806
w=64 45 1,440 B ~1,395
w=128 39 1,248 B ~2,476
w=256 34 1,088 B ~4,335
w=512 31 992 B ~7,936
w=1024 28 896 B ~14,364
w=2048 26 832 B ~26,598
w=4096 24 768 B ~49,152
Every row provides exactly 2^128 post-quantum security. The security comes from SHA-256 preimage resistance, which is independent of how many chains are used or how long each one runs. A quantum adversary using Grover’s algorithm needs 2^128 hash evaluations to forge a signature whether w is 4 or 4096. w is not a security parameter: it is a performance parameter.
On EVM chains, two costs compete directly. Calldata cost is paid by the transaction sender: every byte of signature data costs gas. A smaller signature saves the sender money on every transaction. Verification cost is paid in execution gas: the smart contract must hash each chain element the correct number of steps, and more steps means more keccak256 calls.
Going from w=16 to w=256 saves 1,056 bytes of calldata (roughly 16,000 gas at standard calldata pricing) while roughly tripling the verification gas cost. On calldata-expensive L1 Ethereum, a larger w wins. On execution-heavy chains with cheap calldata, a smaller w wins.
At the extremes: w=4096 requires roughly 49,000 hash steps per verification and may exceed block gas limits on constrained chains. w=4 produces 4,256-byte signatures that can make transactions prohibitively expensive on chains with aggressive calldata pricing. The practical safe range is w=8 through w=512. Whatever you trade off with w, you never trade off security.
Three Layers of Protection
WOTS-39 does not replace classical security. It adds to it. Every transaction requires three independent proofs of authorization, each based on different mathematics, each protecting against different threats.
Layer 1: Classical ECDSA. The standard elliptic curve signature that every Ethereum wallet uses today. Fast, compact, and cheap to verify. It protects against every classical adversary, the overwhelming majority of attackers in the world today. Its one weakness is Shor’s algorithm on a quantum computer.
Layer 2: WOTS+ Signature. The post-quantum signature described above, sized between 768 and 4,256 bytes depending on w. Derived from hash functions alone and secure against both classical and quantum adversaries. Its security proof requires only that SHA-256 is a one-way function, a property no known algorithm, classical or quantum, can meaningfully challenge.
Layer 3: Lamport Chain Authorization. Quantum-secure proof that you, and only you, authorized the WOTS key upload for this transaction. It closes the final loop: even if ECDSA falls to a quantum computer, the Lamport chain ensures an attacker cannot substitute their own key. Because each chain is rooted in a unique nonce and each slot is consumed exactly once, no information from any past authorization bleeds into future ones.
The result is a wallet where every critical operation is protected by hash-function security. ECDSA provides defense-in-depth today, but the post-quantum guarantee does not depend on it.
The Seed Phrase: One Backup, Complete Recovery
All of this complexity is invisible to the user. Setup involves writing down a 12 or 24 word seed phrase, identical to the backup for any existing crypto wallet, using the same BIP-39 wordlist that every major wallet already supports.
Under the hood, that phrase seeds two independent derivation paths. The first follows the standard protocol for ECDSA keys. Your classical private key, public address, and existing wallet experience are completely unchanged. The second uses a different salt (“WOTS Seed v1” instead of “mnemonic”), producing a completely independent master secret, mskWOTS, from the same phrase. The two derivations share the same entropy but are cryptographically independent: knowing one reveals nothing about the other.
A quantum computer that breaks ECDSA could recover your classical private key from your public key. But it cannot reverse the SHA-512 hash functions standing between your private key and your seed phrase, and it cannot cross the derivation boundary to reach mskWOTS. The seed phrase remains secure. The WOTS-39 layer remains secure. The Lamport chain remains secure.
A single 12 or 24 word phrase, stored on paper, is sufficient to recover your entire wallet on any device. No second backup. No extra complexity. One phrase. Full recovery.
Why the Implementation Differs Across Chains
Bitcoin and Ethereum require fundamentally different approaches because they have fundamentally different execution models.
On Bitcoin, transaction validity is enforced at the script layer. There is no smart contract runtime. WOTS-39 on Bitcoin uses a custom witness type (P2WOTS, witness version 3) deployed on a modified Signet with consensus rules that accept WOTS witnesses. The script commits to a hash of the WOTS public key. The witness provides the signature (the partially-evaluated hash chains) and the verifier completes the chains on-chain to confirm they resolve to the committed public key. Slot consumption is tracked by scanning confirmed inputs referencing each commitment. It is entirely stateless from the protocol’s perspective: all state lives in the wallet.
On Ethereum, the account model changes everything. Smart contracts can hold state natively, which means slot consumption, key commitments, and replay protection can all live on-chain inside the account itself.
ERC-4337 implements WOTS-39 as a smart contract wallet. The account’s validateUserOp function verifies the WOTS+ proof directly, walking the hash chains, confirming the result against the stored public key commitment, and marking the consumed slot in contract storage. This requires no changes to Ethereum consensus and works with the existing bundler infrastructure today.
EIP-7702 takes a different angle. Rather than deploying a new contract account, 7702 allows an existing EOA to delegate its validation logic to a smart contract implementation for the duration of a transaction, or permanently. A wallet that has been using an ECDSA key since 2019 can upgrade to WOTS-39 validation without moving funds or abandoning its address. This is the migration path for existing Ethereum users who want quantum safety without starting over.
What Is Live
All three implementations are deployed and functional today.
Bitcoin Signet: A full P2WOTS wallet running on a custom Signet. Supports HD derivation, multi-address scanning, UTXO management, transaction construction and broadcast, faucet, and block explorer. Slot tracking runs both locally and against on-chain signature counts. Live at block_opuslux.ar.io, hosted on the Arweave permaweb, API served over HTTPS from the Signet node.
ERC-4337: WOTS-39 smart contract wallet on [testnet]. The validateUserOp verifier is written in Solidity and tested via Foundry. Bundler-compatible with no modifications to the 4337 stack.
EIP-7702: Native account upgrade path on [testnet]. Existing EOAs can delegate to the WOTS-39 verifier contract, gaining post-quantum signature validation without an address change or fund migration.
Repo: https://github.com/opus-lux/wots39
Website: https://block_opuslux.ar.io
Interested in feedback from anyone thinking seriously about post-quantum account abstraction, particularly on the ERC-4337 validator gas profile and whether EIP-7702 style upgrades are the right long-term migration primitive for existing EOAs.