Price And Depth Discontinuity At The Handover

The price jumps at migration because the two venues compute price with unrelated equations. A curve evaluates a function at a position. A pool divides one reserve by the other. The opening pool price is set by the ratio of the two deposits the migration routine made, and there is no mechanism anywhere in the system that requires it to equal the last curve quote.

Two equations, one instant

A bonding curve is a rule that maps position to price. Ask it for a quote and it evaluates itself at wherever the position currently sits. Nothing else is involved: no reserves to compare, no counterparty, no depth. The rule is total, meaning it produces an answer everywhere in its domain, which is why a curve never runs out of anything.

A constant-product pool is a rule about state rather than a function of position. It holds two balances and preserves their product across a swap, which is the behaviour set out in the Raydium protocol documentation for pools of that type. Ask it for a quote and the answer is the ratio of the balances it currently holds. Every fill changes those balances, so every fill changes the next quote, and the pool has no memory of what it quoted a minute ago.

At migration one is retired and the other takes over, at a single instant, with no overlap by design. That is the discontinuity. It is not a market event, because no participant caused it, and it is not an error, because both mechanisms behaved correctly. It is a change in what the plotted quantity means.

Why the prices need not match

People expect continuity because continuity is what markets normally provide. In a market with continuous trading, the price at any instant is the price of the last trade, and the last trade before an event and the first after it are both trades. The number carries across because the mechanism carries across.

Here the mechanism does not carry across. The last curve price was produced by a rule that no longer exists for this token. The first pool price is produced by a rule that did not exist for this token a moment earlier. The only thing linking them is the deposit, and the deposit is chosen by the migration routine according to the launchpad's parameters rather than to make the chart look tidy.

In practice the two are often close, because the token allocation reserved for the pool and the reserve accumulated by the curve are usually sized so the opening price lands near where the curve finished. That is a design choice, not a guarantee, and treating a close match as a law produces confusion the first time it does not hold.

What sets the opening price

Exactly two numbers: the quantity of quote asset deposited and the quantity of tokens deposited. Divide the first by the second and you have the opening price. Multiply them and you have the constant the pool will preserve.

Both deposits are downstream of launchpad parameters. The quote deposit is the accumulated reserve less whatever the operator retains under its fee model. The token deposit is an allocation held back for this purpose since the token was created. Changing either parameter changes the opening price and the opening depth together, in opposite directions.

This is worth internalising because it makes the opening price predictable in structure even though this desk refuses to print the parameters. If you know the two deposits, which you can read off the migration transaction, you know the opening price exactly. No inference is required and no third-party display is needed.

Slippage changes character

The row worth dwelling on is the last one. In a pool, transactions in the same block execute in an order the trader does not control, and each one moves the reserves for the next. A quote fetched a second before signing describes a state that may not exist by the time the transaction lands. Minimum-output limits exist for exactly this reason, and aggregator interfaces return an expected output alongside that minimum, as the Jupiter documentation describes. Setting the minimum loosely to avoid failures is how people convert a failed transaction into an expensive fill.

Illustrative arithmetic on both sides

Depth becomes a live variable

Before migration, depth is not a concept. After migration it is the single most important number describing the market, and it is one that anybody can change without asking anyone.

The seeded deposit sets a starting depth. From that moment, any provider can add liquidity, earning a share of swap fees in exchange for holding both sides of a volatile pair. Any provider who added can withdraw. The seeded position itself is normally burned or locked and therefore stays, but it is only the floor, and everything above the floor is discretionary.

This produces a pattern worth expecting: depth often rises in the first hours as providers arrive to farm fees during the busiest period, then falls as those providers leave once activity subsides. A trader who calibrated their sizing during the busy window finds the same size behaving quite differently later, and concludes something changed about the token when what changed was the pool.

There is also an asymmetry inside the pool worth knowing. A constant-product pool cannot be fully drained on either side, because the product must stay constant, so the last tokens are arbitrarily expensive. What that means in practice is that a thin pool does not run out; it prices you out, which feels different and is worse, because the transaction succeeds.

The stitched chart and what it hides

Most charting tools present a graduated token as one continuous series. This is a reasonable product decision and a slightly dishonest picture. The left portion is derived from trades against the curve and the right portion from swaps against the pool, and the join is rendered as though it were a normal interval.

Three artefacts follow. First, the candle spanning the seam can look extreme, because it may include the last curve print and the first pool print with the discontinuity between them. Second, volume around the seam is not comparable across the join, because the two halves are counted by different indexers with different conventions about routed legs and both sides of a swap. Third, any indicator with a lookback window straddling the seam is averaging two different quantities and producing a number about nothing.

None of this is a reason to distrust charts generally. It is a reason to treat the seam as a marked boundary and to avoid reading anything across it. When somebody points at a dramatic candle at the moment of graduation as evidence of something, the first question is whether they are pointing at a market event or at a rendering of two mechanisms meeting.

Turnover without depth is unreadable

Turnover is a flow: value that moved through a pair over a window. Depth is a stock: value sitting in the pool right now. A flow figure without the stock it flowed against cannot be interpreted, and almost every surface that displays turnover omits depth entirely.

Consider the same turnover figure against two pools, one deep and one thin. In the deep pool it represents ordinary trading that barely moved price. In the thin pool it represents the reserve being cycled repeatedly, with large price swings and a small number of participants. The screener shows the same number for both, sorted into the same position on the same list.

The cheapest correction available is to divide turnover by depth, giving a rough turnover ratio that says how many times over the pool was traded through in the window. It is crude, it is not standard anywhere, and it separates the two cases above immediately. The second cheapest is to count distinct signers alongside turnover, which separates many participants trading small amounts from few participants cycling large ones.

This is also the honest test to apply to any tool that reports on produced activity. A figure that states its window, its venues, whether it counts both sides of a swap and whether routed legs are deduplicated can be checked against the chain. Teams comparing a professional Solana volume bot against a cheaper one usually find the difference is not the trading; it is whether the reporting is specified well enough to verify at all.

The first hour, mechanically

Several distinct things happen at once in the first hour, and separating them prevents most of the misreadings.

• Anybody who tracked the curve toward completion trades in the earliest slots, because on-chain state is public immediately.
• Arbitrage appears as soon as a second venue for the same mint exists, and it will keep prices roughly aligned across pools at a cost.
• Aggregators index the pool at different times, so quotes differ across front ends for a while and then converge.
• Liquidity providers arrive to capture fees during the busy window, raising depth, and some of them leave later, lowering it again.
• Charting sites begin their pool series, which is why some show a token as brand new when it has been trading for weeks.
• Routed swaps appear as multiple legs, so transaction counts and turnover both run higher than the number of user actions.

What to record at the seam

If you are going to analyse the transition afterwards, a handful of readings taken at the time are worth more than any amount of reconstruction later.

Record the migration slot and block time, which give you the exact boundary. Record both deposit amounts, which give you the opening price and the opening constant. Record the pool address and its program owner. Then take a depth reading at a few known intervals afterwards, because depth is the series nobody keeps and the one you will most want when trying to explain a fill somebody complains about.

None of this requires paid infrastructure. It requires deciding in advance that the readings matter, because they are cheap to take at the time and impossible to take retroactively once the state has moved on.

Questions the desk is sent