Post-migration volume

Post-migration volume is trade against a constant-product liquidity pool, while curve volume was trade against a single program-held reserve. The mint does not change. Almost everything around it does: who supplies depth, how a trade of a given size moves the quote, who earns the fee, and which market record a tracker attributes the trade to. Reading the two figures as one series is the standard mistake.

This note works through the handover mechanically, then through the three effects that follow from it, then through what the first hour after migration actually contains. The aim is to let you tell the difference between a pool that lost its audience and a pool whose numbers merely restarted their accounting.

What migration does mechanically

When the curve reserve reaches the protocol's migration threshold, the curve stops accepting trade and the accumulated quote asset is used to seed a paired pool on an automated market maker. The token side of that pool comes from supply the program withheld from curve distribution for exactly this purpose. From the next block onward the mint trades against two reserves rather than one formula.

In the general design pattern used by launchpads of this shape, the liquidity provider position created at seeding is not handed to the deployer. It is burned or locked by the program so that nobody can withdraw the seeded depth afterwards. That is the pattern rather than a guarantee. Implementations differ between launchpads and have been revised, so verify the current behaviour against the protocol's own documentation.

The destination venue has also changed over time. Migrated liquidity historically landed on Raydium, and the protocol later routed migration to its own automated market maker, PumpSwap. Treat that as documented history to re-verify, not as a constant. It matters practically, because the destination determines which pool address your tracker, your router and your explorer view are all pointed at.

The threshold itself, and what does and does not change in the same block, is treated separately in the note on the graduation threshold and the migration moment. Everything below assumes the handover has already happened and asks what the resulting market looks like.

The depth reset and where it comes from

A pool seeded out of a curve almost always starts thinner than the token's volume history suggests, and the reason is arithmetic rather than sentiment. Volume is cumulative turnover in both directions. The reserve is net directional inflow. A token can process a very large amount of turnover while accumulating only a modest reserve, because buys and sells cancelled each other along the way.

Three separate deductions sit between the two numbers. Protocol and creator fees are taken out of trade flow while the curve is running, so the reserve is already smaller than gross inflow. A migration or handover cost is commonly applied at the moment of seeding. And the pool is seeded from what is actually held, so nothing that has already been paid out to anyone contributes to depth.

There is a fourth effect that surprises people more than the fees do. Curves of this type commonly quote against a virtual reserve component added to the real balance, which is what allows the first buyer to face a sane price instead of an infinite one. Quoted depth on the curve therefore reflects a number larger than the asset actually held. The pool is seeded from real balances, and the virtual component simply does not carry over.

Put together, the pool inherits the smallest of several plausible readings of the token's liquidity. This is not a defect in the design. It is the honest number arriving after a stage that was structurally flattering. The practical consequence is that trade sizes which barely registered on the curve can move the pool noticeably in its first minutes.

Why price impact changes shape

A constant-product pool holds two reserves whose product is held constant across a swap. For a buy of size dx against a quote reserve x, the fraction of the token reserve you receive is dx / (x + dx), before fees. Impact grows with trade size relative to the reserve and it is symmetric in structure: the same formula describes the sell side against the other reserve.

A bonding curve prices along a fixed function whose parameters were set at deployment. Trade is the only thing that moves along it, and no third party can change its shape. That produces a deterministic relationship between size and impact which is identical for every participant and knowable in advance from the reserve balance alone. It is unusually legible, and it is also completely rigid.

The pool is the opposite on that axis. Depth becomes a variable that other people control. A liquidity provider who adds to the pool reduces price impact for everyone without a single trade occurring, and one who withdraws increases it the same way. Two identical trades an hour apart can produce meaningfully different impact because the reserves between them changed for reasons unrelated to trading.

Fees change shape too. On the curve, a protocol fee is skimmed and the trader has no way to be on the receiving side of it. In a pool, the swap fee accrues to liquidity providers in proportion to their share. That creates a second class of participant with an interest in turnover as such, which is one reason post-migration flow has a different composition even when the price is going nowhere.

The attribution shift inside trackers

Volume figures are not properties of a token. They are properties of a market record that some indexer maintains, keyed to a pair or pool address. Curve-stage trade is recorded against the curve account. Pool-stage trade is recorded against the new pool. Unless an indexer deliberately stitches the two together, they are two rows in a database that happen to share a mint.

The visible result is a rolling window that restarts. A twenty-four hour volume figure on a freshly created pool record covers only the minutes since the pool existed, so it reads near zero at the boundary and then climbs for a day as the window fills. Charts show the same discontinuity: the curve-stage candles may simply not be present on the pool chart.

Both things are usually happening at once, which is what makes the fall hard to interpret. Discovery traffic really does decline after migration, because the token has left the surface that was pushing it in front of new eyes. On top of that genuine decline sits an accounting boundary that can be larger than the decline itself. Reading the total as pure sentiment overstates the collapse.

The resolution is to stop trusting the aggregate and go to the record. Take the pool address, list the swaps against it, and sum them yourself over a window you choose. The field-level procedure for doing that, and for cross-checking every other number on a token page against the chain, is in the note on reading a launchpad token page.

What the first post-migration hour contains

The first hour after a handover has a recognisable structure, and very little of it is fresh demand. Knowing what the components are is what stops you from reading a mechanical settling period as a market verdict in either direction.

The first component is arbitrage against stale references. Aggregators, routers, bots and interfaces do not all learn about a new pool at the same moment. While some of them still quote the last curve price and others quote the pool, the gap is a free trade, and it gets closed quickly by whoever notices first. This flow is real volume and carries no information about demand.

The second component is migration-specific positioning. Some wallets watch for reserves approaching the threshold and position to be present in the first blocks of the pool, either to capture the arbitrage above or to be early in whatever move follows. Their behaviour is timed to an event, not to a thesis, and it typically unwinds within the same hour.

The third component is position closing by curve-stage buyers. Early buyers who could not exit meaningful size against a thin curve now face a pool where an exit is possible, and some of them take it. This shows as sell-side pressure that is a function of the curve stage's holder structure rather than of anything happening now. It is the most commonly misread part of the hour.

The fourth component is fee-driven flow. Once swaps pay liquidity providers, there is an incentive for participants who care about turnover rather than direction, including market making and cross-venue routing. Some of the volume in the first hour is simply the pool being wired into the routing graph that Solana aggregators maintain.

This is also the moment anyone running a volume bot on Solana DEXs has to switch targets, since the curve program no longer accepts swaps and the pool address is new. It is worth knowing as a reader too: part of the first-hour flow is operational plumbing being reconnected, on both the automated and the aggregator side, rather than anybody forming a view about the token.

Reading the hour without over-interpreting it means waiting for those four to finish. A workable habit is to ignore the first fifteen to thirty minutes entirely, then measure distinct signers, buy-sell composition and net reserve change over a clean window afterwards. If the pool still has independent signers arriving once the mechanical flow has cleared, that is a signal. The raw first-hour total is not.

Before and after, property by property

The table below sets the curve stage and the pool stage side by side on the seven properties that actually change at the handover. The fourth column is the one to read first: it states why each difference matters to somebody trying to interpret a number, rather than only recording that the difference exists. Several of these are invisible on a token page and only appear when a trade behaves unexpectedly.

The same trade on a curve and in a pool

The arithmetic below is illustrative. The reserve sizes are chosen to be easy to follow and do not describe any real token or any protocol's actual parameters. The point is the ratio between the two impacts, not the absolute values.

Nothing about the token changed between those two lines. The same wallet submits the same five SOL and receives a materially worse fill on the pool than it would have on the curve moments earlier. The gap comes from two places at once: the virtual reserve component that made the curve quote deeper than the balance it held, and the deductions that reduced the amount actually seeded.

Scale that up and the second-order effect appears. A wallet that accumulated on the curve at curve-stage impact now faces pool-stage impact on the way out, in the opposite direction, against a reserve that its own sell is draining. Exit capacity after migration is frequently worse than the entry experience implied, and it is worse precisely for the wallets holding the largest curve-stage positions.

A checklist for a freshly migrated pool

Run these in order the first time you open a pool that migrated within the last day. Each one is a public read against the chain or the pool account, and none of them requires a paid data source or a subscription. The order matters, because the first two establish which market you are looking at and every later reading is meaningless without that.

One closing caution that applies to every figure in this note. Launchpad parameters change: thresholds, fee percentages, handover costs and the destination venue itself have all been revised at least once. Nothing above depends on a particular value, but any number you carry away from a third-party article should be checked against current protocol documentation before you size a position against it.

Questions readers ask

Primary references for the mechanics described here: the Pump.fun protocol for current migration parameters and destination venue, Solscan for reading pool accounts and swap history directly, and the Solana documentation for account and transaction semantics. Migration behaviour has been revised before; verify against the protocol itself rather than against this page.