Everything that is actually true about $NOBACKSIES, including the parts that are inconvenient. If anything on the front page seems to promise more than this page does, this page wins.
You can sell any time the pool is trading. It is the liquidity that is locked, not your tokens — but see who can change the rules.
Strip the cartoon off and there is one mechanism here. A normal AMM collects a fee on every swap and parks it in a balance somebody can later claim. Jarold’s pool is set to compounding mode, so the pool’s share of that fee is added back to the liquidity itself — and the LP position holding it is permanently locked, so in the current program there is no instruction anyone can call to take the liquidity back out. Our fee share is a separate thing, claimed from the position rather than withdrawn from it, and Meteora takes its protocol cut before either of us sees anything.
Together those two settings make pool depth a one-way function:
Compounding mode is Meteora’s feature, not ours. What is unusual is pairing it with a full permanent lock — normally fees are compounded so that someone can eventually withdraw a bigger position. Removing that exit is the whole idea.
| phase | Meteora | into the pool | to us |
|---|---|---|---|
| bonding curve | 20% | nothing | 80% |
| after graduation | 20% | 40% | 40% |
Measured, not assumed: protocol_fee_percent reads
20 on all 8,835 Compounding pools on mainnet — a census, not a sample.
Reproduce it with node src/record-chain-evidence.js; the slot, the program
hashes and the exact query are recorded in launch/evidence-chain.json. Our 40% works out to 0.40%–0.48% of volume;
traders pay 1.00%–1.20%. The spread in both is the volatility fee, which is split
the same way as the base fee. During the curve phase nothing compounds — compounding
only exists in the graduated pool.
Meteora adds the compounded fee to the pool’s SOL only — never to the token side. The pool holds more SOL against the same tokens, so the price rises. It does not make a sell-off hurt less: how far a dump moves the price depends on the token side, which never grows.
| round-trip volume | SOL in pool | price | to us | 2% dump |
|---|---|---|---|---|
| at launch | 110 SOL | 1.00× | 0 SOL | −18.8% |
| 5,000 SOL | 129 SOL | 1.17× | 20 SOL | −18.8% |
| 25,000 SOL | 206 SOL | 1.88× | 100 SOL | −18.8% |
| 100,000 SOL | 500 SOL | 4.56× | 398 SOL | −18.8% |
Equal buys and sells, no net buying. A pool that pays all its fees out ends every row at 110 SOL and 1.00×. The “to us” column is our 40% of the fee — 0.40% to 0.48% of volume, the range being the volatility fee — and we would rather print it than have you find it. The dump column does not move: a fuller jar is not protection. Assumes the pool keeps 80% after Meteora’s cut, which we have not measured, and the pool’s SOL still falls if people are net sellers.
compoundingFeeBps 5000) and claim the other half. The measured protocol cut will be published after devnet.tokenAuthorityOption: Immutable, so there is no mint authority. We verify mint, freeze and metadata authority are all null on devnet before launching.Everything on this page is true under the programs as they are deployed today. Those programs belong to Meteora, not to us. Here is exactly who can change what, and what nobody can change.
The bonding-curve program and the pool program are both upgradeable by a
single upgrade authority, JADaUV8kvDpDbJr55wxXJHVaBS3VCj8thZZHjfeuCVLd — read
straight from each program’s ProgramData account and recorded in
launch/evidence-chain.json. It is an off-curve address, so a program-derived
account rather than a plain keypair. (We previously called it a 4-of-7 multisig; we cannot
decode that account with the tools here, so the threshold claim is withdrawn.) Whoever
controls it can replace the code that enforces everything below. “Forever” on this
page means forever under the current programs.
The 50/50 split is compounding_fee_bps, which becomes ordinary pool
state at migration. A single Meteora admin key can rewrite it with one signature,
no program upgrade, no multisig vote, no timelock. Said plainly: if it were set
to 0, the whole LP fee share would become claimable by us instead of staying in the
pool. We would not have to do anything for that to happen, and we cannot prevent
it. It is set by us at launch and changeable by Meteora afterwards.
A single operator key can set the pool’s status to disabled. While a pool is paused, nobody can buy or sell — that is why the front page says you can sell any time the pool is trading rather than simply any time.
The right to claim our 40% lives in a position NFT, and that NFT can be moved. We could move or sell the right to claim it. The liquidity stays locked no matter who holds it — a new holder inherits the fee stream, not the capital.
Withdraw the locked liquidity. The lock is meant to be enforced by the program
itself rather than by convention — but we are not publishing a number for it here,
because the simulation that would establish it is not yet reproducible from this
repository. It is recorded as lockEnforcement: NOT RUN in
launch/evidence-chain.json, with the exact method written out, and the
launch gate refuses to pass until that script has run and recorded its output.
Until then, treat this as a design claim and not as a measurement.
One honest nuance: split_position can move permanently
locked liquidity to another position, where it stays permanently locked. It cannot
withdraw it. The locked LP is immobile as capital but transferable as an asset.
One run settles every remaining unknown. None of it has been done yet.
A census of every Compounding pool on mainnet finds
1,121 of 8,835 (13%) using a permanent liquidity lock. An earlier version of this page said a
41-pool sample found zero; that was wrong, and the census replaces it. We check the permanent-lock
setting only, not vesting or time locks, so the claim is about permanent locks and nothing else. The
combination here is uncommon rather than unheard of — still its own risk, and still the reason the
gate exists. Reproduce with node src/record-chain-evidence.js.