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.

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 its own counter asset. Nothing is commingled and nothing is routed elsewhere.

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.

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 the counter asset.

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.

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.

Both sides are deposited into a Raydium CPMM pool holding the token against its counter asset, 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 pair 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.

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.

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.

The counter asset is chosen by the launcher and fixed for the life of the token. Fixing it is what guarantees every sweep lands in the same pool. A pair that could rotate would spread the token across a new market each time it changed, and none of them would compound.

The suggested list is curated and ranked by on-chain liquidity, volume or 24h change. Any Solana mint can be used instead by address. Depth on the counter asset matters because the token buys it every minute indefinitely, and a thin asset drifts on that recurring flow.

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.

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 counter asset, 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.

Pools per pair

1

Created once, deposited into thereafter.

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. Chosen at launch, fixed for the life of the token.

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.