Q-FABLE
Documentation

What q-fable is

q-fable is a Solana token with a treasury that cannot be opened by a signature. The treasury is a program account whose only lock is a 32 byte hash, the root of a tree built over 1,024 salted lines of a fable written by Claude Fable 5.1. Spending from it means revealing the next line. The site you are reading does three jobs: it tracks the token live, it reads every line that has been revealed and checks it against the root, and it explains the design in enough detail that you could rebuild the checks yourself.

The risk it answers

Solana wallets are protected by ed25519 signatures, and a Solana address is the wallet's public key in plain view. A quantum computer large enough to run Shor's algorithm could work a private key out of a public one. No such machine exists today and nobody can say when one will. The danger is not gradual. On the day it works, every balance behind an ordinary key is exposed at the same moment. A treasury that plans to exist for years has to decide what it wants to be standing behind on that day.

Why hashes

Hash functions are the one piece of today's cryptography that quantum computing dents instead of breaks. Grover's algorithm halves the effective strength of a hash, so SHA-256 keeps about 128 bits of security against a quantum attacker, which is still out of reach. A hash signature needs nothing else. You commit to a secret by publishing its hash, and you sign by showing the secret. It works once per secret, which is a nuisance for a wallet and exactly right for a treasury that wants a fixed number of moves.

The fable

The secrets in this scheme are sentences. Before launch the model wrote 1,024 lines that read in order as one story. A sentence alone could be guessed, so every line is hashed together with 32 random bytes of salt, and the salt is what makes it unguessable. The lines were fixed the moment the root went on chain. Nobody, including the model, can change a line, reorder the story or add to it without producing a different root, and the program holds only the one it was given.

Leaves and openings

Each line sits in a leaf with four salts, one per action. Hashing the line with a salt gives an opening, the four openings hash into the leaf, and ten rounds of pairwise hashing take 1,024 leaves down to one root. Opening a leaf means revealing the line and one salt, plus the three other openings as bare hashes and the ten sibling hashes on the way up. That is 480 bytes of proof and one sentence. The program recomputes the root from them and compares.

The four actions

A leaf can be opened for a buyback, a burn, a distribution or a seal. A buyback swaps vault SOL for the token. A burn destroys the tokens the vault holds. A distribution pays vault SOL to holders by balance. A seal pulls waiting creator fees into the vault. The program has those four instructions for spending and no others, and the size of each is set by the program, so the open decisions are which action and when.

Exposed and sealed

Creator fees land in an ordinary wallet before they reach the vault. That balance is called exposed, because an ordinary key guards it. Sealed is whatever is inside the vault. Moving fees from one to the other costs a line of the fable, so the split between them is a running record of how the model has traded safety against its remaining moves. Both balances are plain SOL balances of two addresses listed on the first page, and anyone can read them from any explorer.

The trap

A one time key that is used twice gives itself away. The vault turns that into a guarantee. If two different openings of the same leaf ever become public, anyone can present both to the program and take the vault's full balance. The keeper is the only party who could cause that, by trying to act twice on one line, so the keeper is the only party the trap is aimed at. The site reads every record on the vault and reports any leaf with two valid openings.

Reading this site

Every figure is live or empty. Token figures come from a market data feed once a second. Vault figures come from Solana itself: the root record, the revealed lines and the balances are read from chain and each line is verified with SHA-256 before it is shown. Amounts are taken from the vault's balance change inside each transaction, never from a claim in a log. Nothing on the site can be clicked except the page links and the links to an explorer, because the site has no power over the vault and neither do you.

Limits and trust

You can verify that the lines were committed before launch, that every revealed line belongs to the committed set, that each leaf was used once, and how much moved each time. You cannot verify from the chain who wrote the lines or who chose each move, and the salts are held off chain by the keeper that calls the model. If the salts leak, leaves can be spent by the wrong hands. If they are lost, the vault is shut for good. And the vault being quantum safe does not make the rest of Solana quantum safe. This is one treasury that chose its lock carefully, described as plainly as we can.