When you send a transaction on Solana you prove you own the wallet with an ed25519 signature. The safety of that signature rests on one hard problem: given a public key, find the private key. On ordinary computers that problem would take longer than the age of the universe.
In 1994 Peter Shor showed that a quantum computer solves that exact family of problems efficiently. The machine needed does not exist yet. It needs thousands of error corrected qubits and today's devices are far from that. But the algorithm is settled mathematics, and the only open question is engineering.
Solana makes the exposure plain, because a Solana address is the public key itself. There is no hash in front of it. Every funded wallet has already published the one thing an attacker with such a machine would need.
A hash function has no hidden structure for Shor's algorithm to use. The best quantum attack against finding the input of a hash is Grover's search, which turns a search over 2 to the 256 possibilities into roughly 2 to the 128 steps. That is still far outside anything physical.
So if the only thing protecting your funds is "nobody can find the input that hashes to this output", you are on ground that quantum computers do not move much. Hash based signatures are built on that and nothing else. They are the oldest post quantum signatures and the most conservative.
| What protects it | Classical attack | Quantum attack | Status |
|---|---|---|---|
| ed25519 signature | about 2^126 steps | polynomial time with Shor | breaks on a large machine |
| SHA-256 preimage | about 2^256 steps | about 2^128 steps with Grover | holds |
The key was built once, before the token launched, and it can never be rebuilt or extended.
First the model wrote the fable: 1,024 lines, each a single sentence of at most 160 characters, numbered 0 to 1,023. Then four random salts of 32 bytes were drawn for every line, one for each action. That is 4,096 salts in total. Then the hashing, which is the same for every leaf:
| Step | Input | Output |
|---|---|---|
| opening | byte 0x00, the action number as one byte, the leaf number as four bytes, the salt, the line | 32 bytes, four per leaf |
| leaf | byte 0x02, then the four openings in action order | 32 bytes, 1,024 in all |
| pair | byte 0x01, then a left hash and a right hash | 32 bytes |
| repeat | 1,024 leaves become 512, then 256, down to 1 | ten levels |
| root | the last hash standing | 32 bytes, posted on chain |
The tag bytes at the front keep the three kinds of hash apart, so an opening can never be passed off as a leaf or a leaf as an inner node. Putting the leaf number inside the opening ties each line to its place in the story, so line 41 can only ever open leaf 41.
The drawing shows the path the most recent leaf takes to the root. Each row is one level. The marked cell is the hash being carried upward and the cell beside it is the sibling supplied in the record.
When a leaf is spent, the vault program writes one line of text into the transaction log. It starts with the tag qf1 and its fields are separated by upright bars. This site finds those lines by reading the transactions of the vault account and nothing else. A record that does not hash to the root is thrown away, so nobody can plant a fake one.
| Field | Length | Meaning |
|---|---|---|
| qf1 | 3 chars | format tag |
| leaf | 4 chars | record kind |
| index | 1 to 4 digits | which leaf, 0 to 1,023 |
| k | 1 digit | which action: 0 buyback, 1 burn, 2 distribution, 3 seal |
| salt | 64 hex | the salt for that action |
| others | 192 hex | the three openings that stay closed |
| path | 640 hex | ten sibling hashes, bottom first |
| line | up to 160 chars | the sentence |
The root record is shorter: the tag, the word root, the 64 hex root, the number of leaves, and the address of the vault. It must be signed by the wallet that created the token and it must touch the beacon address, which is how this site finds it without being told where to look.
The table below is computed in your browser, right now, from the latest record on chain. Nothing in it comes from our server except the record itself. If the last row says the roots match, the line is genuine.
| Step | Side | Hash |
|---|---|---|
| line | ||
| salt | ||
| opening | ||
| leaf | ||
| level 0 | ||
| level 1 | ||
| level 2 | ||
| level 3 | ||
| level 4 | ||
| level 5 | ||
| level 6 | ||
| level 7 | ||
| level 8 | ||
| level 9 | ||
| root on chain |
A leaf can be opened in four ways and the vault program does exactly one thing for each. There is no fifth instruction and no admin path.
| Action | What the vault does | What changes on chain |
|---|---|---|
| buyback | swaps SOL from the vault for the token and keeps the tokens in the vault | vault SOL falls, vault tokens rise |
| burn | destroys tokens the vault is holding | vault tokens fall, total supply falls |
| distribution | sends SOL from the vault to holders in proportion to their balance | vault SOL falls |
| seal | pulls the exposed fee balance into the vault | vault SOL rises, exposed falls |
The size of each move is not chosen freely either. A buyback or a distribution spends a share of the vault fixed by the program, and a burn destroys everything the vault holds at that moment. The only real choices are which of the four to make and whether now is worth a line.
| Action | Count | Sol in | Sol out | Tokens in | Tokens out |
|---|---|---|---|---|---|
| buyback | |||||
| burn | |||||
| distribution | |||||
| seal | |||||
| all |
There is no schedule. Nothing wakes on the hour. The keeper watches the exposed balance, and when trading has pushed enough fees into it to cover the cost of asking, it calls Claude Fable 5.1 through the ordinary public API. The call is paid for out of those same fees, so a token nobody trades is a model nobody wakes.
The model is shown the state you can see on this site: the price and its recent path, the exposed and sealed balances, the trades since the last seal, how many leaves are left and what the earlier ones were spent on. It answers with one of five choices: one of the four actions, or wait. Wait costs nothing and spends no line. Any other answer spends the next leaf, and the keeper builds the opening and sends it.
The model does not hold the salts and never sees one. It cannot be talked into leaking the key because the key is not in the room with it.
The seal is the action that most directly answers the quantum question, so it is worth walking through. Fees arrive in the creator wallet. That wallet has an ordinary keypair, which the vault program has been given standing permission to draw from and which is used for nothing else. When the model chooses seal, the opening for action 3 of the next leaf is revealed, the program checks it against the root, and the exposed balance moves into the vault in the same transaction.
From then on that SOL can leave the vault only through a buyback or a distribution, each of which needs its own line. No signature moves it. A machine that could forge the creator wallet's signature tomorrow would find whatever had not yet been sealed, and nothing more.
One honest detail. A Solana transaction always needs a fee payer, and the fee payer signs with an ordinary key. That key pays a fraction of a cent for the transaction and has no power over the vault. Forging it would let an attacker pay for transactions on the keeper's behalf, and that is all.
| Leaf | When | Sol sealed | Line | Tx |
|---|
Suppose leaf 200 was opened for a burn. The burn opening is now public: the line and salt 1. The other three openings of leaf 200 are public only as hashes. For leaf 200 to be opened again, for a buyback say, someone would have to reveal salt 0. Only the keeper has it.
If salt 0 for leaf 200 ever appears on chain, in any transaction, successful or not, then two different openings of the same leaf are public. The vault program has one instruction that takes exactly that as its input: a leaf number, two different actions, both salts, the line and the path. If both openings check out against the root, the program sends the vault's entire balance to whoever called it.
So the rule that a leaf is used once is not enforced by trust. It is enforced by a bounty that anyone can claim, funded by the whole treasury. This site flags any leaf for which it has read two valid openings.
Leaf 1,023 is the last. The program treats it differently from the others: whatever action it is opened for, the program first carries out that action and then burns every token left in the vault and closes the vault's ability to accept openings. After that the root guards nothing and the story is complete and public, all 1,024 lines of it.
Nobody can add leaves. A new root would be a new key, and the program stores exactly one root, written once.
This design protects the vault, not the chain. If elliptic curve signatures fall, Solana itself has to change how transactions are authorized, and until it does the network around the vault is in trouble that no single program can fix. What the fable guarantees is narrower: the funds inside the vault cannot be moved by forging a signature, because no signature moves them.
The salts are a secret that lives off chain. If they leak, the leaker can spend leaves. If they are lost, the vault is sealed early with everything inside it. Both are real risks and neither is hidden.
And the exposed side stays exposed until a line is spent to seal it. A treasury that is all exposed and has many leaves left is making a bet that the machine is far away. You can read that bet off the first page at any second.