What is a DEX? Pools and liquidity on Solana
There is no buyer on the other side of your trade. There is a pool, a formula and a fee. Once those three things make sense, price impact, depth, migration and most of the rest of this vocabulary stop being mysterious.
In one sentence
A DEX is a program that swaps one token for another against a pool of both tokens, and liquidity is simply how much is in that pool.
The short answer
A DEX, short for decentralised exchange, is a program on a blockchain that swaps one token for another. On Solana most of them work by holding a pool of two tokens and pricing every swap with a formula, so your trade does not meet another person. It meets a pot of tokens, takes some out, puts some in, and the price moves because the ratio inside the pot changed.
Liquidity is simply how much is in that pot. A pool holding a great deal of both tokens barely notices your trade. A shallow one moves sharply. That single fact explains price impact, slippage, why the same trade costs different amounts at different venues, and why volume and liquidity are unrelated numbers that beginners are constantly told to treat as one.
Why there is no order book
On a traditional exchange you place an order and wait for somebody to take the other side. That requires a matching engine, a queue of resting orders and, in practice, professional participants willing to sit there quoting prices all day. It works, but it needs constant human and institutional attention.
A new token launched an hour ago has none of that. Nobody is sitting there quoting it. If it needed an order book it would simply not be tradable, because there would be no orders. So the dominant design on Solana replaces the counterparty with a formula and replaces the market maker with anybody willing to deposit both tokens into a pool.
Order books do exist on Solana and some venues use them. But the tokens most people meet first, especially anything launched from a launchpad in the last few days, trade against pools or curves, so that is what this page describes.
What a pool actually is
A pool is an account, controlled by a program, that holds a quantity of two tokens. Call them SOL and TOKEN. The program will accept SOL from you and send you TOKEN, or the reverse, and it decides how much to send by applying a rule to the quantities it currently holds.
The most common rule is the constant product rule. Multiply the amount of SOL by the amount of TOKEN in the pool and you get a number, usually written as k. Every swap must leave that product unchanged, apart from the fee. Put SOL in and the SOL side grows, so the TOKEN side must shrink by exactly enough to keep the product the same, and the amount it shrinks by is what you receive.
That is the whole mechanism. There is no price stored anywhere. What people call the price is just the current ratio between the two sides, recalculated after every trade. A pool cannot run out of either token under this rule, because as one side gets scarce it gets arbitrarily expensive, which is elegant and also the reason very small pools produce absurd prices.
The formula, with numbers
The arithmetic is worth doing once by hand, because it makes price impact obvious rather than mystical. Take a pool holding 100 SOL and 10,000,000 TOKEN. The product is 1,000,000,000. The ratio, which people call the spot price, is 100 divided by 10,000,000, or 0.00001 SOL per token.
Now buy with 1 SOL, ignoring fees for a moment so the formula is visible on its own. The SOL side becomes 101. To keep the product at 1,000,000,000 the token side must fall to 1,000,000,000 divided by 101, which is 9,900,990. You therefore receive 10,000,000 minus 9,900,990, or 99,010 tokens. You paid 1 SOL for 99,010 tokens, an effective price of 0.0000101 SOL each, which is about one per cent above the spot price you started from.
That one per cent is price impact. You caused it yourself by trading against a pool of that size. Nobody charged it to you and nobody can waive it; it is a property of the arithmetic. Now watch what size and depth do to it.
| Pool | Trade | Tokens received | Effective price | Impact vs spot |
|---|---|---|---|---|
| 100 SOL / 10,000,000 | 1 SOL | 99,010 | 0.0000101 | about 1% |
| 100 SOL / 10,000,000 | 10 SOL | 909,091 | 0.0000110 | about 10% |
| 1,000 SOL / 100,000,000 | 10 SOL | 990,099 | 0.0000101 | about 1% |
Two lessons sit in that table. Ten times the trade size gives roughly ten times the impact in a pool of the same depth. Ten times the depth gives roughly one tenth of the impact for the same trade. Depth and size trade off against each other almost exactly, which is why every practical question about trade sizing is really a question about pool depth.
Depth, and why it decides everything
Depth is the amount sitting in the pool, and it is the property that determines how expensive it is to move a price and how much it costs you to trade at all. A token can have enormous reported volume and a shallow pool, because volume counts trades and depth counts deposits. They are measured from different things.
This is the point where the two words beginners are most likely to conflate finally separate. If you take nothing else from this page, take this: volume is turnover, liquidity is depth, and knowing one tells you almost nothing about the other. A pool with 5 SOL in it can print hundreds of SOL of daily volume by having the same funds go round repeatedly, and it will still move ten per cent on a 0.5 SOL trade.
The check that takes ten seconds
On any token page, find the liquidity figure and the volume figure and put them side by side. If volume is many multiples of liquidity, the same money has been going round and round. That is not proof of anything improper, but it tells you the volume number is describing circulation rather than fresh interest, and you should read it that way.
Who puts the tokens in
Someone has to deposit both sides. That person is a liquidity provider, and in exchange for depositing they receive LP tokens, which are a receipt proving what share of the pool is theirs. Burn or return the receipt later and you withdraw your share, which by then will be a different mixture of the two tokens than you put in.
For a freshly launched token the liquidity provider is usually the launch itself: the launchpad program deposits the collected SOL and a quantity of the token into a new pool. Afterwards anyone can add to it. Withdrawing is equally permissionless unless the LP tokens have been burned or locked, which is what people mean when they talk about liquidity being locked.
Providers earn a share of the trading fee on every swap, which is their compensation for a real risk: if the price of one token moves a long way relative to the other, they end up holding more of the loser and less of the winner than if they had simply held both. That effect has an unhelpful name, impermanent loss, and it is neither impermanent nor a loss in the ordinary sense. It is the cost of having been on both sides of every trade.
Bonding curves and how they differ
A bonding curve is a simpler cousin of the pool, used by launchpads for the earliest phase of a token's life. Instead of two deposited sides, there is a formula that sets the price purely as a function of how many tokens have already been sold. Buy and the price rises along the curve; sell and it falls back down it. Nobody had to deposit anything to start it.
That is what makes instant launches possible. A launchpad such as Pump.fun can make a token tradable the second it exists, because the curve does not wait for a liquidity provider to show up. The trade-off is that the early price is entirely mechanical and the depth is whatever the curve formula says it is at that point.
| Property | Bonding curve | Two-sided pool |
|---|---|---|
| Needs a depositor to start | No | Yes |
| Price set by | How many tokens have been sold so far | The ratio of the two balances |
| Depth | Fixed by the curve formula at each point | Whatever people have deposited |
| Anyone can add depth | No | Yes |
| Typical lifespan | Until a threshold is reached, then it migrates | Indefinite |
| Fee structure | Set by the launchpad | Set by the pool program, shared with providers |
Migration, or graduation
When a curve reaches its threshold, the launchpad closes it and opens a normal pool, moving the collected SOL and a quantity of tokens across. People call this graduating or migrating. From the trader's point of view the token has changed venue, and almost every property that mattered a moment ago is now different: fee rate, depth, who can add liquidity, and which program the transaction has to target.
This matters for anybody automating trades because a program pointed at a curve will simply stop working when the curve closes. It is not a subtle failure; the target no longer exists. Tools handle this by watching for migration and re-pointing at the new pool, and the transition is one of the moments where run logs suddenly fill with failures.
It is also the moment where the character of the market changes. Before migration, depth is mechanical. After it, depth is whatever people deposited and may be withdrawn again. The same trade size can behave completely differently on either side of that line, which is why any sizing decision made before migration should be re-checked after it.
Routers, aggregators and split trades
Because one token can trade in several pools, there is a question about which one to use. A router answers it: you tell it what you want to swap and it works out the path, sometimes splitting a trade across several pools so that no single one takes the whole impact. The best known on Solana is Jupiter, and its documentation is a readable description of how routing decisions are made.
Routing usually gets you a better price on larger trades, because splitting across pools reduces the impact in each. It costs a little more in transaction complexity and adds a dependency on the router being available. For small trades against a single obvious pool, targeting that pool directly is simpler and just as good.
Anyone running a volume bot on Solana DEXs ends up making this choice explicitly, because a schedule of many small trades has a different routing answer than a single large one. Small trades against a shallow pool rarely benefit from splitting, and each extra hop adds a way for the transaction to fail.
Why one token trades in several places
Nothing prevents anyone from creating a second pool for the same token. Pools are permissionless, so a popular token typically has several, on several different programs, with different depths and different fee rates. Prices between them stay roughly aligned because anyone can profit from the difference, but they are never identical at any instant.
This is the deep reason volume figures disagree between sites. Each aggregator decides which pools and programs it recognises. Include an extra venue and the total rises. Exclude a router and trades made through it may be attributed differently or not at all. The disagreement is a modelling choice, not a bug, and it is worth knowing before you argue with a number.
Reading a pool page
Whatever explorer or aggregator you use, the same handful of fields tell you what kind of market you are looking at. Read them in this order and you will form a reasonable picture in under a minute.
- Liquidity. How deep the pool is. This bounds how large a trade can be before impact becomes silly.
- Volume and its window. Turnover over a stated period. Compare it to liquidity rather than reading it alone.
- Number of traders or makers. Turnover from a handful of addresses describes a different situation than turnover from many.
- Which pool and which program. Curve or pool, and which venue. This determines the fee and whether migration is still ahead.
- Pool age. A pool created twenty minutes ago and one created last year deserve different assumptions about everything above.
None of that requires an account or a purchase, and it is the same information a professional would look at first. The next explainer takes the fee line seriously and adds up every cost that lands on a single swap, including the one you set yourself without realising it.
Written by The Plain Solana Desk. Protocol behaviour described here comes from public documentation and from things anyone can check on a block explorer; any figure in an example is arithmetic chosen to make a point and describes no real account. The way this desk decides what to publish is set out in how we explain things, and every term used above has a short entry in the word list.