What the program cannot do

There is no instruction in this program that moves a pool's SOL or tokens to an admin. Not a disabled one, not a timelocked one — it does not exist in the bytecode.

Only two signers can ever move a pool's funds. The vault PDA pays the locker, creator, or treasury that earned a specific amount. The pool PDA returns locked tokens to their owner or burns an early-exit penalty. Neither can be directed by an admin key.

The fee split, multiplier curve, lock bounds, exit penalty, release window and treasury address are copied onto the pool at creation, and nothing rewrites them afterwards. We can change the defaults that apply to coins launched later. We cannot reach into a pool that already exists.

There is a pause switch. It is read by exactly one instruction — the one that creates new pools. Claim, unlock, extend and deposit do not even load the config account, so there is no code path by which a paused platform could hold your position hostage.

A pool cannot be created without the creator's own locked position, opened in the same instruction. The amount and the term are public on the coin's page from its first block.

A pool can also only be created by the person who actually launched the coin: the program reads pump.fun's own BondingCurve.creator record and requires it to match the signer. Nobody can squat your coin's pool and collect its creator share.

A lock vault holds someone else's tokens for up to a year. Any mint that lets a third party interfere with that is rejected at pool creation: freeze authority, transfer fees, transfer hooks, permanent delegates, non-transferable tokens, default-frozen accounts.

The check is an allow-list, so a token extension invented after this program was compiled is rejected rather than waved through.

Rounding always favours the pool. When fees are spread across weight, the amount the pool sets aside is rounded up from the credit it hands out, while each position's claim is rounded down. Each position keeps its own sub-lamport residue rather than rounding to whole lamports, which is what stops many positions from each rounding up until the pool owes more than it holds.

A randomised test drives a pool through thousands of locks, deposits, claims and exits and asserts, after every single step, that the vault can still pay everyone it owes. A second test hammers the same property with hundreds of uneven deposits.

A full pre-deployment review covered the entire program: every account constraint, every arithmetic site, the Sealevel attack checklist, and the accounting invariants re-derived by hand.

It found fourteen issues — one critical, three high, one medium. All of them are fixed, and each fix carries a regression test that fails against the old code. The critical one let a matured position mint full-multiplier weight with no remaining lock term; the highest-value fix was making rewards stream over time rather than land in an instant that could be chosen by whoever was watching.

That review was internal. An independent external audit has not yet happened, and this page will say so until it has.

• The coin can go to zero. Locking makes that worse, because you cannot sell into the decline without burning part of your bag. VISE changes who receives trading fees; it does not make a bad coin good.
• A coin with no volume pays nothing. There is no emission, no inflation and no treasury subsidy. Yield here is other people trading.
• The upgrade authority is a real authority. The program can be upgraded by whoever holds it. It belongs to a multisig, and burning it entirely is the end state — but until that happens, saying otherwise would be a lie.
• The app fee depends on our front-end. It is enforced by the transaction our API builds. If the API is compromised, the fee it attaches could be changed — though it still can only ever pay into the coin's own vault.

Program: VisecyrWrgtRg9wYhXe9ZgJ4tJBD9dPLCHoqXc54FRb

Read the source, or read the tests — they are the shorter route to knowing whether the guarantees on this page hold.