Docs
Reference for how the protocol works: where fees are assigned, what the keeper does with them each minute, and how the Bitcoin-paired pools behave.
The model
A constant product pool holds reserves x and y with x·y = k. Every trade moves along that curve, and how far a given trade moves the price is set entirely by how large the reserves are. Depth is the product k, and trading alone never changes it: a swap moves value between x and y while leaving k where it was.
Standard launchpads set k once at migration and never touch it again. A token that does a hundred million in volume has the same price impact on day two hundred as it did on day one. The only way k grows is if somebody deposits into both sides.
This protocol makes that deposit automatic and funds it from the token’s own creator fees. Trading generates fees, fees buy both sides, both sides are deposited, k rises. Volume becomes the thing that pays for depth.
Fee assignment
pump.fun stores a coin creator address on each bonding curve, set in the create instruction and immutable afterwards. The creator share of every trade accrues to a program account derived from it.
At launch the protocol generates a keypair for that token alone and passes its public key as the coin creator. The fees are therefore addressed to the protocol from the first trade, with no claiming step for the launcher and no way to change the assignment afterwards.
Because the address is unique to the token, its fees can only ever buy that token and cbBTC. Nothing is commingled and nothing is routed elsewhere.
The sweep cycle
Once a minute the keeper walks every active token. For each one it reads the pending creator rewards first, which is what makes the loop affordable at launchpad scale: a token with nothing accrued costs a single account read rather than a transaction that would fail anyway.
Anything above the deployment minimum is claimed with collectCoinCreatorFee, moving the SOL into that token’s address. Cycles are serialised per token: if one overruns the interval the next is skipped rather than queued, since two concurrent runs would attempt to spend the same claimed balance.
The split
A gas reserve is withheld to pay for the transactions this cycle is about to send. The remainder is halved. One half buys the token, the other buys cbBTC.
The split has to be even, or close to it, because a CPMM deposit requires both sides in the pool’s current ratio. Buying disproportionately would leave one side stranded outside the pool.
Routing
Both halves route through the Jupiter aggregator as ordinary market buys. They are not transfers from inventory, which is why the buy pressure appears in the token’s own chart alongside everyone else’s.
Deposit amounts are taken from measured balance changes after each swap rather than from the quotes, so the protocol only ever deposits what it actually received.
Pool creation
Both sides are deposited into a Raydium CPMM pool holding the token against cbBTC, built through the Raydium SDK.
The pool address is a program-derived address of the two mints, which means there is exactly one pool per token and it can always be found again. The first sweep creates it and its deposited ratio sets the opening price. Every sweep after deposits into that same pool at the prevailing ratio, sized from the token side so the deposit cannot revert on a ratio that moved between the swap and the deposit.
Compounding depth
The consequence of depositing rather than extracting is that k is monotonic. It never falls, and it rises in proportion to volume the token has already done.
Modelled at $250k daily volume with 5 bps of it reaching the fee address, against a $12k opening pool. The flat line is every other launchpad: seeded once, unchanged forever. Illustrative, not a forecast.
Price impact
Depth is only interesting for what it does to trading. On a constant product curve a buy of size dx against reserve x moves price by dx / (x + dx), so the same trade costs less as reserves grow.
Straight from x·y=k: impact is the trade divided by the reserve it hits, so it falls as reserves grow. Deposits do not raise the price of your token. They reduce what every future trade moves it by.
The pair
Every token launched here is paired against cbBTC, Coinbase Wrapped BTC, at mint cbbtcf3aa214zXHbiAZQwf4122FBYbraNdFqgw4iMij. There is no selection step and no way to change it later. Fixing the pair is what guarantees every sweep lands in the same pool, and fixing it protocol-wide means no launcher can bind their liquidity forever to an asset that does not survive.
It is chosen over wBTC (Wormhole) and zBTC (Zeus) on depth. The keeper buys into this market once a minute for the life of every token on the launchpad, so that recurring flow has to land somewhere it will not drift the price, and cbBTCis the deepest BTC market on Solana by a wide margin. It is also a classic SPL mint rather than Token-2022, which is what lets Raydium’s CPMM pool it at all.
The trade is custody. cbBTC is custodied by Coinbase, which holds the mint and freeze authority on the mint. Pools here are held permanently, so that is a counterparty risk rather than a theoretical one. The trust-minimised wrappers have no freeze authority and would be the safer choice on that axis alone; they are an order of magnitude thinner, and depth is what this mechanism consumes.
Mint safety
A pool here is held indefinitely and added to forever, so the standard for a counter asset is higher than for a trade you can exit. The mint account is read directly from the chain, not from a third-party score, and a mint that cannot be read is treated as unsafe rather than waved through.
cbBTC is a named exception to two of the checks below. Every wrapped-BTC mint in existence holds a mint authority, since a bridge that could not mint on deposit would be a bridge nobody could use, and cbBTC additionally holds a freeze authority. Those two are reported as disclosures rather than treated as disqualifying, for that one address only. Every other check still applies to it in full.
Freeze authority
Mint authority
Permanent delegate
Transfer hook and transfer fee
Thresholds
The parameters the cycle runs against. Deployment minimums exist because trading spread is a fixed cost: below a certain claim size, buying and depositing costs more than the claim is worth.
- Cycle interval
- 60s
- How often every managed token is evaluated.
- Split
- 50 / 50
- Token buyback against cbBTC, per claim.
- Minimum deployment
- 0.02 SOL
- Claims below this accrue rather than deploy, so spread does not exceed the amount.
- Gas reserve
- 0.015 SOL
- Withheld from each claim to fund that cycle's own transactions.
- Slippage bound
- 3%
- Applied to both market buys and to the deposit ratio.
- Pool rent reserve
- 0.25 SOL
- Withheld from the first sweep to open the pool.
- Pools per token
- 1
- Created once, deposited into thereafter.
Risks
The part to read properly.
Impermanent loss
The pair is a custodial wrapper
Positions are owned, not burned
The first deposit sets the opening price
Automation means live keys
Depth is not price
Glossary
- Coin creator
- The address stored on a pump.fun bonding curve that the creator share of trading fees accrues to. Set once, in the create instruction.
- Creator rewards
- The accrued fees themselves, held in a program account derived from the coin creator address until claimed.
- Sweep
- One run of the cycle for one token: claim, buy both sides, deposit.
- Counter asset
- The non-protocol side of a pool. Here it is always cbBTC, for every token, permanently.
- CPMM
- Constant product market maker. Reserves x and y satisfy x·y = k across every trade, so k is the measure of depth.
- Keeper
- The process that runs the cycle for every token on the launchpad, once a minute.
