Curve Volume Versus Pool Volume: Two Machines, One Label

A bonding curve and a constant-product pool are different machines that both emit a number called volume. On a curve, price is a deterministic function of how much of the curve supply has been sold, and depth is fixed when the curve is deployed. In a pool, price is the ratio of two real reserves that anyone can add to or withdraw. The same reported figure therefore implies different things, and a screener column places them side by side anyway.

Two machines wearing one label

The word volume describes an accounting operation, not a market structure. An indexer sums recognised trades and prints the total. It does not, and cannot, annotate that total with the shape of the venue that produced it. That annotation is the reader's job, and it is skipped almost universally because the token page gives no hint that it is required.

The practical consequence appears the moment anyone sorts a list. A screener sorted by twenty-four hour volume mixes launch-stage curve tokens with freshly migrated pairs and with established markets. Every row is correct. The ranking is meaningless, because the rows are not measurements of the same thing.

How a launchpad curve prices a token

Solana launchpad curves are commonly implemented as a constant-product formula over reserves that are set when the curve is created. Buyers send SOL to the curve and receive tokens; sellers return tokens and receive SOL. There is no counterparty inventory in the usual sense and no liquidity provider deciding how deep the market should be. The curve is the market maker, and its behaviour is fixed by parameters chosen at deployment.

Three consequences follow directly, and all three matter for reading volume.

• Depth is not a choice. Nobody can add liquidity to make trades cheaper, and nobody can remove it. The price impact of a given trade size is determined by the formula and by how far along the curve the token currently sits.
• Progress is a single tracked quantity. Where a pool has two reserves that move against each other, a curve has one position along a path. Buys advance it, sells retreat along it, and the path does not change shape.
• Migration is an event, not a gradual transition. When curve progress reaches the threshold set by the launchpad, remaining reserves are deployed into a standard pool and trading moves there. Before that point there is no pool; after it, there is no curve.

The underlying token accounts, mint authorities and supply mechanics are the ordinary SPL ones described in the Solana program documentation; the curve sits on top of them as an application. That matters when you go looking for evidence, because the token side of the story is inspectable with standard tools even when the curve program is unfamiliar.

How a constant-product pool prices a token

A standard pool holds two real reserves and quotes a price from their ratio. Every swap changes both reserves and therefore the price, in proportion to the trade size relative to the reserve on the side being drained. Liquidity providers deposit both assets and can withdraw, so depth is a variable that changes independently of trading. The mechanics and the fee handling for the common Solana pool types are set out in the Raydium documentation.

Two properties of pools are directly relevant to volume. First, the same reserves can be traded through repeatedly, so cumulative volume has no ceiling set by pool size. Second, depth is observable: the reserves are on chain, so you can divide volume by them and get a ratio that means something. Neither property holds on a curve in the same way.

There is a third property worth naming because it is often missed. Liquidity can be withdrawn. A pool that showed substantial depth yesterday can show very little today with no trades involved, which changes every ratio computed against it without changing a single volume figure.

The two machines side by side

Read down the two columns and the reason for the confusion becomes obvious. Only one row, the round-trip row, behaves the same way in both structures. Every other row differs, and several of them differ in ways that change how a volume figure should be interpreted.

Migration, and the gap it opens in the data

Migration is the point where reporting most often goes wrong, because it is a change of venue rather than a change of activity. Providers handle it in at least three ways: continue the series and add the new pool to the same page, restart the series at the new pool, or report both for an overlapping period.

Each choice produces a differently shaped chart from identical underlying trades. A restart looks like a collapse in volume followed by a recovery. A continuation looks smooth. Reporting both temporarily looks like a spike. None of those shapes is evidence about the token, and all three are routinely read as if they were.

There is also a real effect mixed in with the artefact, which makes this harder rather than easier. Migration changes what a trade costs, because a curve and a fresh pool have different depth profiles. Activity genuinely does change at migration, sometimes substantially. The difficulty is that the reporting artefact and the real effect arrive at the same moment and look similar in a chart.

Round trips behave differently in each

A round trip is a buy followed by a sale of the same size by the same participant. It adds roughly twice its notional to volume and leaves net position unchanged. This is true in both structures, which is why it is the one row in the table that matches. What differs is the cost and the visible trace.

In a pool, a round trip pays the swap fee twice and pays price impact in both directions, but the second leg partially recovers what the first leg moved, because the reserves return towards their starting ratio. On a curve the same logic applies to curve progress: a buy advances it, the matching sell retreats along the same path, and the token ends up close to where it started with fees paid twice.

The reason this matters for reading volume on a launch-stage token is specific. Migration is normally triggered by curve progress, not by cumulative volume. So two curve tokens showing similar reported volume can be at quite different points on the curve, because one accumulated its figure through directional buying and the other through round trips. The volume column does not distinguish them; curve progress does, and it is usually displayed separately.

What one trade costs in each structure

Cost is the cleanest way to feel the structural difference, because it is where the formula shows through. In a constant-product pool, the price impact of a trade depends on its size relative to the reserve being drained. A trade worth a large fraction of a reserve moves price a great deal; a trade worth a tiny fraction barely moves it at all. That relationship is why turnover is informative, and it is worked through in detail in volume against liquidity.

That blindness runs the other way too. If you are looking at a large volume figure on a shallow venue, you are looking at a number that cost a lot to produce in fees and impact. That does not tell you who paid or why, but it does tell you the figure was not free, and cost is the kind of thing that has a reason behind it.

Worked example: equal volume, unequal meaning

The desk's position is that the tie is the problem. A ranking implies an ordering along one dimension, and volume across venue types is not one dimension. If you need a ranking, rank inside a stage: curve tokens against curve tokens, fresh pools against fresh pools.

Reading a curve token volume figure honestly

Curve-stage volume gets a specific reputation for being noisy, and the reputation is earned for a structural reason rather than a moral one. Launch-stage venues have small effective depth, low per-trade costs at small sizes, and a highly visible progress metric. Those three properties together mean that a lot of activity is cheap to produce and immediately visible, which is why launch-stage flow is where produced volume concentrates.

Being specific about the tooling helps more than being suspicious in general. The controls that shape launch-stage flow are exactly the ones a purpose-built console exposes, and reading the feature list of what is marketed as the best Pump.fun volume bot is a quicker education in the shape of curve-stage activity than any amount of chart staring. Wallet count, interval, size band and venue selection are the four variables, and each one leaves a recognisable trace in the data you can see from outside.

After migration the same logic extends across venues, because a token that trades in several pools can have flow directed at any of them. A multi-DEX Solana volume bot routes across whichever venues hold the pair, which is why post-migration volume comparisons have to fix the venue set before they mean anything. The mechanism is documented plainly in the general-purpose swap and account model in the Solana core documentation: nothing exotic is required, only many ordinary transactions.

None of this makes a curve token's volume fake. The trades happened, the fees were paid, the chain recorded them. It makes the volume figure a poor proxy for interest at that stage, which is a different and more useful statement.

What to record before you compare

Before putting a curve figure and a pool figure anywhere near each other, write down the following. If you cannot fill in a line, that gap is the answer to whether the comparison is safe.

1. Stage. Pre-migration curve, freshly migrated pool, or established pair. Comparisons are only safe inside a stage.
2. Venue set for each side. One pool, several pools, curve only, or curve plus pool during a transition.
3. Depth, or its absence. Reserve value for pools; for curves, record explicitly that no comparable denominator exists rather than substituting a proxy.
4. Trade count for each side. Needed for average trade size, which is the ratio that survives across both structures.
5. Curve progress, where applicable. If two curve tokens have similar volume and very different progress, the difference is round trips.
6. Whether liquidity moved. A pool whose depth changed during the window makes every ratio computed against it approximate.

Six lines is enough to make most comparisons either valid or visibly invalid, which is all a reader needs. The full procedure for a like-for-like comparison, including what to do when the two sides refuse to normalise, is in comparing two tokens honestly, and the specific errors this structure produces most often are catalogued in five comparisons that mislead.

Questions this page gets asked