PumpSwap volume bot: what changes the day your token migrates
Graduation is not a cosmetic milestone. The moment a token completes its bonding curve and its liquidity moves into a PumpSwap pool, the mechanics underneath every trade change completely. Price stops being a deterministic function of supply sold and starts being a function of pool depth. Contention drops sharply. The failure rate that made curve campaigns so expensive falls with it. A campaign configured for the curve and left running unchanged is now using the wrong trade size, the wrong slippage and the wrong assumptions about what a swap costs.
What actually changes at migration
That last point is the one that dominates cost. The curve is a queue: many parties want the next fill and only one gets it, so the rest fail and pay anyway. A pool is not a queue. Two swaps in the same block simply execute against slightly different prices, and both land.
Slippage also changes character. On the curve, slippage is a function of your position in the buy order, which is unknowable in advance because it depends on who else lands first. In a pool it is a function of your trade size against pool depth, which is measurable before you send anything. Unpredictable becomes calculable.
The curve mechanics themselves are covered in how the Pump.fun bonding curve works.
The cost difference, measured
| Program | Sampled tx | Failure rate | Median fee | Cost per landed swap |
|---|---|---|---|---|
| Pump.fun bonding curve low sample | 23 | 73.9% | 5,700 | 21,839 |
| Pump.fun AMM (post-graduation) | 173 | 32.4% | 6,655 | 9,845 |
| Raydium CLMM low sample | 49 | 65.3% | 10,570 | 30,461 |
| Meteora DLMM | 109 | 69.7% | 8,450 | 27,888 |
In the current measurement window the curve cost roughly 21,839 lamports per landed swap against about 9,845 on the post-graduation pool. That is a factor of around 2.2, driven almost entirely by the failure rate rather than by the fee: 73.9% of curve transactions failed against 32.4% on the pool. The same budget buys materially more landed swaps on the other side of migration.
Two cautions on reading this. The curve figure is dominated by tokens actively being contested, since those are the ones generating transactions, so it reflects competitive conditions rather than a quiet curve nobody is watching. And both figures move with market conditions, which is why the window is stamped on the table rather than the number being presented as fixed.
The full per-venue comparison is on which Solana DEX is cheapest for a volume bot, and the fee percentile distribution is on the measured transaction costs page.
The settings that should change with it
- Trade size. On the curve, small trades reduced exposure to losing a race. In a pool, the constraint is price impact against depth, which is a different and usually more permissive limit. Sizing can often increase, though not to the point where impact becomes visible.
- Slippage. Curve campaigns often run wide tolerances to survive unpredictable fill positions. In a pool that tolerance is now an unnecessarily wide window for someone else to profit inside, as covered in sandwich MEV protection. Tighten it toward the pair's actual movement.
- Retries. On the curve, aggressive retrying was rational because failure was expected. In a pool, a failure is usually informative rather than routine, and retrying hard against it wastes fees.
- Priority fees. Curve competition justified bidding up for position. Pool swaps rarely need the same urgency, and continuing to bid at curve levels is a straightforward overpayment.
Left unchanged, a curve-tuned campaign in a pool pays more per swap, exposes itself to unnecessary slippage and produces a burstier, more mechanical looking pattern than it needs to.
Should you run volume before or after graduation
The honest framing is that pre-graduation volume buys a different thing. It contributes to curve progress, which is a real objective if a token is close and stalling. It is not an efficient way to generate chart activity, and treating it as one is how budgets get consumed with little to show.
Post-graduation volume is the reverse. It does nothing for curve progress, because there is no curve any more, and it is a far cheaper way to produce sustained visible activity. Most campaigns want the second thing and pay for the first because they started early.
There is also a middle path worth considering: a small campaign through the curve to help it complete, then the main budget deployed once liquidity is in a pool. That sequencing spends the expensive SOL only where it does something the cheap SOL cannot.
What aggregators actually pick up, and why post-graduation activity registers more reliably, is covered in how DEXScreener trending works.
What to check once the pool exists
A newly created pool is thin by definition until people add to it, so the first hours after migration are not representative of what the pool will be. Sizing from depth measured immediately after the move can leave you with settings that are far too cautious a day later, or far too aggressive if liquidity was withdrawn instead.
It is also worth confirming that the pool you are trading into is the one carrying the depth. Tokens frequently acquire pools on other venues shortly after graduating, and the one that matters is whichever holds real liquidity at the current price rather than whichever was created first.
When a token address is entered in the dashboard, this resolution happens from on-chain state on every campaign rather than once at setup, so a token that migrates mid-campaign is followed rather than left behind. Modelling the cost difference before committing is what the calculator is for, and the reasoning behind publishing these measurements at all is on the page for the volume bot for Solana tokens itself.