Pump.fun Bonding-Curve Laddered Entry & Exit Strategy

Pump.fun's bonding curve is a constant-product AMM with a fixed virtual reserve seed: roughly 30 SOL and about 1.073 billion virtual tokens at launch, with 793.1 million real tokens available for sale before the token graduates. A token migrates to Raydium once ~85 SOL of real reserves accumulate on the curve (the exact threshold has shifted across program versions, so read it from chain, not from a blog). Every buy walks price up the curve; every sell walks it down. If you understand that x*y=k relationship, you can price out exactly what a 2 SOL buy does to the next buyer's entry, and that math is the whole basis for laddering instead of firing one market order and praying.

Most content on this stuff obsesses over the snipe — landing in the first block, racing the dev's own buy. That's a latency game with brutal variance. Laddering is a different bet: you accept you're not first, and you build a position across the curve with pre-planned adds and pre-planned exits, harvesting the migration pump instead of the launch spike. It's less glamorous and it survives more launches.

Why the curve rewards scaling in

On a constant-product curve, marginal price rises as reserves fill. Early on, price is cheap and slippage per SOL is high because the pool is thin. Near graduation, price is richer but the pool is deep enough that a decent-size buy barely moves it. That asymmetry is the edge. A flat "buy 5 SOL at 20% into the curve" ignores it. A ladder that front-loads size where price is cheap and thins out where price is rich captures a better blended entry and caps your damage if the token stalls at 40% and bleeds out — which is what most of them do.

Here's the blended-entry logic I actually run. Reserves are read live; the rungs are fractions of the graduation target, not price levels (price is a derived quantity you should never hardcode):

# rungs as % of real-SOL progress toward migration (~85 SOL)
LADDER = [
    (0.00, 0.06, 0.35),  # (curve_progress_low, high, weight)
    (0.06, 0.15, 0.30),
    (0.15, 0.30, 0.20),
    (0.30, 0.50, 0.15),
]
# weights sum to 1.0; total_size is your full intended position

def next_rung(curve_progress, filled_weight):
    for lo, hi, w in LADDER:
        if lo <= curve_progress < hi and w > filled_weight_at(lo):
            return w
    return 0  # past 50% progress: no new entries, manage exits only

Note the hard stop at 50% of graduation progress. Buying above that is chasing — you're paying near-migration prices for a token that hasn't proven it'll migrate, with none of the cushion the early rungs gave you. If you want the migration move, you should already be positioned before the crowd front-runs the graduation event. Detecting that event cleanly is its own problem; the mechanics overlap heavily with the graduation-timing work I broke down in the piece on building a graduation-detection and JIT liquidity engine on Solana, and it's worth reading if you plan to be near the curve at migration.

Sizing the rungs against real slippage

The trap in laddering pump.fun tokens is treating your quoted price as your fill price. On a thin early curve, a 0.35-weight first buy can eat 8-15% slippage against the virtual reserves, and that's before the priority-fee war and any Jito bundle tip you're paying to land. Model it explicitly. For a buy of dx SOL against reserves (sol_r, tok_r):

tokens_out = tok_r - (sol_r * tok_r) / (sol_r + dx * (1 - fee))
avg_price  = dx / tokens_out

Compare avg_price to the pre-trade marginal price sol_r / tok_r. If the gap is over ~10% on your first rung, your rung is too fat for how thin the pool is — split it or start later. I keep a hard per-transaction slippage cap of 12% on early rungs and 5% on later ones, and I'd rather miss a rung than fill at a garbage price. Pump.fun charges a 1% trade fee on top of the curve, so bake that into every simulation or your backtest lies to you.

Position size relative to bankroll matters more here than on any established pair. These are near-100%-loss-probability assets individually; the ladder only makes sense as a portfolio of many small staged entries where the migration winners pay for the rug losers. If your risk model isn't built around that base rate, the ladder won't save you, and it's the kind of thing worth pressure-testing in a strategy consultation before you point real size at it.

Staged exits before migration

Exits are where most people leave money on the table or eat the reversal. The migration to Raydium is a discrete event: the curve locks, liquidity moves, and there's usually a violent few seconds of price discovery on the new pool. Two failure modes: selling everything into the pre-migration pump and missing the Raydium continuation, or holding through migration and getting caught in the LP-open dump.

My exit ladder is staged against curve progress, mirroring the entry:

• ~55-65% progress: sell the first-rung tokens (your cheapest, highest-conviction size). You're already up multiples on those; take the free roll off the table.
• ~70-80% progress: trim to your migration-hold size, typically 30-40% of remaining position.
• Migration event: hold the residual through the curve lock, then decide on the Raydium pool with fresh liquidity data — do not blind-market-sell into the open.

The residual-hold decision is genuinely hard and shouldn't be a static rule. Post-migration behavior depends on the freshly seeded Raydium reserves and the first minute of real order flow, which is closer to the fee-capture and rebalancing logic in the Meteora DLMM auto-rebalance strategy than to anything on the bonding curve. Treat the pre-migration curve and the post-migration pool as two separate venues with two separate models.

The gotchas that actually bite

A few things that don't show up until you're live:

• Reserve reads race the mempool. Your curve_progress is stale the instant you read it. Size rungs assuming 2-3 other buys land between your read and your fill, or you'll consistently overshoot your slippage cap.
• The dev's own supply. Devs frequently hold a chunk and can dump it into your ladder. There's no on-curve signal for intent; the only defense is small rungs and hard slippage caps.
• Priority fees invert your economics. On a 0.3 SOL rung, a 0.05 SOL Jito tip is 16% of trade value. Ladders with many small buys pay fees many times. Batch where you can, and don't ladder so finely that fees eat the edge.

If you're wiring this into an execution engine, the recurring-order and conditional-trigger patterns from the Jupiter trigger and recurring-order engine writeup map cleanly onto rung execution, and you'll want the same real-time reserve monitoring you'd build for a live trading dashboard so a human can see where each position sits on its curve. Before any of this touches mainnet with real size, get the fill simulation and slippage-cap logic in front of a second set of eyes in a code review and audit — the failure modes here are silent and expensive.

If you want the ladder logic, slippage model, and staged exits built and stress-tested against your own risk parameters, that's exactly what our strategy consultation is for.