How hash-based signatures can be adapted to Solana's transaction limits, using the OPEQ wallet as a worked example.
1. Why quantum computing matters for blockchain keys
Most public blockchains rely on classical elliptic-curve cryptography, such as Ed25519 on Solana and secp256k1 on Ethereum. These schemes are secure against today's computers, but Shor's algorithm, run on a sufficiently large fault-tolerant quantum computer, could derive a private key from its public key. No such machine exists today, and estimates of when one might appear vary widely. The concern is nonetheless taken seriously, especially on Solana, where an account address is its Ed25519 public key — meaning the key material needed for an attack is visible on-chain from the moment an address is used or funded.
Several responses have been discussed. The first is a network-wide migration to post-quantum signatures, which requires protocol changes and a coordinated hard fork. The second is moving funds into offline storage, which limits exposure but makes active use of DeFi difficult. A third option is implementing post-quantum verification inside an on-chain program, so that no protocol change is needed. OPEQ, currently deployed on Solana devnet, is a project that follows this third approach, and this article uses it to illustrate the design trade-offs.
2. Key design elements
2.1 Keyless custody through PDAs
Solana Program-Derived Addresses (PDAs) are generated off the Ed25519 curve, so they have no corresponding private key. In OPEQ's design, the wallet address is a PDA, and the wallet program authorizes transfers through Solana's cross-program invocation mechanism (invoke_signed) — but only after a hash-based signature has been verified. Other programs, such as token programs and AMMs, treat the PDA as a normal signer.
This removes the elliptic-curve attack surface from the vault itself. Security shifts to the program's signature-verification logic and to the secrecy of the recovery words.
Each wallet uses two on-chain accounts:
- A state account, owned by the program, holding the Merkle root, a public seed, the next leaf index, and the epoch.
- The wallet PDA itself, which holds the assets and carries no data of its own.
2.2 Fitting a signature into 1,232 bytes
A serialized Solana transaction is capped at 1,232 bytes. Lattice-based schemes such as ML-DSA produce multi-kilobyte signatures that do not fit. Hash-based schemes are more compact, but they come with other constraints.
| Component | Parameter | Size |
|---|---|---|
| One-time signature | WOTS+ with n = 16 bytes, w = 256 (16 message chains + 2 checksum chains) | 288 bytes |
| Merkle authentication path | Height-10 tree (10 × 16-byte siblings) | 160 bytes |
| Total signature material | 448 bytes | |
| Hash function | SHA-256 truncated to 16 bytes, tweaked with a per-account public seed and address field, following the SPHINCS+ / SLH-DSA style | |
| Security target | About 128-bit classical / 64-bit quantum security per one-time key, same category as SLH-DSA-128 |
The signed message binds the program ID, account ID, epoch, leaf index, an expiry slot (capped at 300 slots ahead on-chain), and every inner instruction's full content.
2.3 Salt grinding and compute cost
The client searches a 32-bit salt before submitting a transaction. A good salt produces a message digest whose WOTS+ chains are short, reducing the number of hash steps the on-chain verifier must execute. The project reports that this brings verification down to about 1,275 hash steps — roughly 160,000 CU for a standard transfer and 200,000 CU for a Raydium swap.
2.4 Merkle key trees and rekeying
WOTS+ is a one-time signature scheme, so each key may sign only once. Merkle trees address this by committing to many one-time keys under a single root. Each OPEQ tree has 1,024 leaves. The last 16 are reserved for rekeying, leaving 1,008 usable signatures per tree. When a tree is nearly exhausted, a rekey transaction mounts a fresh tree while the wallet address and balances stay the same. All trees derive from a single 256-bit master seed displayed as a standard 24-word BIP39 phrase, which does not change even after many rekeys.
2.5 Separating fees from custody
Network fees are paid by a separate Ed25519 fee key derived from the same recovery words. It has no authority over the wallet; the wallet tops it up from inside its own signed transactions. If that key were broken, the loss would be limited to its fee balance.
3. Comparing approaches
| Dimension | Conventional wallets (e.g., Phantom) | One-time Winternitz Vault | Hash-based smart wallet (OPEQ-style) |
|---|---|---|---|
| Quantum resistance | Vulnerable to Shor's algorithm | Hash-based | Hash-based; depends on parameters and implementation |
| Suitable usage | Everyday use | Infrequent signing, cold storage | Everyday use, within per-tree signature limits |
| Key reuse | Unlimited | Fresh vault for each spend | 1,008 signatures per tree, then rekey |
| Address stability | Static | Changes with each new vault | Static across rekeys |
| Signature size | 64 bytes | Scheme-specific | 448 bytes |
| Protocol changes | None | None | None, but requires trusting an on-chain program |
| Maturity | Widely deployed | Optional add-on, limited use | Devnet |
4. Trade-offs and open questions
- Stateful key management. Stateful hash-based signatures must never reuse a one-time key. Backups, multi-device use, and interrupted transactions all require careful handling. OPEQ mitigates this with a single active device policy and an on-chain counter, but the risk is inherent to the design.
- Security margin. A 16-byte hash output keeps signatures compact, but gives a smaller quantum security margin (64 bits) than a 32-byte parameter set would. This is a deliberate trade-off between size and security depth, and it deserves independent cryptographic review.
- Trust in program logic. The PDA removes the private key, but security now rests on the wallet program's correctness and its upgrade authority. The upgrade authority is itself an OPEQ quantum-safe wallet, so a broken Ed25519 key cannot alter the code. On devnet, this authority is a single admin wallet held by the developer; the mainnet governance model — either an immutable program or a multisig with a timelock — is listed as an open design decision.
- Signature budget. A finite number of signatures per tree means periodic rekeying, which adds a transaction and a small cost.
- Remaining exposure. The fee key and any assets held in ordinary Ed25519 accounts remain classically vulnerable.
5. Outlook
Whether and when quantum computers will threaten blockchain signatures remains uncertain. Even so, protecting long-lived assets before the threat materializes is a reasonable engineering goal. Approaches that avoid hard forks, like the one described here, are a meaningful step, but they also introduce complexity and new trust assumptions — stateful keys, a custom on-chain verifier, and upgrade governance.
When evaluating such a system, the things to look for include external audit reports, parameter justification, a defined upgrade-governance model, and an operational track record on mainnet. Native, protocol-level post-quantum migration is likely to remain an active research and governance topic in the meantime.
Top comments (0)