Solana priority fees, and why the median transaction pays nothing extra
Solana charges a fixed base fee and then lets you bid for position on top of it. The bid is priced per compute unit, not per transaction, which is the detail that trips up most cost estimates. Measured across finalized blocks, the median transaction on the network bids nothing at all, while the top percentile bids many multiples of the base fee. Both facts matter when you are budgeting thousands of swaps.
How a Solana priority fee is calculated
Two instructions control this. One sets the compute unit limit, the ceiling on how much execution the transaction may consume. The other sets the compute unit price, your bid per unit. The fee you pay for priority is limit multiplied by price, converted from micro-lamports to lamports by dividing by a million.
The consequence that catches people out is that requesting a larger compute limit than you need makes your bid more expensive at the same price. Overshooting the limit is not free insurance, it is a larger bill. Conversely, setting the limit too low means the transaction runs out of compute and fails, which costs the fee anyway. Getting this right per instruction type is ordinary engineering work, and it is where a well-built engine quietly saves money.
Validators order transactions by the fee per compute unit, so what buys you position is the price of your bid rather than its total. A small transaction bidding aggressively per unit outranks a large one bidding modestly, even if the large one pays more in absolute terms.
What transactions actually bid
| Percentile | Total fee | Base fee | Priority portion |
|---|---|---|---|
| Median (p50) | 5,000 | 5,000 | 0 |
| p90 | 11,806 | 5,000 | 6,806 |
| p99 | 320,000 | 5,000 | 315,000 |
| Maximum | 15,005,000 | 5,000 | 15,000,000 |
The practical reading is that priority fees are not a general tax on activity, they are a congestion price on specific accounts. Most of the network moves without competing for anything, so it bids nothing. Your swaps are not most of the network: they compete for the accounts belonging to one token, alongside everyone else interested in that token at that moment.
This is why a launch hour costs several multiples of what a quiet hour costs while the network median stays flat. It is also why a vendor quoting one fee figure for all conditions is quoting something that cannot be true.
Contention is per account, not per network
This architecture explains almost everything about Solana fee behaviour. There is no single global queue to buy your way into. There are as many small queues as there are hot accounts, and you are only bidding in the ones your transaction touches.
For a volume campaign the contested accounts are predictable: the bonding curve or pool state for your token, plus any shared program accounts. When many wallets in your own fleet trade the same token in the same slot, they contend with each other, not just with outsiders. Spacing trades across slots is therefore both a cost control and a reliability measure, and it is one of the reasons duration is a meaningful setting rather than cosmetic.
Failed transactions from lost account locks still pay their fee, which is why measured failure rates belong in any honest cost model. The measurement page reports them per DEX program.
Budgeting priority fees for a campaign
A workable method: decide what proportion of your transactions must land within the campaign window. If timing is loose, bid low and accept retries; the cheapest strategy on a quiet pair is patience. If timing is tight, because you are targeting a specific feed window, bid at the upper percentiles from the start rather than discovering the requirement through failures.
The trap in the middle is bidding just below what is needed. Those transactions fail, pay, and retry at the same inadequate bid, producing the worst of both approaches. Under-bidding is more expensive than either bidding properly or waiting.
Full campaign arithmetic including tips and rent is in the cost breakdown. Jito tips are a separate bid with separate mechanics, covered in Jito tips explained.
What a bid actually buys differs by venue, because failure rates do. The per-venue figures are on the Solana volume bot overview and, for bonding-curve traffic specifically, on the Pump.fun volume bot page.
In practice the bid you need is set by whoever else is competing for the same accounts. That is at its worst on a live Pump.fun launch, moderate on Meteora DLMM and Orca Whirlpools where arbitrage traffic concentrates, and lowest on a settled PumpSwap or Raydium pool. Paying launch-window priority fees on a quiet pool is one of the most common ways a campaign overspends without noticing.