Inside the bunker.

The threat

Every Solana wallet is an ed25519 key pair. Its security rests on elliptic-curve math that ordinary computers can't solve. A large, error-corrected quantum computer running Shor's algorithm could. It would work out a private key from the public key, and every public key on Solana is already on-chain.

Nobody knows when such a machine will exist. The day it does is usually called Q-Day. Funds that move only with an ed25519 signature are exposed from that day on.

Why hashes

SHA-256 maps inputs to a 32-byte digest. Recovering a preimage is computationally infeasible under current assumptions. The best known quantum attack on hashes, Grover's algorithm, only gives a square-root speedup, which a large enough hash absorbs. Signatures built only from hashes have been studied for decades and are part of the post-quantum standards (SPHINCS+ / SLH-DSA).

Winternitz chains

A Winternitz one-time key is a set of secrets. Each secret is hashed 15 times to form a chain. The ends of all chains are hashed together into one commitment.

To sign, you hash the message and read it as 64 digits from 0 to 15. For each digit you reveal that chain at that step. A verifier hashes each revealed value the remaining steps and checks the result folds into the commitment. Three extra checksum chains stop anyone from pushing chains further to forge a different message. Try it in the key lab.

How a bunker opens

1. The proposed bunker account would store the hash-based verification commitment and custody state, rather than relying on an ordinary wallet key for withdrawals.
2. You build a withdrawal (amount, destination, nonce) and sign it with your one-time key, in your browser.
3. The bunker program recomputes the chains on-chain and checks they reach the stored commitment.
4. If they match, the SOL moves and the stored commitment is replaced by the next one you committed to.

Rotation

A Winternitz key is safe for one signature. Each one reveals part of every chain, and multiple signatures from the same key undermine the one-time security assumption and can enable forgery. So every unlock carries the commitment for your next key. The used key is dead the moment it's used, and on-chain nonce enforcement must reject replay.

Trade-offs

• Bigger signatures: about 2 KB instead of 64 bytes, so unlocks cost more compute than a normal transfer.
• You hold the secret: lose it and the bunker stays closed. There is no recovery.
• The rest of Solana: a bunker protects what's inside it. Your normal wallet still signs with ed25519.
• Unaudited: nothing here has been audited yet. Don't treat the preview as a promise.

Canonical withdrawal intents

Our executable intent module normalizes fixed-order UTF-8 JSON under the BUNKER_WITHDRAWAL domain, version 1. It binds the genesis-hash bytes, program ID, vault address, asset, base-unit amount, recipient, nonce and expiration. Every integer is a canonical decimal u64 string; addresses must decode to exactly 32 bytes.

Changing any bound field changes the digest. This identifies the exact request; it does not itself authorize a transfer. A vault program must verify a signature over the specified message and consume the nonce atomically with asset movement.

Authority graph and replay protection

The hash-based policy must govern every withdrawal route, ownership change, recovery action and verifier upgrade. An ordinary administrative key that can bypass the policy defeats the intended protection against ordinary key recovery.

For a rotating one-time scheme, the next commitment must be included in the signed request and replaced atomically. The current v1 intent encoder does not yet support a next-commitment field; that requires a reviewed specification revision before deployment.

From key lab to production verifier

The key lab is an educational Winternitz-style construction with SHA-256, w=16, 64 message chains and three checksum chains. It produces a 2,144-byte signature and a 32-byte commitment. It is not a standardized WOTS+ implementation, an audited signature system, or a deployed custody verifier.

The production research candidate remains NIST SLH-DSA, a stateless hash-based signature scheme. The browser lab explains chain verification; its successful round trip does not establish the security of a custody program. Signature size exceeds a normal Solana transaction payload, so staged transport, buffer binding, compute cost and verifier conformance must be measured.

How this follows bunker mode

The motivating bunker-mode post proposes keeping public keys hidden where possible and moving toward hash-based authorization. Ordinary Solana addresses expose their Ed25519 public keys; a fresh address does not hide them. Our proposed PDA vault follows the longer-term direction: an ordinary wallet key alone should not unlock the funds.

Speculative AI cryptanalysis is separate from the known quantum threat to elliptic-curve signatures. Neither a demonstrated AI break of Ed25519 nor a particular Q-Day timeline is established here. The vault does not repair Solana consensus cryptography.