Atomic Fee Economics

atomic-fee-economics — pump.fun creator-fee economics

A pump.fun coin's creator earns a percentage of every buy + sell into the coinCreatorVault PDA. Collecting those fees costs SOL (Jito tip + tx fee + the operational overhead of running a watcher). This skill helps the operator make the cost/benefit call: how often to collect, what threshold to set, when to stop bothering.

The core trade-off

Every collect cycle costs roughly:

Round to ~0.005 SOL per collect cycle as a working estimate. That's your break-even per cycle.

If MIN_COLLECT_SOL is set too low, you collect frequently but burn most of the proceeds on tips. If set too high, fees accumulate slowly but each collection is net-positive — and the SOL sitting in the vault is at risk if the creator key is leaked.

Picking MIN_COLLECT_SOL

For atomic-watch:

The leaked-key case is the most aggressive setting: you're not optimizing for net yield, you're optimizing for not losing the SOL to a competitor. Sometimes the right move is to accept negative net per-cycle in exchange for denying the adversary.

Estimating accrual rate

Pump.fun's creator fee is a small percentage of each trade (the exact percentage has shifted; check current pump-sdk constants). For a quick rule of thumb:

• A coin doing 10 SOL of daily volume yields very roughly 0.05–0.15 SOL of creator fees per day.
• A coin doing 100 SOL of daily volume → roughly 0.5–1.5 SOL/day.
• A coin doing 1000+ SOL of daily volume → meaningful fee income; can sustain aggressive collect cadence.

These are illustrative. The actual rate depends on the current pump.fun fee parameters at the time of trading.

To get a real estimate:

1. Run atomic-watch with a low MIN_COLLECT_SOL for 24 hours.
2. Count the collects. Each collect harvested at least the threshold.
3. Total collected SOL ÷ hours = SOL/hour accrual.
4. From there, decide the optimal threshold: pick a value where you collect once every 1–4 hours during peak trading.

When to consolidate vs keep collecting

atomic-consolidate is destructive in the sense that it drains the creator wallet + funder wallet too, not just the vault. Use it when:

• Retiring the coin's operational footprint. No more launches from this creator, want everything in cold storage.
• The creator key just leaked. Stop running watch-collect (sweepers will race you), drain everything once via consolidate, never use the wallet again.
• Migrating to a new funder. Drain the old funder + creator into a destination, generate fresh wallets.

Don't consolidate if you're still actively launching from the creator wallet — rent loss on closed accounts adds up if you re-open them later.

Cost of NOT collecting

SOL sitting in the coinCreatorVault PDA earns no yield. It also:

1. Is at risk if the creator key leaks. Larger vault = larger target.
2. Is in a PDA you don't control directly. Only collectCoinCreatorFee can withdraw it, and that requires the creator key.
3. May be subject to program changes. A pump.fun program upgrade could theoretically change vault accessibility (this hasn't happened, but the risk is non-zero).

For these reasons, even at low accrual rates, periodic collection is worth doing. Setting MIN_COLLECT_SOL=0.5 and getting one collect per month is fine for a low-volume coin.

Math: break-even threshold

For watch-collect, you're net-positive when:

collected_amount - jito_tip - tx_fee > 0

With tx_fee ≈ 0 and jito_tip = 0.005:

collected_amount > 0.005 SOL

So MIN_COLLECT_SOL = 0.005 is the theoretical break-even. In practice, set it higher for two reasons:

1. Jito tip volatility. During congestion, you'll bump tips to 0.01–0.02 to land. A MIN_COLLECT_SOL=0.005 then becomes net-negative every congested cycle.
2. Slot competition. If you're racing a sweeper, your bundle may need higher tips than usual to land. Same effect.

A practical floor is MIN_COLLECT_SOL = JITO_TIP × 5, so even worst-case congestion is net-positive.

When to stop collecting at all

There's a point where the operational overhead of running watch-collect (RPC costs, monitoring, alerting on failures) exceeds the fee income. Rough heuristic:

If the coin is genuinely dead, just run a final collect + consolidate and move on.

Edge cases

• V2 USDC pools pay creator fees in USDC, not SOL. The vault PDA logic is different, the script behavior is different, and the economics math above is in USDC units. See atomic-v2-migration. The break-even logic is the same but in USDC terms — at $0.005-ish USDC per cycle, MIN_COLLECT_USDC ≈ 0.025.
• Coin graduates to Raydium (or other AMM). Pump.fun creator fees may stop accruing or change rate post-graduation. Verify with current pump-sdk docs.
• Vault PDA balance includes the rent-exempt minimum. Collecting "the full balance" leaves the PDA rent-exempt floor in place (~0.002 SOL). Not actually a loss — that SOL stays accessible to the next collect cycle.
• Multi-coin operator. If you run many coins from one funder wallet, watch-collect instances share the funder's SOL pool. Make sure the funder has enough for the worst-case simultaneous collect across all of them.

Decision flow

Does the coin still have trade volume? 
├─ NO → final manual collect, then stop
└─ YES → is the creator key leaked / shared?
    ├─ YES → run watch-collect with low MIN_COLLECT_SOL (0.005–0.01); race-mode
    └─ NO → what's the daily accrual rate?
        ├─ < 0.01 SOL/day → manual collect monthly
        ├─ 0.01–0.5 SOL/day → watch-collect with MIN_COLLECT_SOL=0.05–0.1
        └─ > 0.5 SOL/day → watch-collect with MIN_COLLECT_SOL=0.01–0.05 (low-friction)

Related

• atomic-collect — manual one-shot
• atomic-watch — long-running collector
• atomic-consolidate — drain everything (creator wallet, funder wallet, vault)
• atomic-leaked-key-response — when economic math is overridden by security priorities
• atomic-v2-migration — USDC-quoted coins have different fee math
• atomic-bundle-debug — when collect bundles repeatedly fail (eating tips for no SOL)