One coin, two chains, no claim form
What RUNEPAD does, exactly, and how to check it without trusting us.
The launch
Every coin is created on StonkFun through Raydium LaunchLab with StonkFun's standard platform settings, paired against WBTC (Bitcoin on Solana), so every price, every fee and every payout is in BTC. The pool's creator, the account StonkFun forwards the creator fee to, is a vault derived from the coin's own mint address, so a coin's fees belong to that coin and to nothing else. Neither the launcher nor we can point them elsewhere later. StonkFun charges 1% on every trade; half of it, 0.5%, is the creator fee, split 5% to the launcher and 95% to the protocol.
LaunchLab mints are Token-2022 with six decimals and, from the moment the pool exists, no mint authority and no freeze authority. The bridge checks that on chain before it etches anything: a coin whose supply could still be increased would make the Bitcoin side a fiction.
The rune
Right after the launch the coin is queued for its Rune. The bridge daemon etches it in two Bitcoin transactions, as the Runes protocol requires for a chosen name: a commit that locks the name into a Taproot script, six blocks of waiting, then the reveal that carries the etching. The name is RUNE•TICKER•XXXXX, the last five letters derived from the mint address so it cannot collide with a rune someone else etched.
- No terms. There is no open mint. The supply is the premine, equal to the coin's supply on Solana, and every unit of it is sent to the reserve in the reveal. No one, including us, can create more.
- Divisibility equals decimals. One raw unit of the coin is one unit of the rune, exactly.
- An explicit pointer. The reveal points its unallocated runes at the reserve output by index, never by default.
Once the reveal confirms, the daemon verifies the etching from raw Bitcoin transactions (it does not rely on any rune indexer), records the rune id, and marks the coin live. From that Solana slot on, burns count.
Burning
From the coin's page, you enter an amount and your Taproot address and sign one transaction. It contains a BurnChecked of the coin and a memo reading runepad:v1:bc1p…. You can build the same transaction by hand with any tool; the bridge does not care where it came from, only what it says.
The verifier is strict, and every rule is mandatory:
- The transaction exists at finalized commitment and succeeded.
- Exactly one burn, inner (CPI) instructions included, of a registered mint, with a positive amount and the registered decimals.
- The burn's authority signed the transaction itself. A burn driven by a program is not your statement of intent.
- Exactly one memo, matching runepad:v1: plus a valid Taproot address for this network, and nothing else.
Every transaction is fetched from at least two independent RPC providers and verified separately. A burn is recorded only when they agree on mint, amount, destination, slot and authority. If they disagree, nothing is paid and the disagreement is published.
Delivery
Recorded burns are paid in batches, in the order they were finalized, with no discretion over who goes first. A batch is one Bitcoin transaction: an OP_RETURN runestone, one output per recipient with an edict for exactly their amount, a rune change output back to the reserve that the runestone's pointer names explicitly, and BTC change. If the runestone would not fit the relay limit, the batch is split rather than trusted to a miner.
The daemon that builds these has no keys. The transaction goes as a PSBT to a signer on a separate machine, which re-derives everything from the bytes: that the pointer is set and points at the reserve, that the edicts match the burns it knows about, that every non-recipient output pays the reserve, that no burn in the batch was ever paid before (it keeps its own record), and that the fee is sane. Only then does it sign.
Before any batch is built, the daemon checks the invariant on chain: runes in the reserve + runes delivered = the premine. If that does not hold, it stops and says so on the ledger page.
What we refuse
A refusal is recorded forever with its code, and shown on the coin's page and on the burn's own page. The codes:
| no_memo | the burn transaction carries no memo |
| multiple_memos | more than one memo: ambiguous, so none is trusted |
| malformed_memo | the memo is not exactly runepad:v1:<address> — no spaces, nothing after the address |
| bad_destination | the address is not a Taproot (bc1p…) address on this network |
| no_burn_instruction | no Burn or BurnChecked instruction in the transaction |
| multiple_burn_instructions | two burns in one transaction: which one does the memo refer to? |
| unregistered_mint | a burn of a coin that is not one of ours |
| zero_amount | a burn of zero |
| decimals_mismatch | the transaction reports different decimals than the mint was registered with |
| authority_not_signer | the burn's authority did not sign the transaction (a program or a multisig burned): the memo is not the owner's statement |
| transaction_failed | the transaction failed on chain |
| rpc_mismatch | two RPC providers disagreed about the transaction; nothing is paid until a human looks |
Refused burns are still burns: the tokens are gone. Check the memo and the address before you sign.
Auditing it yourself
The audit is a command in the open-source bridge. It does not read our database. From the published registry (each coin's mint, rune id, reveal transaction, activation slot, and the reserve address) it lists every burn of the mint on Solana through the RPCs you choose and verifies each with the same pure verifier the daemon uses; follows the rune from its etching through every reserve output on Bitcoin, decoding runestones itself; and checks that every delivery matches a burn by destination and amount, that no burn was paid twice, and that reserve + delivered = premine.
cd bridge && npm install npm run audit -- --registry registry.json --rpc https://api.mainnet-beta.solana.com,https://<your-other-provider>
It exits non-zero on any inconsistency. If only we could audit this, there would be no audit.
Custody, stated plainly
The reserve is one Taproot address controlled by one key. That is custody. Runes that have not been delivered depend on that key existing and behaving; if it were stolen, the reserve could be emptied, and if it were lost, undelivered runes would be stuck. We keep the key off the daemon's machine, publish the reserve address, and make every movement checkable, but none of that makes it trustless, and we will not describe it that way.
Your tokens on Solana are never in our custody: burning destroys them in your own wallet, and trading runs against StonkFun's curve.
Costs
- Launching: paid in WBTC: 7,000 sats to RUNEPAD, 7,000 sats for the Solana rent and fees the platform pays, and 14,000 sats toward the Bitcoin commit and reveal. StonkFun charges nothing on this path.
- Burning: the Solana transaction fee. The Bitcoin delivery, including the dust on your output, is paid by the reserve.
- Trading: StonkFun's 1% pool fee, in WBTC. The protocol's share goes to 7P48uP…w6TR.
Risk
These are memecoins. The bridge makes the Bitcoin side honest; it does not make the coin worth anything. Burns cannot be undone, a refused burn is not refunded, and a rune sent to an address that cannot handle Runes may be lost. The reserve is custodial, as stated above. Do not burn what you cannot afford to lose.