A Solana priority fee is an optional extra fee added to a transaction to improve its chance of being processed quickly when the network is busy. It is set by the sender as a price per compute unit, quoted in micro-lamports, and it is paid in SOL on top of the base transaction fee.
Every Solana transaction pays a base fee per signature. When block space is contested, a sender can add a prioritization fee on top, and validators favour transactions that pay more of it per unit of compute. The fee is set through a compute budget instruction in the transaction itself, as a compute unit price quoted in micro-lamports per compute unit, where a micro-lamport is one millionth of a lamport. The amount paid is that price multiplied by the compute unit limit set for the transaction, and it is charged to the fee payer in SOL together with the base fee.
Most users never set it directly. Wallets and applications estimate a price from recent network conditions and attach it automatically, and many offer a setting that raises it during congestion.
A related cost that is not a priority fee is a tip paid to a bundling service that validators run, which some wallets and trading bots attach to win ordering. That is a plain SOL transfer to a tip account inside the transaction, not part of the fee field, so it appears in a transaction history as SOL sent to an address rather than as a fee.
A swap with a compute unit limit of 200,000 and a compute unit price of 10,000 micro-lamports pays a priority fee of 2,000,000,000 micro-lamports, which is 2,000 lamports or 0.000002 SOL, on top of the 5,000-lamport base fee. The same swap submitted during a congested launch with a price of 1,000,000 micro-lamports per compute unit pays 200,000 lamports, or 0.0002 SOL, forty times the base fee for the same trade.
A priority fee is treated the same way as the base fee it sits on top of, because it is paid in the same asset for the same purpose. Under Notice 2014-21 SOL is property, so the SOL spent on the fee is disposed of under section 1001, with gain or loss on those units measured against their basis. The fee is then a cost of the transaction it paid for. On an acquisition, it is added to the cost basis of the asset bought. On a sale, it reduces the amount realised. On a swap, one of those two conventions is applied and used consistently.
Where the transaction is not a purchase or a sale, such as a transfer between your own wallets or a stake account operation, the fee SOL is still disposed of, but there is no acquisition or sale for the cost to attach to. The common treatments are to add it to the basis of the asset moved or to leave it as a cost that is not deducted. Either way, the disposal of the fee units is reported.
The priority fee does not need to be separated from the base fee for tax purposes, since both are treated identically, but the total has to be right. The combined fee is what left the wallet, and the reconciliation of the SOL balance depends on carrying all of it. Tips paid outside the fee field are the same cost in economic terms and are booked the same way, once they have been identified as costs rather than as transfers to a third party.
Tips and priority fees paid through a trading bot during a congested period are the usual failure. The wallet shows hundreds of small SOL transfers to the same handful of tip addresses alongside the trades. Software reads each one as a transfer to an unknown wallet or a sale of SOL to a third party, so the report carries a long list of unmatched sends or small gains, while the cost never reaches the basis of the tokens the bot bought. The trades then show gains overstated by the total cost of getting them executed.
Read our Pros and Cons of Solana: The Future of Blockchain or a Temporary Trend? 2026 Update
CountDeFi specializes in complex DeFi tax accounting, including Solana trading bots, fee reconciliation and multi-chain activity. See pricing.
