Solana DEX fees, and why they dominate your budget

Why this dwarfs network fees

Discussion of Solana costs almost always focuses on the network: base fees, priority fees, compute units. Those are interesting, they are cheap, and they are not where a campaign budget goes.

The difference is what each one scales with. Network fees scale with transaction count. Send a thousand swaps and you pay a thousand base fees, which remains a small number in absolute terms however busy the network is. Venue fees scale with volume. Route a hundred SOL and the pool takes a percentage of a hundred SOL, regardless of whether that was ten swaps or ten thousand.

For any campaign of a size worth running, the second number is several times the first. A quarter of a percent on a few hundred SOL of routed volume is more than the entire network cost of the swaps that produced it. The network fee breakdown works through the other side of that comparison with real figures, and the conclusion there is the same: the pool is the expensive part.

How different venue types set fees

Deliberately no percentages in that table. Fee schedules across this ecosystem change often enough that any figure published here would be misleading within a quarter, and a stale number quoted confidently is worse than no number. What stays stable is the structure, which is what you need in order to know what to look up.

The order book row deserves a note because it is the one people mis-model. A published taker fee understates the real cost by a wide margin when the book is thin, because crossing a wide spread on every round trip is the dominant charge and it appears nowhere in the fee schedule.

Two pools, same token, different cost

The point that surprises teams most is that the fee is a property of the pool rather than of the token or the venue.

A token can have a constant product pool on one exchange, a concentrated pool on a low tier somewhere else, and another concentrated pool on a high tier created by a different provider. All three trade the same asset. All three charge different amounts. Nobody chose this centrally; each pool creator picked a tier when they set theirs up.

For a campaign that means the cost depends on where the swaps land, which is a routing question rather than a pricing question. It also means the cheapest pool is not automatically the best destination, because a low tier attached to shallow liquidity costs more in price impact than the fee it saves. The two numbers have to be read together, which the concentrated liquidity explainer covers for the case where depth is hardest to read.

Dynamic fees and when they bite

Some venues vary the fee with recent volatility: quiet conditions charge a base rate, and turbulence adds a variable component on top.

The reasoning is sound from a liquidity provider's perspective. Providing depth during violent price movement is riskier, and a higher fee compensates for that risk. Without it, providers withdraw during exactly the periods when depth is most needed.

From a campaign perspective it introduces a modelling problem, because the periods when the variable component is highest are frequently the periods you most want to be trading. A launch window, a listing, an announcement: all volatile, all expensive. A budget built by simulating a swap on a calm afternoon can be meaningfully wrong when the campaign actually runs, and the shortfall shows up as less confirmed volume than expected. Simulating during conditions resembling your actual window is the only way to model it honestly.

There is a second reason this row matters beyond budgeting. Because the variable component rises with volatility, the fee is highest precisely when your own campaign is contributing to that volatility. A campaign that trades too large relative to depth therefore pays twice for the same mistake: once in price impact, and again in the elevated fee its own movement helped trigger. Keeping swaps small relative to the pool avoids both at once, which is the same conclusion nearly every cost question in this category arrives at.

Reading the fee you will actually pay

1. Identify which pools hold your token. Not which venues exist, which ones have liquidity for your mint.
2. Find the tier on each. Pool information pages display it, and it is a property of that specific pool.
3. Simulate a realistic swap on each and compare the output against the quoted mid price. That captures the fee and the impact together, which is what you actually pay.
4. Repeat during conditions like your campaign window. On a dynamic-fee venue a quiet-hour reading is not representative.
5. Multiply by your target volume, not by your transaction count. This is the arithmetic that reveals how large the number is.

Step three matters more than step two. The tier tells you the headline rate; the simulation tells you the total cost of trading there, and on a thin pool those two numbers are very far apart.

What routing does to the average

Spreading a campaign across several pools produces a blended rate rather than a single one, and the blend is usually better than any individual choice for reasons that have nothing to do with fees.

Concentrating everything in the cheapest pool maximises the share of that pool's depth you consume, which raises price impact and slippage failures. Both of those cost more than the fee difference in most realistic configurations. Spreading keeps each swap small relative to the depth it faces, which lowers impact, lowers failures, and produces a pattern that looks less like one participant hammering one venue.

The practical position is that fee tier is a real input and it is rarely the deciding one. Depth first, fee second, and the two weighted together rather than either optimised alone. That is why routing is automatic here rather than a setting: the correct split changes with depth and conditions, and a split fixed in advance is wrong as soon as either moves. You can see which pools hold your mint and the exact SOL figure for a given target in the campaign console.