The Full Cost Breakdown of a Solana Swap

Execution cost crypto discussions usually collapse into a single number, and that number is almost always the pool fee. It is the smallest interesting part of the answer. One Solana swap carries seven distinct cost lines, each computed differently, each driven by something different, and each reduced by a different lever with a different trade-off. Until they are separated you cannot tell whether your last trade was expensive because of the network, the pool, your own size, or your own impatience.

The seven lines in one swap

The cost of getting from one token to another is the sum of the following, and nothing you do removes a line entirely. The most you can do is move cost from a line where it is expensive to a line where it is cheap, which is the entire discipline of execution.

1. Base network fee. A fixed lamport charge per signature, independent of value moved.
2. Priority fee. A bid for inclusion, computed from a compute unit price and a compute unit limit.
3. Protocol or pool fee. A percentage of the input amount taken by each pool you route through.
4. Spread or quoting margin. The gap between the rate you were quoted and the true mid at that instant.
5. Price impact. The cost your own size imposes by moving the pool along its curve.
6. Failed attempts. Fees paid on reverts, plus the price drift that occurs while you retry.
7. Adverse selection. The systematic loss from trading against better informed flow, including sandwiching.

Lines one and two are paid in lamports and are known before you sign. Line three is a stated percentage and is also knowable. Lines four through seven are the ones that vary, that are invisible on the confirmation screen, and that account for most of the difference between two traders executing the same idea.

Line one: the base network fee

Solana charges a base fee of 5,000 lamports per signature on a transaction. SOL carries nine decimals, so one lamport is 0.000000001 SOL and 5,000 lamports is 0.000005 SOL. A single signature transaction therefore pays 0.000005 SOL to be processed, and a transaction requiring two signatures pays twice that. The charge is entirely independent of the value being moved: a swap of one unit and a swap of ten thousand units pay the same base fee.

There is essentially no lever here. You cannot negotiate the rate, and the only structural saving is to avoid transactions you did not need in the first place, such as separate approvals or account setup steps that could have been bundled into the same transaction. The base fee matters not because it is large but because it is fixed, which as we will see is what makes it dominate the cost of very small orders.

Line two: the priority fee

The priority fee is the part of your network cost that you actually control. It is not a flat charge; it is the product of two numbers you specify.

Two consequences follow immediately. First, doubling the compute unit price doubles what you pay for the same work, which is the intended mechanism: you are bidding for earlier inclusion when blocks are contested. Second, and far less well understood, doubling the requested compute unit limit also doubles what you pay, even if the transaction consumes exactly the same compute as before.

That second point is where money is quietly wasted. If a swap actually consumes around two hundred thousand compute units and you request the full 1,400,000 cap as a safety margin, you pay seven times the priority fee for identical priority. Requesting a realistic limit, sized from what the transaction genuinely uses with a modest buffer, cuts the line directly. The trade-off is that a limit set too tightly causes the transaction to run out of compute and fail, which moves the cost to line six.

The other lever is timing. Priority pricing responds to contention, and contention is not constant. Sending a non-urgent order into a quiet period costs less for the same probability of landing. The trade-off is obvious: waiting exposes you to price movement, which is a different line of the same cost sheet. The details of how a transaction is constructed and priced are documented in the Solana fees reference.

Line three: protocol and pool fees

Every pool takes a fee from the input amount of each swap that passes through it. The rate is a property of the pool, set as a fee tier, and it varies enormously between pool types: stable pairs typically sit at the low end because inventory risk is small, while volatile or newly launched pairs sit far higher to compensate liquidity providers. Read the tier of the specific pool you are routing through rather than assuming a market-wide number.

The part that catches people out is that this line multiplies with hops. A route that passes through two pools charges two fees, each on the amount arriving at that pool. The combined effect compounds rather than adds, because the second fee applies to an amount that the first fee has already reduced.

The lever is route length. A shorter route pays fewer fees and consumes fewer compute units, which also reduces line two. The trade-off is that the short route may not have the depth your order needs, pushing cost into line five. This is the classic tension between a direct swap and an aggregated one, examined in full in our comparison of aggregators versus direct pool swaps.

Lines four and five: quoting margin and price impact

These two are frequently merged and should not be. They have different causes and different remedies.

The quoting margin is the difference between the rate you were offered and the true mid price at that instant. Part of it is genuine compensation for the risk taken by whoever is quoting you, part of it is staleness in the data behind the quote, and part of it may simply be a margin embedded in the interface. It exists even for an order small enough to have no impact at all, which is precisely how you can measure it: quote a trivially small size and compare the implied rate to an independent reference. Whatever gap remains is margin, not impact.

Price impact is the cost created by your own order moving the pool along its curve. On a constant product pool obeying x * y = k, an order equal to a given fraction of the input reserve produces an average impact of roughly that same fraction. It is not a fee paid to anyone; it is value transferred to the pool and, shortly afterwards, to whoever arbitrages the pool back. It is the only line on this sheet that you create entirely by yourself, and the only one that scales worse than linearly with your size. Sizing it deliberately is the subject of our note on trade sizing against pool depth.

Line six: the cost of failed attempts

A transaction that is included in a block and then reverts still pays. The validator performed the work, so the base fee and any priority fee are charged whether or not your swap succeeded. On Solana this line accumulates faster than people expect, because slots target roughly four hundred milliseconds and a trader chasing a moving price may burn through several attempts in a handful of seconds.

The lamport cost of those reverts is usually the smaller half of the problem. The larger half is opportunity cost. While you retry, the price you were chasing continues to move, and the fill you eventually get is measured against a quote that no longer exists. A trade that reverts three times and then fills at a materially worse rate has paid three sets of fees plus the entire drift, and only the fees appear anywhere you can easily see them.

The levers are a wider slippage tolerance, a higher priority fee, a fresher quote, or a smaller order. Each moves cost somewhere else. A wider tolerance raises exposure to line seven. A higher priority fee raises line two. A smaller order raises the number of transactions and therefore the total of lines one and two. There is no configuration that eliminates failure cost, only configurations that price it more sensibly for your urgency.

Line seven: adverse selection

The last line is the one with no receipt. Adverse selection is the systematic cost of being the less informed side of a trade. In its sharpest form it is sandwiching: your pending order is observed, a trade is placed ahead of it to move the price against you, and a closing trade captures the difference after your fill lands. But the general case is broader and does not require anyone to target you specifically. If you consistently buy into flow that already knows something, you consistently pay for it.

What makes an order attractive to this line is predictability and headroom. A large order in a thin pool with a wide tolerance offers a known direction and a known amount of room to move the price. Reducing any of those three reduces the exposure. Tightening tolerance is the most direct lever, and the trade-off is a direct increase in line six, since a tight tolerance is exactly what causes reverts.

Because this line leaves no explicit charge, the only way to know you are paying it is to measure fills against a benchmark over many trades and look at the distribution rather than any single result. That measurement discipline, including how to compute realised slippage from transaction data, is covered in our guide to measuring execution quality.

How the lines scale and where they cross over

The seven lines do not respond to order size in the same way, and this is the most useful structural fact on the page. Lines one and two are fixed in absolute terms: they cost the same lamports whether you swap a small amount or a large one. Expressed as a percentage of notional, they therefore shrink as size grows. Line three is proportional: a fixed percentage regardless of size. Line five is worse than proportional: the value forfeited to impact grows roughly with the square of your share of the pool's reserves.

Plot those against size and they cross. Below the crossover, fixed lamport costs dominate and everything else is noise. Above it, impact dominates and the lamport costs are a rounding error. The crossover point can be located approximately.

Put illustrative numbers through it. A transaction paying 5,000 lamports of base fee plus 10,000 lamports of priority fee costs 15,000 lamports, or 0.000015 SOL. Against a pool holding 10,000 SOL of input reserve, the crossover sits near the square root of 0.15, which is about 0.39 SOL. Below roughly that size you should be optimising compute units and retries; above it you should be optimising routing and sizing, and the fee tinkering is wasted effort.

This single calculation resolves most arguments about execution. A trader moving very small amounts and a trader moving large amounts are optimising genuinely different cost functions, and advice that is correct for one is close to useless for the other.

Build your own cost sheet

The table below is the working document. Fill in the middle columns from the specific pool and transaction you are about to send, and the right two columns tell you what you can do about each line and what it will cost you elsewhere.

The routing cost row deserves a note, because it is the one line that can move in either direction depending on what you do. Consolidating a route cuts fees and compute but concentrates your entire order into one pool, which inflates impact. Splitting it does the reverse. Working out where that balance sits for a given order is the comparison a Solana DEX volume bot is performing on every route it prices, since a console that sends the pieces across several venues has to weigh the same two directions you would weigh by hand before each order. The wider context for these decisions lives in our execution cost and quality section.

A fully summed illustrative order

The following totals one order across all seven lines. Every input is chosen for illustration only. None of these figures is an observation of any market, any pool, or any platform, and they should be treated purely as a demonstration of the arithmetic.

Work the network lines first. The base fee is 5,000 lamports. The priority fee is 200,000 multiplied by 50,000, divided by one million, which is 10,000 lamports. One attempt therefore costs 15,000 lamports, or 0.000015 SOL, and the two failed attempts add another 30,000 lamports, or 0.00003 SOL.

Now the proportional lines. Two hops at 0.25 percent compound to 1 minus 0.9975 squared, which is 0.499375 percent, or 49.94 basis points, costing 0.249688 SOL. An order equal to 0.25 percent of the input reserve produces an average impact of 0.0025 divided by 1.0025, which is 0.2494 percent, or 24.94 basis points, costing 0.124688 SOL. The three assumed lines contribute 5, 10 and 8 basis points, costing 0.025, 0.05 and 0.04 SOL respectively.

The total is 0.489421 SOL, or 97.884 basis points, just under one percent of notional. Read the shape rather than the number. All network related lines together contribute 0.009 basis points out of nearly ninety-eight. Pool fees and impact together contribute close to seventy-five. The two lines nobody sees, drift and adverse selection, contribute eighteen, which is roughly two thousand times the entire lamport cost of the transaction.

Now change one assumption. Shrink the notional from 50 SOL to 0.2 SOL and leave everything else alone. The 0.000015 SOL of network cost becomes 7.5 basis points instead of 0.003, while impact, being proportional to the share of reserves consumed, nearly vanishes. The ranking of the lines has inverted entirely without a single parameter of the network changing. That inversion, not the totals, is the point of building the sheet.

Cost per unit filled versus cost per attempt

One last distinction determines whether your cost sheet tells the truth. Cost per attempt is what you can read from a single transaction: the fees that transaction paid and the rate it achieved. Cost per unit filled is what you actually experienced: everything spent, including on attempts that filled nothing, divided by the quantity you ended up holding.

These diverge whenever attempts fail. Five attempts that produce one fill have a cost per unit filled roughly five times the fee component of a single attempt, plus whatever drift accumulated across the sequence. A configuration that looks cheap per attempt because it uses a minimal priority fee and a tight tolerance can be the most expensive configuration you run, because it fills so rarely that the successful trades carry the cost of all the unsuccessful ones.

Track both. Cost per attempt tells you whether your fee parameters are sane. Cost per unit filled tells you whether your strategy is viable. When the two diverge sharply, the gap is your landing rate problem, and it is almost always cheaper to fix that than to shave basis points off a line that was never the expensive one.

Both figures also get harder to keep honest as order count rises, because failed attempts are the first thing a manual log loses. Anything running multi-venue volume automation should be judged on whether it reports attempts alongside fills; a tool that shows only the trades that landed is presenting the flattering half of this arithmetic, and the half it omits is the one that decides viability.

The general rule that emerges from the whole sheet is simple. Optimise the line that is largest at your size, not the line that is easiest to see. For small orders that means compute units and landing rate. For large orders it means sizing and routing. Attention spent anywhere else is attention that could have been spent on the line actually costing you money.

Frequently asked questions