Solana keys
Every Solana wallet is an ed25519 key pair. Unlike Bitcoin or Ethereum, the address isn't a hash of the public key: it is the public key, base58-encoded. So a Solana public key is exposed from the moment the address is shared, whether or not it has ever signed.
Security rests on the elliptic-curve discrete-log problem: given the public point, find the secret scalar. No classical computer can do that for a 255-bit curve in any useful time.
Shor, Grover and q-day
Shor's algorithm (1994) solves discrete logs in polynomial time on a large, error-corrected quantum computer. That breaks ed25519 outright. How many qubits it takes depends on the circuit, error rates and error correction. A raw hardware qubit count says little on its own, and nobody can date q-day with confidence.
Hash functions face a weaker threat. Grover's algorithm gives a square-root speed-up on brute-force search, so a 256-bit preimage costs about 2128 quantum steps. That's why hash-based signatures are the most conservative post-quantum option, and why NIST standardised one (SLH-DSA) in 2024.
Chains are permanent, so the risk starts now: anyone can archive public keys today and attack them later.
Winternitz one-time signatures
plannedA Winternitz one-time signature (WOTS) starts from a list of random secrets. Hashing each secret 255 more times gives the chain ends, and the hash of all chain ends is the public key. To sign, you split the message digest into bytes and reveal each chain at the position set by its byte. A verifier hashes each revealed value the rest of the way and checks it lands on the published end.
A checksum over the digest stops forgery: pushing any message byte up would force a checksum byte down, which would mean running a hash backwards. Each key signs exactly once. Reuse leaks enough of the chains to forge.
Vaults
plannedA vault is a program-derived address seeded with the hash of a WOTS public key. Being a PDA, it is off the ed25519 curve, so there is no private key for Shor to find. The vault program releases funds only for a valid WOTS signature over the exact instruction: amount, recipient, and the next vault that receives the change.
- ▸one signature per vault; the remainder moves to a fresh vault in the same transaction
- ▸verification is hashing only, done on chain within Solana's compute limits
- ▸the program and its upgrade authority are part of what you trust; both will be published
Dev identity
plannedDevs need to sign more than once, so each gets a Merkle tree of one-time keys (the construction behind XMSS, RFC 8391). The root is registered alongside the coin's mint at launch. Each signed update uses the next unused leaf and carries its authentication path, which anyone can check with hashes alone. A valid update proves who signed it, not that its message is true.
The canary
plannedThe canary is SOL at an address nobody can sign for. We plan to make it a “nothing up my sleeve” point: hash a public phrase until the result decodes to a valid ed25519 point, then clear its small cofactor. Anyone can repeat the derivation, and nobody (including us) ever knew a private key for it.
If that SOL ever moves, someone derived a private key from a public one. That's the q-day signal every armed bunker listens for. The same wallet doubles as the bounty.
The bunker
plannedAuto-bunker: you sign an escape transaction in advance that moves chosen holdings into your vault. It is stored unsent. Solana transactions normally expire after about 150 blocks, so the escape uses a durable nonce to stay valid until it is needed. A watcher broadcasts it the moment the canary moves.
Bunker mode: skip the waiting and move into the vault now with one approval.
Known limits: tokens you receive after arming aren't covered until you re-arm, and the watcher must be online.
Launching a coin
plannedCoins launch on pump.fun. The flow is prepare → build → sign → relay → finalize: the image and metadata are uploaded, the create transaction is built, your wallet signs it, it's relayed through our RPC, and we wait for confirmation and record the coin. Qinu never sees your keys.
A launch can touch more than one transaction, and they aren't atomic. If anything fails after sending, check your wallet history before retrying, or you may create a second coin.
How the scanner scores
liveThe scanner reads an address from chain: SOL balance, SPL and Token-2022 accounts, up to the 1,000 most recent signatures, and the five newest transactions (to see whether the address signed them). Nothing is written and no wallet connection is needed.
The exposure score (0–100, higher is more exposed) is a simple, transparent heuristic:
- ▸off-curve addresses (PDAs) score 5: no private key exists
- ▸program accounts score 10
- ▸untouched addresses (no balance, no tokens, no history) score 20
- ▸otherwise start at 50, because the address is the public key
- ▸+15 if it signed one of its five newest transactions
- ▸+4 / +10 / +18 / +25 for any / ≥1 / ≥10 / ≥100 SOL
- ▸+3 / +6 / +10 for ≥1 / ≥5 / ≥20 token accounts holding a balance
- ▸capped at 100; 45+ is medium, 75+ is high
It's for comparing wallets and nudging habits, not a security audit.
Where the data comes from
live- ▸Solana reads go through our server to Helius RPC. The API key stays on the server; the browser talks to
/api/rpc, which only allows read methods. - ▸Token metadata comes from Helius DAS, with on-chain Token-2022 / Metaplex metadata as a fallback.
- ▸Price and market cap come from DexScreener's public API.
- ▸Network heartbeat (slot, TPS, epoch) refreshes every 15 seconds.
Limits and honesty
Quantum-resistant is not quantum-proof. Hash-based signatures rest on fewer assumptions than anything else we know, but no one can promise what future mathematics will find, and implementation bugs are a bigger near-term risk than quantum computers. Every program we ship will have its address and source published before we ask anyone to use it.
$QINU is a memecoin with no promise of return. Nothing on this site is financial advice.