Key takeaways
- A Solana priority fee costs the compute unit price in micro-lamports times the compute unit limit, divided by 1,000,000 and rounded up, and it goes entirely to the block-producing validator.
- On 5 October 2026, getRecentPrioritizationFees returned zero for every one of 450 sampled slots network-wide, while the Raydium SOL-USDC pool's median slot minimum was 10,000 micro-lamports.
- At 10,000 micro-lamports per compute unit, a 200,000-unit Solana swap pays 2,000 lamports of priority fee, or 0.000002 SOL, on top of the 5,000-lamport base fee.
- Solana charges the priority fee on the compute unit limit you request, not on the units used, so simulating the transaction and requesting about 10% above its consumption is the cheapest optimization.
- Phantom adds its own priority fee automatically, set to Auto by default, unless the transaction already carries compute budget instructions or signatures.
The short answer
For a plain SOL or token transfer between quiet wallets, the priority fee you need on Solana is often zero, and wallets add a small one anyway. For a swap on a busy pool, the slot-by-slot minimums on 5 October 2026 sat at about 1,700 to 10,000 micro-lamports per compute unit, which is roughly 350 to 2,000 lamports on a 200,000-unit swap. Hot launches can demand 100 times more. Set a tight compute unit limit before you raise the price.
What exactly is a Solana priority fee?
A Solana priority fee is an optional bid, in micro-lamports per compute unit, that a validator's scheduler uses to order transactions competing for the same accounts. The formula, from Solana's documentation, is:
priority fee (lamports) = ceil(compute unit price × compute unit limit ÷ 1,000,000)
One SOL is 1,000,000,000 lamports and one lamport is 1,000,000 micro-lamports. The price is set with the Compute Budget program's SetComputeUnitPrice instruction and the limit with SetComputeUnitLimit. The whole priority fee goes to the validator that produces the block, while the 5,000-lamport base fee per signature is split half burned, half to the validator. The base fee and the difference between fees and rent are covered in Solana transaction fees explained; this post is about choosing the priority number.
One recent change for developers: Solana's documentation now describes a v1 transaction format in which the priority fee is an absolute total in lamports set in the message, and Compute Budget instructions are ignored. Everything below applies to the legacy and v0 transactions that wallets have long used.
What were real priority fees on 5 October 2026?
On 5 October 2026, between 10:22 and 10:28 UTC, I queried getRecentPrioritizationFees on mainnet and got three very different answers depending on which account I asked about. The method returns, for each of the last 150 slots, the lowest priority fee paid by a transaction in that slot that write-locked the accounts you pass. I sampled 750 slots per account.
| Accounts queried | 25th percentile | Median | 75th percentile | 90th percentile | Highest slot minimum |
|---|---|---|---|---|---|
| None (network-wide) | 0 | 0 | 0 | 0 | 0 |
| Orca Whirlpool SOL-USDC pool | 863 | 1,743 | 5,460 | 33,823 | 5,998,944 |
| Raydium AMM v4 SOL-USDC pool | 2,120 | 10,000 | 10,000 | 13,032 | 9,999,620 |
| A pump.fun fee recipient account | 0 | 10,000 | 500,000 | 1,000,000 | 135,593,312 |
All values are micro-lamports per compute unit, and they are per-slot minimums, so treat them as floors rather than the going rate. Three things stand out:
- Network-wide, the floor was zero in all 450 slots I sampled. Nearly every block contains at least one transaction that paid nothing, which is why the bare call is useless for pricing.
- Two SOL-USDC pools on the same minute differed by about six times at the median. Solana's fee markets are local to the accounts being written.
- The pump.fun account had the widest range, from zero to over 135 million micro-lamports, because launch snipers compete for the same accounts in bursts.
Other sources agreed in shape. My RPC provider's estimator (Helius getPriorityFeeEstimate) suggested 4,777 micro-lamports for "low", 8,547 for "medium" and 21,126 for "high" on the Raydium pool. These numbers are a snapshot of six minutes; the Priority Fee tracker recomputes them every 10 seconds.
How much does each price actually cost?
The cost in SOL is tiny at normal prices because it is the price times the compute unit limit, divided by a million. The table shows lamports of priority fee, before the 5,000-lamport base fee.
| Price (micro-lamports/CU) | SOL transfer (450 CU) | Token transfer (6,500 CU) | Swap (200,000 CU) | Swap with a 500,000 limit | Maximum limit (1,400,000 CU) |
|---|---|---|---|---|---|
| 1,000 | 1 | 7 | 200 | 500 | 1,400 |
| 10,000 | 5 | 65 | 2,000 | 5,000 | 14,000 |
| 100,000 | 45 | 650 | 20,000 | 50,000 | 140,000 |
| 1,000,000 | 450 | 6,500 | 200,000 | 500,000 | 1,400,000 |
The bottom right cell is 0.0014 SOL, the most a single transaction pays at a million micro-lamports. The middle rows are where most retail swaps live: 2,000 to 20,000 lamports, or 0.000002 to 0.00002 SOL. If a number of lamports is hard to picture, the lamports converter and the SOL to USD converter put it in SOL or dollars.
How do you choose a value?
Choose a value from the fee market for the accounts your transaction writes to, then pick a percentile that matches how much a delay would cost you. A practical order:
- Find the writable accounts. For a swap that is the pool and its vaults; for a mint, the mint and its config. A plain transfer touches only the two wallets.
- Query the fee market for those accounts. Pass them to
getRecentPrioritizationFees, or paste them into the tracker, which shows the 25th, 50th, 75th and 90th percentiles as Low, Medium, High and Turbo. - Pick a tier by urgency. Low or Medium for a transfer or a swap on a quiet token, High for a busy pool, Turbo only when missing a block is genuinely expensive, such as a contested launch or a liquidation.
- Simulate and set the limit. Run
simulateTransaction, readunitsConsumed, and request about 10% more, which is the margin Solana's compute budget documentation recommends. - Re-check if it does not land. If the transaction expires, query again rather than doubling blindly; a stale price is a more common cause than a low one.
Why does the compute unit limit matter more than the price?
The compute unit limit matters because Solana charges the priority fee on the limit you request, not on the units you use. A transaction with no explicit limit gets a default of 200,000 compute units per non-builtin instruction (3,000 for builtin programs such as System), capped at 1,400,000 per transaction, and pays the price on all of it.
The waste is visible on chain. In a small sample of 27 successful swaps through the two SOL-USDC pools above, which I decoded on 5 October 2026, the median transaction consumed about 223,000 compute units but requested about 500,000, roughly 2.1 times what it used; 20 of the 27 requested more than 1.5 times. At the same price, a limit of 245,000 would have cut the typical priority fee by about half. It is a tiny sample, mostly from automated traders, so read it as an illustration, not a statistic.
You can check any transaction yourself: the Transaction Decoder reads the Compute Budget instructions, splits the fee into base and priority parts, and shows units consumed next to the limit requested.
What do wallets do automatically?
Most wallets set a priority fee for you, so you only need these numbers if you build transactions or want to override the default. At the time of writing, in October 2026:
- Phantom calculates and adds a priority fee at signing, priced on the accounts involved, as long as the transaction has no signatures yet and no compute budget instructions of its own. Its documentation asks dApp developers to leave the fee to the wallet. The user setting defaults to Auto and can be switched to a custom amount in SOL.
- Solflare announced automatic priority fees in January 2023: in-wallet transactions are priced at the current market rate and the fee rises slightly when the network is under load. Check its settings for the current manual options.
- Apps and bots that set their own compute budget instructions keep control, which is why trading bots often pay far more than a wallet would.
The practical consequence: if a dApp sets a large limit and a high price, Phantom does not override it, and you pay what the dApp chose. The decoder shows what you actually paid afterwards.
When does a higher priority fee not help?
A higher priority fee does not help when the transaction is invalid, expired or never reaches the leader, and those cause most "stuck" transactions. Common cases:
- Expired blockhash. A transaction is valid for only about 150 blocks. Re-sign with a fresh blockhash.
- Failing simulation or slippage. A swap that fails on slippage still pays its fee if it lands; raising the fee just makes the failure cost more.
- Overloaded or non-forwarding RPC. The transaction never reaches the block producer, whatever it bids.
- Compute budget exceeded. A limit set too low fails the transaction and still charges the fee.
These, with the error messages that go with them, are covered in why Solana transactions fail.
Where do Jito tips fit in?
A Jito tip is a separate SOL transfer to one of Jito's tip accounts, paid when you send through Jito's block engine, and it is not the same thing as a priority fee. Jito's documentation sets the minimum tip at 1,000 lamports, notes that tips only help when the current leader runs the Jito-Solana client, and suggests splitting about 70% priority fee and 30% tip when sending single transactions. On 5 October 2026 at 10:28 UTC, Jito's tip floor endpoint reported landed tips of 3,672 lamports at the median and 10,000 at the 75th percentile. For ordinary wallet use you can ignore tips; they matter to bots and to bundles that must land together.
How does SOLTidy handle priority fees?
I built the free Priority Fee tracker because the network-wide number is almost always zero and therefore misleading. It samples the last 150 slots every 10 seconds, lets you paste up to 128 writable accounts to see their own market, shows what each tier costs for a transfer, token transfer, swap and NFT mint, and gives a ready setComputeUnitPrice snippet. It needs no wallet and sends nothing. If you want to see where your SOL went across many past transactions, including the deposits locked in empty token accounts, a Solana wallet cleanup scan is the other half of that picture.
The same numbers apply on the command line: spl-token commands take a price with --with-compute-unit-price, for example when closing token accounts with the CLI.
Bottom line
Most Solana transactions need a small priority fee or none: on 5 October 2026 the network-wide floor was zero and two major SOL-USDC pools sat at roughly 1,700 to 10,000 micro-lamports at the median. Query the fee market for the accounts you actually write to, pick a percentile by urgency, and set the compute unit limit about 10% above simulated usage, which often saves more than any price change. If a transaction still does not land, look for an expired blockhash or a failing simulation before raising the bid.
Questions & answers
What is a good priority fee on Solana right now?
It depends on the accounts your transaction writes to, so check them live. On 5 October 2026 the network-wide minimum was zero in every sampled slot, the Orca SOL-USDC pool's median slot minimum was about 1,700 micro-lamports per compute unit and the Raydium SOL-USDC pool's was 10,000. For a swap of about 200,000 units, 10,000 micro-lamports costs 0.000002 SOL. Hot launches can need a hundred times that.
Does Phantom set the priority fee for me?
Yes. According to Phantom's documentation, it calculates and adds a priority fee at signing time, priced on the accounts involved, unless the transaction already has signatures or its own compute budget instructions. The setting defaults to Auto, and at the time of writing it can be changed to a custom amount in SOL. Most users never need to touch it.
Why do I pay a priority fee for compute units I did not use?
Because Solana charges the priority fee on the compute unit limit the transaction requests, not on what it consumes. A transaction without an explicit limit gets 200,000 units per non-builtin instruction, up to 1,400,000. Requesting a limit about 10% above the simulated consumption, as Solana's documentation suggests, removes the overpayment without risking a compute budget error.
Is a higher priority fee always faster?
No. A priority fee only changes the order among valid transactions competing for the same accounts in the same block. It does nothing for a transaction with an expired blockhash, one that fails simulation, one dropped by an overloaded RPC, or one that fails on slippage. Past the point where you are ahead of the competing transactions for your accounts, extra fee buys nothing.
What is the difference between a priority fee and a Jito tip?
A priority fee is set with compute budget instructions and paid by the protocol to whichever validator produces the block. A Jito tip is an ordinary SOL transfer to one of Jito's tip accounts, used when sending through Jito's block engine, and only helps when the current leader runs the Jito-Solana client. Jito's own docs suggest splitting about 70% priority fee and 30% tip for single transactions.
Do I get the priority fee back if my Solana transaction fails?
No. A transaction that lands in a block and then fails pays the base fee and the full priority fee, charged on the requested compute unit limit. Only a transaction that never lands, for example because its blockhash expired, costs nothing. That is why simulating before sending matters more than raising the fee.
