Fees and slippage on Solana, for beginners

The short answer

Slippage is the difference between the price you were quoted and the price you actually got, and it happens because the pool moved between the moment you were quoted and the moment your transaction landed. Fees are the fixed charges you pay regardless: a network fee for processing the transaction, an optional priority fee to be processed sooner, and a percentage taken by the venue.

Those are different animals. A fee is a price somebody charges. Slippage is a consequence of time passing and other people trading. You can shop around on fees. You can only bound slippage, by telling the transaction to cancel itself if the price has moved too far.

The five costs on one swap

Take one buy of a token on Solana. Five things reduce what you end up holding, and only two of them are usually called fees. Learn all five as separate items, because tools and marketing pages tend to quote whichever subset flatters them.

1. Base network fee. A fixed charge for having the transaction processed at all.
2. Priority fee. An optional extra to make your transaction more attractive to include when there is competition.
3. Rent. A one-off deposit each wallet pays the first time it holds a given token.
4. Venue fee. A percentage of the swap taken by the pool or launchpad program.
5. Price movement. Both the impact your own trade causes and the slippage caused by other trades landing before yours.

The base fee, and lamports

Solana prices things in lamports. One SOL is 1,000,000,000 lamports, which is why every amount in this subject has nine decimal places. The base transaction fee is 5,000 lamports per signature, and most swap transactions carry one signature, so the base fee is 0.000005 SOL.

That number is small enough to be worth stating clearly: five millionths of a SOL. If somebody tells you Solana fees make automated trading expensive, they are not talking about this line. The base fee is charged whether the transaction succeeds or fails, which matters when a run produces many failures, but even then it is rarely the number that hurts.

The general fee model is documented on the Solana documentation site, and it is worth reading once because it is short and because it separates the two fee types clearly.

The priority fee

When more transactions want to be included than there is room for, something has to break the tie. On Solana that something is the priority fee: you declare how many compute units your transaction may use and how much you are willing to pay per unit, and the product of those two numbers is your extra payment.

The price is quoted in micro-lamports per compute unit, where a micro-lamport is a millionth of a lamport. So the arithmetic looks alarming and lands somewhere small. Suppose your swap requests a budget of 200,000 compute units and you set a price of 1,000,000 micro-lamports per unit, which is one whole lamport per unit. That is 200,000 lamports, or 0.0002 SOL.

Two things follow. First, this fee is entirely under your control and can be set to zero, at the cost of your transaction being deprioritised whenever there is competition. Second, it scales with the compute budget you request, so asking for far more compute than the transaction needs is a way of quietly overpaying.

Rent, and why an empty wallet costs money

On Solana, storing data on chain requires a deposit. An account that holds a particular token is a separate small account, and it must carry enough SOL to be exempt from rent, which works out at roughly 0.002 SOL for a standard token account. That deposit is refundable if the account is closed later, but only after the tokens are gone.

For a single trader this is invisible. For anybody funding many wallets it is not. Two hundred wallets each opening a token account for the same mint is roughly 0.4 SOL locked up before any trading happens, and it stays locked unless something explicitly closes those accounts afterwards. This is the cost line that most surprises people the first time they add up a run.

The venue fee

Every venue takes a cut of the swap. On a two-sided pool most of that cut goes to the people who deposited the liquidity, which is what makes providing liquidity worth doing. On a launchpad curve it goes to the launchpad. Rates differ by venue and change over time, so the only reliable move is to read the rate the venue publishes today rather than trusting a number in an article.

What does not change is that this is usually the largest recurring cost of a small swap. At a rate of one per cent, a 0.05 SOL trade pays 0.0005 SOL to the venue, which is a hundred times the base network fee. Anybody optimising the network fee while ignoring the venue rate is polishing the wrong number.

Slippage, and what it is not

Two different things get called slippage, and separating them makes the setting much easier to reason about.

Price impact

Price impact is the movement your own trade causes. It is fully determined by your trade size and the pool depth, and it exists even if you are the only person on the chain. A quote already includes it: when a router says 1 SOL buys 99,010 tokens, that figure has your impact baked in.

Slippage proper

Slippage is the additional difference caused by the world changing between the quote and the execution. Somebody else's buy landed first, so the pool is now at a different ratio, so your trade gets less than you were told. This is the part you cannot predict, and it is what the tolerance setting exists to bound.

The distinction is practical, not academic. Price impact is fixed by choosing a smaller trade or a deeper pool. Slippage is reduced by landing faster or by trading when less is happening. Confusing the two leads people to raise their tolerance when they should have reduced their size.

The tolerance setting, with numbers

A slippage tolerance is an instruction written into the transaction: send me at least this many tokens or fail. It does not request a better price and it does not protect you from your own price impact. It is a floor, and the only thing it can do when the floor is breached is cancel.

Work an example. You are quoted 99,010 tokens for 1 SOL and you set a tolerance of one per cent, so the transaction demands at least 98,020 tokens. Three things can happen.

The third row is the one people find unfair, and it is the setting working exactly as intended. You told it not to trade at that price. The alternative, a very wide tolerance, means you would have accepted 96,800 tokens, or 90,000, or whatever the pool happened to offer. On a shallow pool with automated traders watching, a very wide tolerance is an invitation to be given the worst price the pool can produce.

There is no correct number. There is a trade-off: tight tolerance means more failures and more wasted fees; wide tolerance means fewer failures and worse fills. On a deep pool with small trades you can afford to be tight. On a shallow pool with volatile flow you cannot, and the honest answer is often to trade smaller rather than to loosen the setting.

Adding one swap up

Now put every line together for a single small trade, so the shape of the cost is visible. The trade is 0.05 SOL. Two figures are protocol facts and three are assumptions you would replace with today's real numbers.

Rent is excluded because it is charged once per wallet per token rather than per trade. The striking part of the table is the proportions: the network fee is a rounding error, the venue fee dominates, and the setting you control most directly is the priority fee, which is also the one people fiddle with hardest.

A round trip is two swaps

Almost nobody buys a token and stops. A trade that goes out and comes back is two separate swaps, and every line in the table above is charged twice. That sounds obvious written down, and it is the single most common omission in a first budget, because people price the buy and then think of the sell as undoing it rather than as a second purchase of network time.

At the assumptions used above, a round trip on 0.05 SOL costs about 0.00181 SOL and produces 0.1 SOL of reported turnover, since both legs are counted by most services. The venue takes its percentage twice. The priority fee is paid twice. The price impact is paid in both directions, and it is not symmetrical: you moved the pool on the way in, so the way out starts from a slightly worse ratio than you began with.

There is one asymmetry in your favour. The token account rent is paid once, on the first purchase, and the deposit becomes recoverable when the account is emptied and closed. That is the only line in the whole model that can come back, and it comes back only if something actually performs the closing step.

The practical rule is to treat the swap, not the round trip, as the unit of cost, and then count how many swaps the plan really contains. A schedule described as one hundred trades usually means one hundred swaps, but a schedule described as one hundred cycles means two hundred, and the difference is the entire fee bill again.

Scaling to a whole run

Multiply the per-swap total by the number of swaps and add the one-off rent. Three hundred swaps at 0.000905 SOL is 0.2715 SOL, and if the run used sixty wallets the rent reserves add roughly 0.12 SOL, giving about 0.39 SOL before any failed attempts are counted.

Then add failures. If one attempt in six fails, those attempts still pay the base and priority fees, which at these assumptions is 0.000205 SOL each. Fifty failures is another 0.010 SOL, which is small here but grows quickly if the tolerance is tight and the pool is busy. Model the failures rather than assuming them away.

This arithmetic is exactly what a multi-DEX Solana volume bot has to do before it starts, because the venue fee is different on each supported pool and the same schedule therefore has a different total depending on where it is routed. If a tool cannot show you that estimate before a run, you are being asked to authorise a spend nobody has priced.

Anybody sizing a budget for the first time will find that the published cost pages for these tools are mostly restatements of this table with the vendor's own charge added on top. Reading a page about Solana volume bot cost alongside your own arithmetic is a good way to see which line a given service is charging for and which lines it is simply passing through.

Five expensive misunderstandings

• Thinking the network fee is the cost. It is about one per cent of the total in the example above. The venue rate and price movement are where the money goes.
• Raising tolerance to stop failures. This does stop failures. It also accepts every price the pool offers, which on a shallow pool can be considerably worse than failing would have been.
• Forgetting failed transactions cost money. They pay base and priority fees. In a tight-tolerance run on a busy pool this line can exceed the venue fee.
• Ignoring rent on many wallets. A few hundred wallets lock up a meaningful amount of SOL, and it only comes back if something closes the accounts afterwards.
• Comparing quotes without comparing depth. A better quote from a shallower pool can turn into a worse fill the moment anybody else trades.

Every one of those is checkable before you spend anything. Read the venue rate, look at the pool depth, decide your trade size from the depth rather than from a round number, and price the failures. The next explainer moves from money to keys, which is the other thing a beginner can lose quickly and permanently.