After the pool opens: what a migrated token changes in a campaign

After migration the campaign is trading a different instrument. A bonding curve prices fills against a reserve the program holds and moves in one direction as it fills; a pool prices fills against two-sided depth that any participant can add to or withdraw, and price can fall on the same venue that it rose on. Every parameter derived from the curve reserve is now describing a mechanism that no longer exists, and the venue field is the one that has to be right before any of the others matter.

A pool is a different mechanism

An automated market maker holds both sides. A constant product design keeps the product of the two balances fixed as trades move between them, which means depth exists in both directions and a sell is priced by the same arithmetic as a buy. Concentrated liquidity designs change where that depth sits rather than the principle, and pools of both kinds are documented in detail by the venues that run them - the Raydium documentation is one place the mechanics of each pool type are set out.

The difference that matters for a campaign is participation. On a curve, the reserve responds to flow and nothing else; the campaign was effectively the main author of the mechanism's state. In a pool, other participants provide the depth and can remove it, and the depth the campaign sized against this hour may not be the depth in front of it next hour. That makes every derivation provisional in a way it never was on a curve.

The second difference is direction. A curve campaign that bought was pushing the quote up along a known path. A pool campaign that buys is moving along a path other people are also trading, and the price can come back down through the same depth without the campaign doing anything. A position that felt like a mechanical consequence on a curve becomes an exposure in a pool.

Curve and pool, field by field

The row that ends campaigns is the first one. Everything else in the table produces a suboptimal phase; a stale venue produces failed transactions or fills against something the plan never assessed. It is also the easiest to get right, which is why it belongs at the top of the handover packet rather than at the bottom.

What has to be re-pointed on day one

Three things, in order. The route, which decides where a fill goes. The depth observation, which every size derivation depends on. And the stop rule's observable, because remaining curve capacity was the thing the approach phase watched and it has ceased to exist.

Route resolution is worth understanding precisely rather than assuming. Some execution setups resolve a venue once when the campaign is configured and reuse that resolution for every subsequent fill; others resolve at execution time and follow the liquidity. Neither is wrong, and the difference is invisible until the moment it matters. A Raydium volume bot that targets pools directly is solving a different routing problem from one pointed at a launchpad curve, and the plan should record which behaviour it is relying on.

The depth observation should be taken after the pool has had some time rather than in its first minutes, because the earliest state is the least representative. Taking it immediately and deriving a band from it produces a band matched to a moment that will not persist, which is worse than waiting and running a deliberately small opening.

Deriving a size band against two-sided depth

The rules from the curve phase transfer; their inputs do not. The cost rule is unchanged, because fixed costs per fill are a property of the network and the setup rather than of the venue, so the floor moves only if fee conditions have moved. The impact rule needs restating: instead of a share of a one-sided reserve, it becomes a share of the depth available in the direction the fill is going.

That asymmetry is new. On a curve, buys and sells were priced by the same reserve. In a pool, the depth available to a buy and the depth available to a sell can differ, particularly in a concentrated design where liquidity sits in ranges. A single impact rule applied to a single depth number is an approximation, and the block should say that it is one.

The practical form most plans land on is a conservative opening band derived against the thinner side, held for a stated period, then a re-derivation once the pool has settled and the observation is worth trusting. That sequence costs a little efficiency in the first hours and removes the risk of sizing an entire phase against a transient state.

Worked arithmetic: the same rule set, a pool instead

The figures below are illustrative arithmetic showing how the curve rules restate for a pool. They describe no real pool, token or run.

The last line is the whole point of the re-check trigger. Curve depth only grew, so a stale band was conservative; pool depth can fall, so a stale band becomes aggressive without anyone changing a setting. That is a genuinely new failure mode at this phase and it does not exist anywhere earlier in the campaign.

Note also that the impact rule was tightened from the curve phase, from half a percent to a quarter. That is a choice the block has to justify, and the justification here is that depth is no longer under the campaign's influence and can move against it. Whether a plan tightens, holds or loosens is up to the operator; what matters is that the number was reconsidered rather than inherited.

The first hours after the pool opens

1. Confirm the venue before anything executesResolve the route and verify a single small fill lands where the plan expects. This is the cheapest check in the campaign and it prevents the most expensive failure.
2. Run a deliberately small openingA short stretch at the conservative band, sized to observe rather than to achieve. Its purpose is to produce real cost and fill data against the new mechanism.
3. Re-observe depthOnce the opening has run and the pool has had time to settle, take the depth observation that the real band will be derived from.
4. Re-derive the band and the intervalUsing the observed depth and the fixed cost the opening actually produced, rather than the assumptions carried from the curve phase.
5. Set the new stop ruleAgainst depth and against the campaign's own exposure, since capacity remaining no longer exists as an observable.
6. State the end conditionWhat ends the pool phase, and therefore the campaign, in one checkable sentence.

Steps two and three are the ones most often skipped under time pressure, and skipping them means the whole phase runs on assumptions imported from a mechanism that has been replaced. The opening stretch costs a small fraction of the allocation and converts every later number in the block from an estimate into a measurement.

Why the buy and sell mix inverts

On the curve, the mix had two meanings: a cost decision, and a decision about how much remaining capacity the campaign consumed. In a pool the second meaning disappears entirely, and a third appears in its place: exposure. Price can now fall through the same depth it rose through, and a directional position is held in a market where other participants are trading the same pool.

This changes what a balanced mix is for. On a curve it was mainly a way of trading without consuming capacity. In a pool it is a way of trading without accumulating exposure, and the cost of the second leg buys something different from what it bought before. A plan that carries the ratio across without rewriting the reason line has kept a number and lost its meaning.

It also changes what an unbalanced mix means. A buy-heavy pool phase is a decision to hold something, and the block should say what the intention is for that holding and what ends it. Left unstated, it becomes whatever position the phase happens to finish with, sized by nobody and reviewed at the worst possible moment.

Measuring a pool phase

The measurement definitions carry across unchanged - that is the point of fixing them before phase one - but the sources change. Fills now sit against a pool alongside everyone else's, so separating campaign flow from total flow requires the signing accounts rather than the venue. That is the same reconciliation as before, done against a different denominator.

Reading it independently matters more here than earlier, because the pool phase has more moving parts. Per-account transaction history is public, and pulling it from a block explorer such as the Solana explorer rather than only from the execution tool's own summary means an error in one is visible against the other. Transaction structure and what is recorded is described in the Solana documentation for anyone who wants to reconcile more carefully than a summary allows.

The four closing lines are the same as every other phase: what the block predicted, what the record shows, what it cost including fees, and which condition ended the phase. The one addition worth making here is a line on final exposure, because the pool phase is the only one that can end holding something the campaign did not intend to hold.

The post-migration checklist

• The route was re-pointed and verified with a single small fill before anything else ran.
• The plan records whether the venue resolves at execution time or at configuration time.
• Depth was observed after the pool settled, not in its first minutes.
• The cost rule was checked against fees actually paid rather than assumed unchanged.
• The impact rule was restated for two-sided depth, and the restatement has a reason line.
• The band was derived against the thinner side, and the block says which side that was.
• A re-check trigger exists for depth falling, not only for depth rising.
• The buy and sell mix has a new reason line describing exposure rather than capacity.
• The stop rule uses an observable that exists in a pool.
• The end condition for the campaign is written and checkable by someone who was not there.

Writing the end of the campaign

The pool phase is the last block, so its exit condition is also the end of the campaign, and that deserves a sentence of its own rather than being inherited from the allocation. A campaign that stops because its money ran out has not concluded anything; it has simply become unable to continue, and the close will have nothing to compare against.

Three endings are worth writing down in advance. The objective was answered, in which case the close says how. The allocation was exhausted before the objective was answered, in which case the close says what the shortfall was. Or a stop rule fired, in which case the close says which one and what the observable was doing at the time.

Whichever ending occurs, the campaign is finished when the four closing lines exist for all four phases and the exposure line is filled in. That is a small document, and it is the only thing that turns a sequence of runs into something the next campaign can learn from rather than repeat.

What the pool phase does not restore

The pool phase does not undo anything the curve phases did. The record they wrote is permanent, the costs they paid are spent, and a well-run post-migration block cannot retrofit a coherent story onto phases that were run on carried-over settings. It is a fresh block against a fresh mechanism, and that is all it is.

It does not make the token liquid either. Depth in a pool is supplied by participants, and a campaign trading through that depth is a consumer of it rather than a source. Confusing the two is how operators end up describing their own turnover as liquidity, which is a claim the record does not support and this desk will not make.

And it does not remove the exposure the campaign chose to take. A directional block in a pool holds something, and no parameter in this note changes what that something is worth. The block's job is to make sure the position was sized on purpose, stated in advance, and reviewed at the close rather than discovered there.

The same questions, asked at this depth