What Trading Volume Means, And The Context It Needs

Trading volume is the summed value of the trades an indexer recognised, over a stated window, across the venues that indexer covers. That is the whole definition. It is also why the figure cannot be read alone: it inherits a window, a venue set and a counting convention, and a token page prints the answer without printing any of the three. Change one input and the number changes while the market does not.

A definition that is complete and still not enough

Most metric confusion comes from definitions that are vague. Volume has the opposite problem. Its definition is precise, short and universally agreed, and the precision creates a false sense that two figures wearing the same label are the same measurement. They frequently are not, and the reasons are structural rather than accidental.

Consider what has to happen before a number reaches a token page. A program on chain executes a swap. An indexer decodes the transaction, recognises the instruction as belonging to a program it supports, extracts the input and output amounts, and picks a side to value. To value that side it needs a price, which usually comes from a reference pair elsewhere. It then adds the result to a running total that resets or rolls according to a window rule.

Each of those steps involves a decision. None of the decisions is wrong. All of them are invisible in the final figure, and any of them can differ between two providers looking at exactly the same chain.

Three inputs hidden inside one number

It helps to write the definition as a formula with its arguments made explicit, because the arguments are what a comparison must equalise.

Two figures are comparable when W, V and C match. When they do not, the difference between the numbers contains the difference between the conventions as well as any difference in activity, and there is no way to separate the two after the fact. This is not a subtle statistical caveat. In practice it routinely accounts for gaps of two or three times.

The window, and why two sites disagree

A twenty-four hour figure can be built two ways. A rolling window continuously includes the last twenty-four hours, so a spike stays in the total for a full day and then falls out abruptly. A fixed window resets at a clock boundary, so the same spike inflates one day and vanishes at the reset, and a figure read shortly after the reset covers only a few minutes of activity.

Both are legitimate. They produce different numbers for the same token at the same moment, and they produce differently shaped charts. Reading a fixed-window figure two hours after its reset and comparing it against a rolling figure is a mistake that produces a difference of an order of magnitude with no misconduct anywhere.

Shorter windows carry a second problem: they are dominated by whatever happened most recently. A one-hour figure on a thinly traded token can be produced by a handful of trades, and it will swing wildly between readings taken minutes apart. That volatility is a property of the sample size, not of the market.

The venue set, and what actually gets summed

Solana has many places a token can trade: launchpad curves, constant-product pools, concentrated and dynamic liquidity pools, and aggregator routes that touch several of these inside one transaction. An indexer covers the programs it has chosen to support. Two providers with different coverage produce different totals for the same token, and neither total is incorrect.

Coverage differences bite hardest around migration events, when a token moves from a launchpad curve to a standard pool. During and shortly after that transition, one provider may still be counting curve activity, another may have switched to counting only the new pool, and a third may be adding both. The token page shows one number and no indication of which of those three you are looking at. The set of on-chain programs a swap can touch is documented in the Solana documentation, and the individual transactions are inspectable in the public Solana explorer if you want to see which program actually executed a given trade.

There is a further wrinkle in summing across venues. Adding every pool that holds the same pair produces a correct total of flow and a misleading picture of available depth, because those pools are not one order book. You cannot execute against their combined depth in a single trade at a single price, so the summed figure describes activity rather than opportunity.

Routes, legs and double counting

Aggregators split and route orders. A single user action can execute as three swaps across three pools inside one transaction. Counting each pool interaction separately gives three swaps that sum to roughly the user's order size, which is defensible. Counting the user's intent gives one swap at full size, which is also defensible. For a simple split, the two approaches produce similar totals.

Multi-hop routes are where the two diverge. If a route goes from token A to SOL to token B, a per-pool count records two swaps. If both are valued at their full notional, the same value is counted twice. Across a busy pair this convention alone can materially inflate a headline without a single extra trade taking place.

Neither convention is wrong, and neither is usually disclosed. The practical consequence is that a provider counting legs will systematically report higher volume than a provider counting intents, for tokens that are frequently routed through. The gap widens exactly when a token becomes popular enough for aggregators to route through it, which is the moment people start comparing it to other tokens.

Three machines that print the same number

Set the counting conventions aside and assume two figures were produced identically. They can still mean different things, because the market structure that produced them differs. There are three structures worth separating.

A bonding curve

On a launchpad curve, price is a function of how much of the curve supply has been sold. Buyers trade against the curve, not against a counterparty's inventory. There is no liquidity provider choosing depth, no second reserve to drain, and no meaningful sense in which the curve can be emptied by ordinary trading, because selling simply moves back down the same function. Volume here records value pushed along and back along a fixed path.

A fresh pool

A newly created constant-product pool holds whatever reserves were seeded into it. Price comes from the ratio of two reserves and every swap moves it. Depth is small, price impact per trade is large, and the same reserves can be traded through repeatedly. Volume many times the size of the reserves is ordinary rather than remarkable, and it says nothing about whether new value entered.

A deep pair

An established pair with substantial reserves absorbs trades with little price movement. Here a daily volume figure is typically a fraction of available depth rather than a multiple of it, and the number behaves roughly the way an untrained reader expects: it loosely tracks how much value moved in and out at prices close to the quoted one.

Only the third case matches the intuition most people bring to the word volume. The first two produce the same figure by mechanisms that break that intuition in different directions, which is why placing them in the same sorted column is the single most common error on a token screener.

Worked example: one figure, three markets

Volume per wallet, and what it adds

The third useful division is volume by the number of distinct wallets that traded in the window. It has an obvious weakness: addresses are free, so a wallet count is an upper bound on participants rather than a count of them. It also has a real strength, because it constrains the shape of the flow.

A very high volume per wallet against a small wallet count says a few addresses did nearly everything, which is what you see with concentrated ownership, with a market maker, or with an operator trading through a small set of funded addresses. A very low volume per wallet against a large wallet count says many addresses each did very little, which is what a genuine retail crowd looks like and also what a wide funded wallet set looks like.

Neither reading is a verdict. Combined with average trade size and turnover it produces a profile, and profiles are what comparisons should be made between. Comparing profiles is much harder to get wrong than comparing headline totals, because a profile carries its own context.

Why volume is not a measurement of demand

This is the point the rest of the site rests on. Volume records that trades occurred and how large they were. It does not record why they occurred, who wanted the asset, or whether anyone finished the day holding more of it than they started with. A round trip, a buy followed by a sale of the same size, adds twice its own value to volume and leaves net position exactly where it was.

That is not a loophole. It is what the metric measures. Any market with two-way flow contains round trips, and no indexer attempts to net them out, because netting would require deciding which trades belong to the same participant and that information is not reliably available on chain.

Because producing volume requires nothing more than placing swaps, tools exist that do exactly that. A Solana volume bot schedules swaps across a set of funded wallets at chosen sizes and intervals, and the resulting trades are indexed like every other trade. Reading such a console is useful here for one narrow reason: it makes the inputs to a volume figure explicit, and it shows plainly that the output of the process is a number in a column, not evidence that anyone wanted the token.

The honest reading of a large volume figure is therefore conditional. It supports the claim that a lot of value passed through a venue. It does not support the claim that a lot of people wanted the asset, and no amount of additional volume data converts the first claim into the second. Getting from flow to demand requires evidence about position changes and about who holds what afterwards, which is a different investigation with different sources.

A six-line reading checklist

This is the sequence the desk runs before quoting any volume figure. It uses only numbers already displayed on a standard token page and takes about two minutes.

1. Name the window and its rule. Rolling or fixed, and if fixed, how long ago it reset. If you cannot establish this, quote the figure as approximate or not at all.
2. Name the venue set. One pool, all pools for the pair, or a launchpad curve plus a pool. Around migration events, expect providers to disagree.
3. Ask how routes are counted. Per leg or per intent. If the token is commonly routed through, this alone can shift the figure substantially.
4. Divide by transaction count. Average trade size tells you whether the total came from a few large clips or an enormous number of small ones.
5. Divide by available depth. Turnover tells you how many times the reserves were worked. On a curve, record that the denominator does not exist rather than substituting something else.
6. Divide by distinct wallets. Volume per wallet narrows the range of stories that fit, especially when read alongside the previous two ratios.

Six lines, three divisions, and the headline stops being a mystery. What it becomes instead is a profile: a statement about size distribution, about how hard the depth was worked, and about how concentrated the activity was. That profile can be compared to another profile honestly, which is the subject of comparing two tokens honestly. The mechanical difference between the first two structures is worked through in curve volume versus pool volume, and the turnover ratio has a page of its own in volume against liquidity.

Questions this page gets asked