The vault: hash-based keys and what they protect

The desk's crypto room has a wallet, and the wallet has a second compartment called the vault. Money in the wallet address is guarded by an Ed25519 key, the same kind every Solana wallet uses. Money in the vault is guarded by something else: a signature made of nothing but SHA-256 hashes, checked by a small program the desk wrote for Solana — on the chain itself, once the program is deployed there. This page says what that is, what it protects, what it does not protect, and what it costs — so that the word "vault" on the panel means exactly one thing to you, and no more than it should. It assumes you have read holding your own keys, because everything there is still true here: the phrase is the key, there is no password reset, and nobody can call anyone.

What a hash-based signature is

An ordinary digital signature rests on arithmetic over an elliptic curve, and the post-quantum page explains why that arithmetic is the part a large quantum computer would break. A hash-based signature rests on no arithmetic at all. It uses a hash function — a function that is easy to run forward and, as far as anyone has found, cannot be run backward — and nothing else.

The simplest version is older than Bitcoin. Pick a secret random number and publish its hash. To sign a "1", reveal the secret; anyone can hash it and see that it matches what you published. You have proved you knew the preimage, and you have also spent it: the secret is public now, so the key is good for one signature. The scheme the vault uses, Winternitz one-time signatures (WOTS+ in RFC 8391's spelling), is that idea made efficient. A 32-byte message is cut into 64 half-bytes and a three-digit checksum, 67 digits in all, each between 0 and 15. For each digit the signer has a secret, hashed in a chain fifteen steps long; the end of each chain is the public key, and the signature reveals each chain at the step the digit names. The verifier walks every chain the rest of the way and compares the ends. Forging a signature would mean walking a chain backward — finding a preimage of SHA-256 — which is the one thing a hash is built to prevent.

Where this stands against a quantum computer is a question with a precise answer, and the desk gives it in the words the record uses. A hash-based signature rests on SHA-256 and nothing else. No known quantum algorithm breaks a 256-bit hash; Grover's search halves the exponent, which 256 bits absorbs. This is the construction behind NIST's SLH-DSA (FIPS 205). NIST's own report on the subject puts the two cases side by side in one table: RSA and elliptic-curve signatures, "No longer secure"; SHA-2 and SHA-3, "Larger output needed" — because Grover's algorithm "proffers a quadratic speedup on unstructured search problems", so a search that would take 2^256 steps takes about 2^128, and 128 bits is the strength the industry already accepts for everything else. NIST's standardised hash-based signature, SLH-DSA, is "based on SPHINCS+", a cousin of the vault's construction built from the same one-time signatures and trees. None of that is a promise about your money. It is a statement about which hard problem the lock rests on.

Why one key signs once, and how a tree gives 256

The cost of a one-time signature is in its name. RFC 8391 is blunt: "each private key MUST be used only once to sign a single message." Sign two different messages with one Winternitz key and you have revealed two different points on every chain; an attacker can combine them to sign a third message you never wrote. The vault treats this as the first rule, and three separate things enforce it, which the last section comes back to.

One signature per address would be a poor wallet — the address would have to change on every spend, and a deposit sent to the old one would land on a dead key. So the vault does what RFC 8391 does: it puts many one-time keys under one Merkle tree. The desk's signer derives 256 one-time keys from your phrase, hashes each one's public key down to a single leaf, pairs the leaves and hashes them up eight levels to a single root. The root is the vault's public key. A signature now carries the one-time signature and the eight sibling hashes from that leaf to the root — the authentication path — so the verifier can recompute the root from the leaf it recovered. One address, 256 spends, each on its own leaf, each leaf used once. The program on the chain keeps the counter: it stores the next leaf it will accept and refuses any other, so a signature made for leaf 7 cannot be replayed at leaf 8, and a leaf already spent is dead to everyone, including you.

When the 256 are nearly used, the panel says so from leaf 240 and from leaf 250 offers only a rotation: a last spend of the whole balance to a fresh vault built from the next tree in your phrase's sequence. The phrase derives every tree, in order, on any device, so there is no second secret to lose.

What the vault address is, and is not

Your wallet address is a public key: the Ed25519 point your signer holds the private half of. The vault address is not. It is a program derived address — in Solana's own words, one of the "deterministic, off-curve addresses derived from seeds and a program ID. No private key exists". The seeds are the vault program's name for the account, a version byte, and a hash of your tree's root, public seed and height. Because the height is in the address, nobody can create "your" vault at a different height and strand it; a different height is a different address. Because the address is off the curve, no key can ever sign for it — only the program can move what it holds, and the program moves nothing without a hash-based signature that recovers to the stored root at exactly the next leaf.

Three consequences, stated plainly on the panel and repeated here:

• Deposit from anywhere. The vault address is an ordinary Solana address to the rest of the world. Send SOL or a token to it from an exchange, from another wallet, from your own desk wallet; the address does not change with spends. Tokens land in the vault's own token accounts, which the program owns.
• Only the vault is guarded this way. Funds in your ordinary wallet address are still guarded by Ed25519, exactly as before. The vault is a compartment, not a conversion; the chain's own signatures, and every token program's, are unchanged. The post-quantum page's warning stands: a token cannot be post-quantum on a chain that is not.
• The phrase is still the whole key. The vault's secrets are derived from the same twelve words as the wallet's key, by a different road. Lose the phrase and the vault is as gone as the wallet. The wallet password you set in the signer is a local unlock for that device; it is not the key, and restoring from the phrase sets a new one.

What the program does and does not do

The TOTH Vault program is the desk's own, written from its design record, and it does four things: create a vault account for a given root, stage a signature into a scratch account in three pieces (a signature with its path is 2,404 bytes, and a Solana transaction is "1,232 bytes maximum"), verify the staged signature and pay the recipient, and let the payer of a scratch account close it. It has no owner, no pause switch, no fee, and no instruction that moves funds without a valid signature at the next leaf. It takes no public key and no digest from its input; it rebuilds the message from the parameters you asked for — program, vault, recipient, asset, amount and leaf — and recovers the key from the signature itself, so a signature over one spend is useless for any other.

Two lines on the vault card deserve your reading — the first read from the chain, at most a few minutes old, on every visit; the second fixed in the desk's code:

• The authority line. A Solana program can be changed by whoever holds its upgrade authority, or by nobody if that authority has been given up. The card reads the authority as it stands and says either "the program can be changed by the key shown here" or "the program is immutable". It shows whatever the chain reports for the program on that cluster; on devnet, where the desk rehearses, the desk expects a throwaway deployer's key. On mainnet there is no program yet; when the founder deploys one, with his own key after an independent audit, the card will show what he chose.
• The audit line. The program has not yet been independently audited. That sentence is removed only when a report is linked in the desk's code, not before and not by a flag. Until then the vault card is shown on devnet only when the founder opens it (desk flag vaultOpen), where coins have no value, and is locked on mainnet for everyone, the founder included — a lock in the same shape as the desk's live-routing lock, lifted only by two clicks whose second one names the unaudited program.

A bug in an unaudited program can lose funds. That is why the lock exists, and why the honest order is devnet first, audit second, mainnet third.

What it costs

A vault is not free, and every figure here is hypothetical and approximate — a worked example at the rates in force in November 2026, which move. The panel reads the exact numbers from the chain before you confirm anything; trust it over this page.

• Rent, once. Every Solana account must hold a minimum balance in proportion to the bytes it stores; the chain calls it rent, and Solana's documentation gives the formula: the account's size plus 128 bytes, times 3,480 lamports per byte-year, times two years. The vault account is 72 bytes, so about 1.39 million lamports — roughly 0.0014 SOL — paid when the vault is created and kept there as long as the vault exists. A spend may never take the vault below it.
• Rent, refunded. Staging a signature needs a scratch account of 2,502 bytes — by the same formula about 18.3 million lamports, roughly 0.018 SOL — which your wallet funds when the first piece is written and gets back in full when the spend lands or the account is closed. This is the figure that catches people: a wallet holding only a few thousand lamports cannot start a vault spend, and the panel says so before anything is signed, with the amount it needs, read from the chain rather than from this formula.
• Fees. A spend is four transactions — three to stage the signature, one to withdraw — and Solana charges "a base fee of 5,000 lamports per signature", so about 20,000 lamports, or 0.00002 SOL, plus the optional prioritisation fee the panel adds from recent network prices (quoted in micro-lamports per compute unit; the panel shows the figure). Verifying the signature on the chain takes about 250,000 compute units in the worst case, well inside the 1,400,000 a transaction may use.

Fees are the network's, paid in SOL, never the desk's. There is no desk fee on a vault, and no yield from one: a vault holds what you put in it.

If a spend is waiting

A one-time key must sign exactly once, so a spend that was signed but never landed — a closed window, a dropped connection, a node that would not answer — is the one situation the design has to handle carefully, and it does so by refusing to improvise. A signed spend must land before another can be made from this vault; if one is waiting, retry it. The panel shows the waiting spend and a RETRY button, and SPEND is disabled until it is settled. Retry replays the same plan: the signer returns the same signature it already made for that leaf and digest, the desk sends the same three staging pieces and the same withdraw, and the program accepts the result once. Nothing new is signed.

Three places refuse anything else, independently. The signer keeps its own record of which leaf signed which message and will not sign a different one. The desk keeps a row per vault and leaf, and refuses a new request for a leaf whose row names another message — from any device, since the row is on the desk. And the program's counter refuses a leaf it has already accepted. If you see "leaf already signed for another spend" in the signer, that is this rule working, not a fault: find the waiting spend on the panel and retry it. If the spend was for an amount or a recipient you no longer want, you cannot cancel it — the signature exists — but you can let it land and spend again; the next leaf is unspent.

What the desk holds of all this is public already: the vault's address, its root and public seed, the digest of each spend and the signatures of the transactions. The signing half of every leaf lives in the signer, derived from your phrase, and the desk has no column for it. That is the same sentence the whole wallet is built on, and the vault does not change it: TOTH never holds your keys or your funds.

• What a perpetual future is and how funding works
• Spot vs perps vs on-chain: where a trade actually happens
• Holding your own keys: what a signature proves, and what nobody should ask you for
• Liquidity pools and impermanent loss, with the arithmetic
• Staking — what you earn, what you risk, what is taxed
• Post-quantum on a token vs in a wallet: what the words can and cannot mean

← Crypto · All of Learn