How Solana Sniper Bots Exploit Pump.fun Bonding Curves

Pump.fun's bonding curve mechanism was designed to democratize token launches — no liquidity pool to seed, no rug-pull risk during the curve phase. What the designers did not advertise is that the graduation event is one of the most structurally predictable price discontinuities in all of DeFi. If you know the exact SOL threshold and you can process an on-chain event faster than the next block, you have an edge that is mechanical, not speculative.

The Bonding Curve in Plain Numbers

Every token launched on pump.fun starts on a constant-product curve parameterized so that the token graduates to Raydium once the curve accumulates 85 SOL in reserves (roughly $12,000–$15,000 at typical prices). The curve mints a fixed supply of 1,000,000,000 tokens, reserves 200,000,000 for the liquidity pool, and sells the remaining 800,000,000 along the curve. Price is fully deterministic at every point:

price = virtual_sol_reserves / virtual_token_reserves

Both reserve values are stored in the BondingCurve account. You can derive the current price and the remaining SOL to graduation by reading a single account — no oracle, no AMM query required. This matters because it means your bot can predict graduation before it happens, not just react to it.

Detecting the Graduation Event

The naive approach is to subscribe to program logs and parse MigrateFunds or the equivalent instruction from the pump.fun program (6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P). The problem: by the time that event appears in a standard WebSocket subscription, you are already in the same block as everyone else watching the same stream.

The production approach has two layers:

• Account-diff subscription: Use accountSubscribe on the BondingCurve PDA with commitment: processed. When the complete flag flips to true in the account data, you have the earliest possible signal — the state change, not the log.
• Slot-level racing: Pre-build and sign the buy transaction before graduation, targeting the pool accounts you can derive deterministically. Send it via multiple RPC endpoints simultaneously (Helius, Triton, and a bare validator connection if you have one). The winning submission lands in the first slot after the migration instruction.

The Raydium pool address for a graduated pump.fun token is derived from the mint and a known program seed — it is not random. Your bot can compute the pool address and pre-build the swap instruction before the pool technically exists.

Front-Running the Migration: Slot Timing

Solana slots are approximately 400 ms. The migration from pump.fun to Raydium takes one transaction to burn the curve and seed the pool. If your bot is not in the same block as that migration, you are at minimum one slot behind — and in high-competition launches that is enough to give up 20–40% initial price impact to the bots that were.

Practical slot-level timing requires:

1. Stake-weighted QoS: Standard RPC nodes throttle burst traffic. A staked connection (directly to a validator or via a provider that offers staked endpoints) gives your transactions priority in the leader's queue.
2. Jito bundles: Submit your buy as a Jito bundle with a tip. Bundling guarantees atomicity and lets you express explicit ordering relative to the migration transaction if you can identify the migration tx hash in the mempool equivalent (Jito's block engine sees transactions before they land).
3. Priority fee calibration: Pump.fun graduation slots attract 50–200 competing transactions. A static priority fee will lose. The bot needs to read the recent getFeeForMessage response and add a multiplier — typically 2–5x the 75th-percentile fee from the last 10 slots.

Position Sizing and Exit Logic

Getting into the first post-graduation block is only half the problem. The bonding curve suppresses volatility by design; Raydium has none of that suppression. Price discovery is violent. Typical behavior on a mid-tier launch: 3–8x in the first 60–90 seconds, then a reversion to 1.5–2x over the next five minutes as early curve holders exit.

A production sniper does not hold. The exit is structured as a trailing stop triggered by pool reserve changes, not a time stop:

• Fetch getAccountInfo on the Raydium pool every 2 slots.
• If the SOL reserve drops more than 15% from peak within any 10-slot window, treat it as large-holder exit and send the sell in the next block.
• Hard stop at –25% from entry, no exceptions.

Position size should be capped at the level where your own buy does not move the pool price more than 3%. On a freshly graduated pool seeded with 85 SOL, that means your entry is bounded at roughly 2–3 SOL. Larger size means worse average fill and a harder exit.

On-Chain Risk You Cannot Engineer Around

Two risks are structural and worth naming directly. First, RPC propagation variance: even with staked endpoints, your transaction can miss the target slot if the leader is on a different geographic node. Latency to the leader matters more than latency to your RPC. Second, copy-cat graduation transactions: some tokens are launched specifically to attract sniper bots and then immediately dump the bonding curve allocation into the Raydium pool in the same bundle. There is no reliable on-chain filter for this; the mitigation is behavioral — watch deployer wallet history before entering, and reject any token where the deployer's address has more than 5% of supply outside the curve.

Building a production-grade sniper means accepting that the edge here is thin, temporal, and infrastructure-dependent. The code is not the moat — the node topology, the staked connections, and the continuous calibration of fee logic are.

---

If you want a sniper bot built for your specific parameters — chain, risk tolerance, position limits — talk to us. We build and operate these systems in production, not in demos.