Programmatic Liquidity

Mechanism

One loop, run once a minute against every token. Fees in at step one, a deeper market for your token at step four.

  1. 01

    Assign

    The launch transaction sets the token’s coin creator to an address the protocol generates for that token alone. pump.fun accrues the creator share of every trade to a program account derived from whatever sits in that slot, so the fee stream is pointed at the protocol from the very first trade. Your opening buy, if you make one, is bundled into the same transaction so nothing can land between the two.

  2. 02

    Claim

    Once a minute the keeper reads the pending balance for every token it manages and calls collectCoinCreatorFee on anything above the minimum, which moves the accrued SOL into that token’s address. Reading before claiming is what makes this work at launchpad scale: a token with nothing pending costs one lookup instead of a wasted transaction.

  3. 03

    Buy

    The claim is split in half and both halves route through Jupiter. One buys your token, the other buys the asset you paired with. These are ordinary market buys on the open market, not transfers out of inventory, which is why the buy pressure is visible in your token’s own chart.

  4. 04

    Pair

    Both sides are deposited into a Raydium CPMM pool holding your token against your chosen asset. There is exactly one such pool per pair: the first sweep creates it through the Raydium SDK and its deposited ratio sets the opening price, and every sweep after that deposits into the same pool. Its address is derived from the two mints, so it is always found again rather than duplicated.

One pool, not many

Worth being explicit about, because it is the part that makes the rest worth doing. Your token gets one pool per pair asset, not one per sweep. Sweep one builds it. Sweep two through ten thousand add to it. Reserves only ever go up, so slippage on your token only ever goes down, funded entirely by the volume your token already produced.

Before you launch

The parts worth understanding first.

Your pair is permanent
You choose the counter asset at launch and it cannot be changed. That is what guarantees every sweep lands in the same pool. Pick something deep: your token buys it once a minute forever, and a thin asset moves against you on your own buying.
The liquidity is owned, not burned
Positions belong to your token’s own protocol address. They are not burned and not locked. Whether that is acceptable is a governance question rather than a technical one, and it is the first thing an informed observer should ask about.
Impermanent loss is the cost of the design
Liquidity paired against a volatile asset is exposed to divergence between the two sides. If your pair falls hard against your token, the position is worth less than having held both. That is inherent to providing liquidity, not a defect the design can remove.