How creator fees become
PumpSwap liquidity.

A technical reference for how every coin's pump.fun creator fees are claimed, split into the coin and SOL, deposited into the coin's PumpSwap pool, and locked for good with the LP burned.

Overview#

Every coin launched here is a standard pump.fun coin: minted with create_v2 on the bonding curve, Token-2022, 1,000,000,000 supply, graduating to PumpSwap when the curve completes. The only difference is who the coin's creator is.

On pump.fun the creator fee is income for whoever launched the coin. Here, the creator is a per-coin engine wallet, and a keeper process turns its income into liquidity: half the value is converted into the coin, the two sides are deposited into the coin's pool, and the LP tokens are burned.

Coin lifecycle#

The liquidity engine#

Each keeper cycle runs four steps per coin. Each step is its own transaction, simulated before it is sent.

1 · Claim#

When the creator vaults hold at least 0.01 SOL, both are swept to the engine wallet in one transaction: collect_creator_fee on the curve program (lamports) and collect_coin_creator_fee on PumpSwap (WSOL), followed by CloseAccount on the WSOL account to unwrap it to native SOL.

2 · Split#

The engine targets an inventory that is 50% coin and 50% SOL by value. Before graduation it buys on the bonding curve; after graduation it buys on PumpSwap with buyQuoteInput. The buy size comes from the rebalance math, so tokens left over from earlier rounds are used before buying more.

3 · Deposit#

Once the coin has graduated and the spendable SOL is at least 0.02 SOL, the engine deposits into the canonical pool. The deposit is sized by SOL with slippage headroom, and falls back to sizing by tokens when the pool price moved and the coin side is the constraint. Dust that does not pair stays in inventory for the next cycle.

4 · Burn#

The LP tokens minted by the deposit are burned with a Token-2022 Burn in the same transaction. The pool keeps the reserves; nobody holds the claim on them. Each coin page shows the pool's burned share as lp_burned / lp_supply.

Rebalance math#

Let S be spendable SOL (balance minus the 0.01 SOL rent reserve), T the engine's token balance and p the price in SOL per token.

On the curve (p = virtualSol / virtualTokens):
  value  = S + T·p
  buy    = value · 0.5 − T·p          // bring the coin side to 50%
  if buy ≥ 0.002 SOL and buy ≤ S: buy on the curve

On PumpSwap (p = poolQuote / poolBase):
  buy    = (S − T·p) / 2                // equal value on both sides at the pool price
  if buy ≥ 0.002 SOL: buyQuoteInput(buy)

Deposit:
  quote  = S / (1 + 2%)              // leave room for maxQuote
  r      = depositQuoteInput(quote)
  if r.maxBase > T:                     // coin side is short
    r    = depositBaseInput(T / (1 + 2%))
  deposit(r.lpToken, r.maxBase, r.maxQuote) + burn(r.lpToken)

Because the PumpSwap buy happens immediately before the deposit, the post-buy price is slightly above p. The fallback to base-sized deposits absorbs that drift; the unpaired remainder is a few basis points and is deployed next cycle.

Engine wallets#

Each coin has its own engine wallet, set as the coin's creator at mint, so its fees, inventory and deposits never mix with another coin's. The engine wallet keeps a 0.01 SOL reserve for token-account rent that is never deployed; a separate keeper wallet pays network fees.

Transactions#

All are v0 transactions compiled against pump.fun's address lookup table, with a 600k compute-unit limit.

Why PumpSwap#

pump.fun coins graduate into a canonical PumpSwap pool, and that is where their price and volume live. Depositing anywhere else, such as a separate Raydium pool, would split liquidity across two venues, leave the main pool thin, and hand the spread between them to arbitrageurs. Deepening the canonical pool is the only placement that lowers slippage for every trader. It also closes the loop: PumpSwap trades pay creator fees back into the engine.

The keeper#

An off-chain keeper runs the engine around the clock. Every 15 seconds it:

1. Refreshes bonding-curve state for every live coin, which decides whether it trades on the curve or on PumpSwap.
2. Runs claim → split → deposit → burn for every coin, several coins in parallel.
3. Indexes new trades and refreshes holders for the site.

Trade indexing#

Trades come from chain, so trades placed on pump.fun appear too. The keeper pages getSignaturesForAddress on the bonding curve and, after graduation, on the pool, then parses each transaction with jsonParsed (v1 transactions included):

• Curve: SOL is the curve account's lamport delta; the trader is the largest token-balance change for the mint.
• Pool: SOL and tokens are the pool vaults' deltas. When both vaults move in the same direction it is a deposit or withdrawal, not a trade, and it is skipped.

Failure handling#

Parameters#

The live values the engine runs with.

Trust model#

• Trading, curve math, graduation and pool accounting are pump.fun's programs. The site only builds transactions.
• Unclaimed fees and inventory sit in each coin's engine wallet until the keeper deploys them.
• LP that has been burned is out of anyone's reach, the operator included.
• Every engine action is a public transaction linked from the Engine page.
• The launch server never broadcasts a transaction that does not match the prepared mint and fee payer.

FAQ#