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, so its fees, inventory and deposits never mix with another coin's. The key is derived, never stored:

seed   = HMAC-SHA256(KOTH_MASTER_SEED, "koth:fee-authority:" + mint)
engine = Ed25519.fromSeed(seed)

The launch route derives it to set creator in create_v2; the keeper re-derives it to sign. The public key is stored with the coin and checked against the derivation before every engine run. The engine wallet pays its own token-account rent from a 0.01 SOL reserve that is never deployed; the 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#

A long-running process (pnpm keeper) owns every state transition. Each cycle (default 15s):

1. Resolve launches whose browser confirmation timed out.
2. Refresh bonding-curve state for all live coins, 100 accounts per RPC call.
3. Per coin: index new trades → snapshot holders (at most once a minute) → run the engine.

pnpm keeper            # live
pnpm keeper --dry-run  # simulate every engine transaction, send nothing
pnpm keeper --once     # single cycle, then exit

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#

Data model#

Postgres (Supabase), every table prefixed koth_, row-level security on, public read, server-only writes.

Parameters#

The live values, set in src/lib/koth.ts and picked up by the keeper on restart.

Trust model#

• Trading, curve math, graduation and pool accounting are pump.fun's programs. The site only builds transactions.
• Whoever holds KOTH_MASTER_SEED controls every engine wallet's unclaimed fees and inventory. LP that has been burned is out of anyone's reach, including ours.
• 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#