Running volume on PumpSwap after migration

What PumpSwap actually is

A Pump.fun token spends its first life on a bonding curve, where price is a function of how much has been bought rather than of a pool of reserves. When the curve fills, the token graduates and liquidity is seeded into an automated market maker pool. PumpSwap is that destination.

The distinction matters because almost every assumption carried over from the curve stops being true at that moment. The curve was a single contested piece of state with formula-defined depth. The pool is an ordinary market with real reserves, real price impact, and competition from every other ordinary market on the network.

How it differs from the curve in practice

Read the last row twice. On the curve, campaigns fail because everyone is quoting against the same state at once. On PumpSwap they fail because the pool is too shallow for the swap size chosen while the curve was still the reference.

One more difference is worth naming because it changes the economics rather than the mechanics. On the curve, the token had a captive audience: people watching a progress bar, refreshing to see how close graduation was. That attention was free and it was structural. After migration it disappears completely, and the token competes for eyes against every other pool on the network with no built-in reason for anyone to look. Teams consistently underestimate this, because the curve phase felt like traction when much of it was a mechanic.

Why everything starts from zero

Screeners index pools rather than tokens. Migration creates a new pool with a new address, so the pair that discovery surfaces read is a new entrant with no volume, no trade count and no age. The token-level page aggregates both pairs, but any ranking that reads pair-level figures treats the migrated pool as day one.

This produces the single most common post-graduation complaint, which is that the chart went flat. Usually it did not; the person is looking at the curve pair, which genuinely stopped receiving trades. The post-graduation guide works through the full checklist, including the links you control that now point at a dead page.

Sizing against the seeded pool

The number that matters is not what the token did on the curve. It is what a realistic buy does to the pool now.

1. Simulate an ordinary buy. The size a real trader might send, not your best case.
2. Read the price impact. More than a percent or two for a normal order means the pool is thin for campaign purposes.
3. Size swaps well under that. If a 1 SOL order moves the price noticeably, campaign swaps should be a fraction of it.
4. Raise wallet count to compensate. The same volume delivered in smaller pieces produces better trade counts and much less impact.

The arithmetic behind that last point, including what each additional wallet costs in recoverable rent, is in the fleet sizing guide.

A concrete version of that arithmetic. Suppose a realistic 2 SOL buy moves the migrated pool by three percent. That tells you the pool is shallow enough that campaign swaps of half a SOL will each leave a visible mark, and that a swap of two SOL is something a real buyer will not enjoy. Dropping campaign swaps to a tenth of a SOL and raising the wallet count to hit the same total keeps each individual trade nearly invisible while producing five times the trade count. Same money, better numbers, cleaner chart, and the only cost is a slightly larger rent float that comes back when the accounts close.

The failure rate changes too, in your favour

This is the part that surprises people who ran campaigns during the curve phase and concluded that volume tooling does not work well for their token.

Bonding curves are among the most contested pieces of state on Solana. Dozens of participants quote against the same curve within the same slot, all with tight tolerances, and only the transactions that land first get the price they quoted. Everyone else reverts. Our weekly sampling of finalized blocks has repeatedly measured curve failure rates far above what established pools show, and the current figures with the block range are published on the measured data page.

The practical implication is that a budget calibrated on curve-era results will under-estimate what the same money achieves on PumpSwap, sometimes considerably. That is a pleasant direction to be wrong in, but it is still worth re-measuring rather than assuming.

One caution about reading the improvement. A lower failure rate means more of what you send lands, which raises confirmed volume for the same budget. It does not mean the pool absorbs larger swaps than it can, and it does not mean the chart will look better. Those are governed by depth, which migration does not automatically fix. The two effects pull in different directions often enough that the only reliable move is to measure both before committing: failure rate tells you how much of your spend converts, depth tells you what the conversion looks like on the chart.

A migration-week plan

Assuming the pair is indexed and the pool has usable depth, the week after graduation is where the position is either rebuilt or lost.

• Do not go quiet. Every counter reset. This is the moment activity matters most.
• Concentrate rather than spread. Ranking inputs on a new pair read short windows, so density beats duration.
• Route across every pool, not just PumpSwap. Graduated tokens frequently end up with liquidity in more than one place.
• Update every link you control. Pinned posts and docs pointing at the curve pair now send visitors to a dead chart.
• Re-check depth after a day. Seeded liquidity can move, and the pool you sized against may not be the pool you are trading against tomorrow.