The session logic is the same and three things change. Trades hit pool reserves instead of a bonding curve, so slippage depends on pool depth rather than on curve position. Order sizing has to be set against that depth, because an order that is large relative to the reserves moves the price and pays for it. And the token becomes eligible for pool-level boards such as DexScreener trending, which is a different competition from the launchpad feed it just left.
Short version
- Depth replaces curve position as the thing that decides slippage.
- Order size should be read as a percentage of pool reserves, not as an absolute SOL figure.
- Migration is the moment the audience is largest, so a session that stops there stops at the worst point.
- New boards become available, with different competition and a longer refresh cycle.
- The fee structure on the trade changes from a launchpad fee to a pool fee, and it is still charged on both legs.
Curve versus pool
On a bonding curve, price is a function of how much of the supply has been bought. Every trade moves along a predetermined shape and the venue takes a fee. There is no depth in the usual sense: the curve will fill any size, at whatever price the curve says.
In an AMM pool, price is a function of the ratio between the two reserves. A buy takes tokens out and puts quote asset in, which moves the ratio and therefore the price, and how far it moves depends entirely on how large the trade is relative to the reserves. A 1 SOL order in a pool with 40 SOL of depth is a very different event from the same order in a pool with 400.
| Bonding curve | AMM pool | |
|---|---|---|
| Price set by | Supply sold along the curve | Ratio between the two reserves |
| Slippage driver | Position on the curve | Order size relative to depth |
| Fee charged | Launchpad fee, both legs | Pool fee, both legs |
| Order sizing rule | Absolute SOL amounts | Percentage of reserves |
| Boards it competes on | Launchpad feed | Pool trending boards |
Sizing orders against depth
This is the practical adjustment. On a curve you can pick an order band in SOL and leave it alone. In a pool the same band means something different in every pool, so the band should be derived from the reserves.
Read the pool depth
Find the quote-side reserve for the pool. That is the number every order size should be compared against.
Set the band as a share of it
Small orders relative to reserves keep slippage negligible. Orders that are a meaningful percentage of depth move the price on the way in and again on the way out, and you pay for both.
Widen the band, do not raise it
Variance is what makes the tape read as a crowd. Getting variance by raising the ceiling costs slippage; getting it by lowering the floor does not.
Check the round trip cost
Buy slippage plus sell slippage plus the pool fee twice is the real cost of one cycle. Multiply by the order count before you commit to a size.
Recheck if depth changes
Liquidity can be added or removed while a session runs. A band that was conservative at the start may not be an hour later.
This is why a session on a thin pool is more expensive per SOL of routed volume than the same session on a deep one, even though the tool fee is identical. The rest of the cost stack is unchanged and set out in how much a volume bot costs.
The migration boundary
When a bonding curve completes, liquidity moves into a pool and the token keeps trading there. For a launch this is the loudest moment it will have: the graduation itself is a visible event, the token appears on aggregators it was not on before, and more people are looking at it than at any point since the first minutes.
A session that is configured only for the curve stops at exactly that point. The flow ends, the tape goes flat, and the chart is handed back to the market in front of the largest audience it has had. Routing that follows the token into the pool avoids that, and it is worth planning for before the session starts rather than after the boundary has passed.
Different boards, different competition
The launchpad feed sorts new mints and turns over in minutes. Pool-level boards such as DexScreener trending sort across chains, refresh on a longer cycle, and include tokens far older and far larger than a fresh graduate. The cut-off is higher and it moves more slowly.
Practically that means a longer session with steadier flow, rather than the dense burst that suits a launchpad feed. It also means the non-trading signals matter more, because a longer evaluation window gives visitors time to look at the holder list, the liquidity and the socials. What each board actually reads is broken down in does a volume bot get you trending.
What does not change
Everything important. Routed flow still moves volume, transactions and makers, and still does not move the price durably, produce holders or guarantee a slot. The wallets are still ephemeral and still funded from the session deposit. PumpWave still charges a flat 1% of the target volume from 100 SOL up, shown before anything is funded, whether the routing happens on a curve, in a pool, or across the boundary between them.
Questions people actually ask
Can a volume bot run on Raydium pools?
Yes, a volume bot runs on Raydium pools. The routing submits swaps against the pool the same way it submits them against a bonding curve. The difference is in how order sizes should be chosen, because slippage in a pool is a function of size relative to reserves.
Does slippage make a pool session more expensive?
Slippage can make a pool session more expensive, and it depends on depth. In a deep pool, small orders have negligible slippage. In a thin one, every round trip pays slippage twice plus the pool fee twice, which adds up quickly across thousands of orders.
Should the session continue after graduation?
In most cases yes, because graduation is when the largest audience arrives. A session that ends at the migration boundary spends its budget and then goes quiet at the single worst moment.
Is trending on DexScreener harder than on a launchpad feed?
DexScreener trending is a different competition rather than a strictly harder one. The pool boards include older and larger tokens and refresh more slowly, so the cut-off tends to be higher and a slot lasts longer once reached.
Does adding liquidity help a session?
Added liquidity changes the economics rather than the visibility. Deeper reserves reduce slippage on every order, which lowers the real cost of routing. It does not move any ranking input on its own.
What about PumpSwap instead of Raydium?
The same logic applies to any constant product pool. What matters to the session is that price is set by reserves rather than by a curve, and that the order band is chosen against depth.
Run one and watch it land
Paste a mint, shape the session, see the exact fee before you fund anything. Flat 1% from 100 SOL, no install, no seed phrase.
Builds and runs the PumpWave session engine at PumpWave Labs in Estonia. Writes about Solana launch mechanics from the operator side: what settles, what it costs, what the board does with it. Corrections and arguments to support@pumpwave.net.