Where Solana Volume Comes From

Solana DEX volume comes from five venue classes: aggregators and routers, constant-product automated market makers, concentrated-liquidity pools, central limit order books, and launchpad bonding curves. Only four of those hold liquidity. Aggregators originate order flow and route it into the others, which is why their published share overlaps with venue share instead of adding to it.

That overlap is the single most common source of confusion in Solana market-share discussion. A reader collects figures from several dashboards, adds them, and produces a total larger than the market. Nothing was fabricated along the way. The figures were measured at different layers of the same stack, and layers do not sum. This note works through the classes, the routing behaviour that connects them, and the form a defensible share claim has to take.

The five venue classes

Start with the four classes that hold liquidity, because they are where value actually changes hands. Each applies a different pricing rule, and the rule determines what a trade against it costs, how quickly the price recovers afterwards, and what kind of participant supplies the other side. Naming them as classes rather than as brands keeps the analysis stable as individual venues rise and fall.

Constant-product automated market makers are the baseline. Two reserves, an invariant of the form x × y = k, and liquidity spread across every possible price from zero to infinity. They are simple to reason about and forgiving of extreme moves, at the cost of holding most of their capital at prices no trade will ever reach. Most long-tail Solana pairs sit in this class.

Concentrated-liquidity pools take the same curve and let depositors restrict their capital to a chosen price band. Inside the band, depth is far greater for the same capital; outside it, the position contributes nothing and has been fully converted into one asset. The result is a venue that quotes tightly while the market stays where depositors expected it and thins abruptly when it does not.

Central limit order books work the way a traditional exchange does. Participants post bids and offers at chosen prices, and a matching engine crosses them. Depth is whatever has been posted, it can be cancelled in the next slot, and quoted spreads reflect the willingness of market makers rather than a formula. Solana's throughput makes this design practical on chain, which is not true of every network.

Launchpad bonding curves are the fourth. A program sells a token against a deterministic price schedule, with the program itself as the only counterparty. There is no depositor-supplied reserve on the sell side in the way a pool has one, and the price path is fixed in advance. The differences from a deployed pool are structural and are worked through in the note on curve liquidity versus pool liquidity.

The fifth class, aggregators and routers, holds nothing. It receives an intent from a user, searches paths across the venues that do hold liquidity, and submits a transaction that executes against them. Its output is a routing decision. Its volume is real user demand, but the settlement happens somewhere else, and that displacement is what breaks naive addition.

Why the shares do not add up

Consider what a single routed trade produces in the data. The user signs one transaction. The router selects a path. One or more pools execute swap instructions. Every layer of that stack can legitimately record the event, and each records it in its own units, so the same economic action appears in three or four different totals simultaneously.

Suppose a wallet sends a 60 SOL order through an aggregator, and the router splits it 36 SOL into one pool, 18 SOL into a second and 6 SOL into a third. The three pools record 36, 18 and 6, which sum correctly to 60. The aggregator records a 60 SOL user trade. Add all four figures together and you have 120 SOL of apparent activity produced by 60 SOL of intent.

Nobody in that chain reported anything false. The pools accurately described what passed through them. The aggregator accurately described what the user asked for. The error is entirely in the addition, and it is committed by the reader who assembles figures from different layers into one table without noting which layer each row belongs to.

The rule that follows is narrow and easy to apply. Compare within a layer, never across layers. Aggregator against aggregator answers a question about who captures order flow. Venue against venue answers a question about where liquidity is being consumed. Both are useful; the ratio between them is not a market share, and no denominator exists that makes it one.

A second consequence is that the denominator has to be stated. Share of what: all Solana swap volume, all spot DEX volume, volume in one pair, volume within one hub of venues? Each choice produces a different figure for the same venue. The conventions behind those choices are set out in the note on how DEX volume is counted.

What launch curves contribute

Launch curve activity is counted as volume by most surfaces, and mechanically that is defensible, since tokens move and value changes hands. But it is a different kind of volume, and treating it as equivalent to pool volume distorts any comparison that includes a period of heavy token creation.

The first difference is the counterparty. In a pool, both sides of a trade are supplied by depositors who chose to be there, and a buyer is matched against reserves that someone committed. On a curve, the counterparty is the issuing program executing a schedule. Nobody took the other side of the trade in an economic sense; the supply was minted into it.

The second difference is the price path. A curve's price is a deterministic function of how much has been sold, so a buy always raises the quoted price and a sell always lowers it, in an order that is known before the token exists. Pool prices also move with flow, but around a level set by two-sided participation rather than along a predetermined track.

The third difference is what the activity predicts. A curve fills concentrate at the start of a token's life and then stop, either because the curve completed and liquidity migrated to a pool, or because interest ended. Neither outcome resembles the steady bilateral flow that pool volume in an established pair represents, so extrapolating from one to the other fails in both directions.

For measurement, the practical response is separation rather than exclusion. Report curve volume as its own line. A period in which most activity was issuance against curves is a genuinely different market from one in which most activity was exchange between holders, and a single combined figure describes neither. The broader question of what a volume print contains is taken apart in the anatomy of Solana trading volume.

Routing, splitting and where the print lands

Routers split orders because execution cost is convex in size. Filling half an order against each of two pools usually costs less in total than filling all of it against either one, since the second half of a single large fill executes at a materially worse price than the first. The router is solving a cost minimisation, and the split is the output of that solve.

The splitting behaviour has a direct effect on where volume appears. A venue that consistently offers the best marginal price on a pair will receive the largest slice of every routed order in that pair, and its recorded volume will grow without any user ever choosing it by name. Venue share measured this way is a measure of quoted competitiveness, not of user preference.

Multi-hop routing adds a second effect. When no direct pool exists between two tokens, the router passes through an intermediate asset, and both hops are real executions in real pools. Pool-level volume totals therefore include activity in pairs that no user intended to trade. The mechanics of how these paths are constructed are documented in the major Solana aggregator's developer documentation.

Priority fees and slot timing shape the outcome too. Solana targets roughly 400 millisecond slots, and a route computed against reserves in one slot may execute against different reserves in the next. Slippage tolerance is what protects the trade from that gap, and a transaction that exceeds the tolerance fails rather than filling badly. Failed attempts move no value and belong outside any volume total.

Because routing is where the classes meet, some execution software is built to work across them rather than against a single pool. What sits behind the next link is a third-party execution console covering several Solana venue classes, presented as a commercial product; this desk does not operate it, has no involvement in it, and takes no position on whether any such tool suits a given token. Readers who want to see how that category is organised can open Solana Volume Bot Pro and form their own view. The practical distinction to look for is coverage: a volume bot on Solana DEXs that reaches several AMMs distributes its prints across the classes described above, while a single-pool tool concentrates them in one place, and the two produce very different-looking attribution tables.

The venue classes side by side

The table below is deliberately free of figures. The columns that matter are the last two, because attribution rules and additivity are what determine whether a set of numbers can be combined at all. Any share discussion that skips them is arithmetic performed on incompatible units.

Two rows deserve a note. Concentrated-liquidity pools are additive at the venue layer, but a share figure computed from them conceals whether the depth was in range during the window, which is the property that made the venue competitive in the first place. Request-for-quote fills are the hardest case, because they may be invisible to pool-level indexers entirely while still consuming genuine user flow.

Stating a share claim honestly

A market-share claim is checkable only if the reader can reconstruct it. That requires five declarations, none of which are onerous, and all of which are routinely omitted. The omission is usually habit rather than intent, but the effect is the same: an unfalsifiable number that propagates through screenshots until it is treated as established.

Declare the venue set. List the programs included in the denominator, and say what was excluded and why. Declare the layer. State whether the comparison is between aggregators, between liquidity venues, or between something else, and confirm no figure crossed layers on the way into the table.

Declare the routing convention. Say whether a split order counts once as user intent or once per pool that executed a leg, and whether intermediate hops in multi-hop routes are included. Declare the window with a timezone, since a rolling figure and a calendar day figure describe the same market with different numbers.

Declare the treatment of failures. A transaction that reverts changed no balances, so it produced no volume, though it remains useful data for measuring execution quality in a separate metric. Every one of the five declarations fits in a single line of a footnote, and together they turn a headline into a claim a reader can check or refute.

The reason to insist on this is not pedantry. Share figures drive real decisions about where to deploy liquidity and which venue to integrate. A figure assembled by adding an aggregator to the pools it routes into will overstate the market by roughly the aggregator's own share, and every conclusion drawn from it inherits that error without any visible sign that it happened.

Attribution questions from readers

If an aggregator holds no liquidity, why does it report volume at all?

Because it measures something real that no venue can see: the size of the order a user actually wanted to place. Pools observe only the slice that reached them. The aggregator figure is the correct one for questions about demand, and the wrong one for questions about where liquidity was consumed.

How do I tell which layer a dashboard is measuring?

Find a transaction you can inspect, then look for it in the dashboard's feed. If it appears once at the size the wallet submitted, you are at the intent layer. If it appears as several entries matching the individual pool executions, you are at the venue layer.

Should launch curve volume be excluded from totals entirely?

No, but it should be reported separately. Excluding it hides genuine activity; merging it implies an equivalence with two-sided pool trading that does not hold. A separate line preserves both the total and the ability to see what the total is made of.

Does a venue with more volume necessarily have more liquidity?

No. Volume is flow over a window and liquidity is a stock at an instant. A venue can record high volume by turning over modest reserves repeatedly, and a router will keep sending flow to whichever venue quotes best for the sizes being traded, not to whichever holds the most capital.

Why do order book venues complicate the comparison?

Because their depth can be cancelled. Posted size is a statement of willingness that disappears in the next slot if the maker changes their mind, whereas pool reserves have to be withdrawn by a transaction. Comparing the two as though both were committed capital overstates the order book side.

What is the minimum acceptable footnote on a share chart?

The venue set, the layer, the routing convention, the window with a timezone, and the treatment of failed transactions. Five short clauses. A chart without them can be shared but cannot be verified, and it should not be cited as though it had been.