Solana Transaction Fees: Base Fee, Priority Fee, Compute Units

A Solana transaction pays a base fee of 5,000 lamports per signature — 0.000005 SOL, about half a thousandth of a dollar with SOL near $106 — plus an optional priority fee that you set per compute unit. A plain SOL transfer has one signature and costs the base fee; wallets usually add a small priority fee so the transaction lands quickly when the network is busy. Even with that, everyday transfers cost a fraction of a cent. The larger cost people meet on Solana is not the fee at all but rent for new token accounts, covered in the rent-exempt guide.

The base fee

The base fee is fixed per signature, not per byte or per unit of computation: 5,000 lamports (1 SOL = 1,000,000,000 lamports). Most user transactions have one signature, so they pay 5,000 lamports. Half of the base fee is burned and half goes to the validator that processes the transaction.

Compute units and the priority fee

Each transaction declares how much computation it may use, measured in compute units (CU). By default the runtime allows 200,000 CU per instruction, and a transaction can request up to 1.4 million. A SOL transfer uses only a few hundred CU; a swap through an aggregator can use several hundred thousand.

The priority fee is the compute unit price, set in micro-lamports (millionths of a lamport) per CU, multiplied by the compute unit limit the transaction requests:

priority fee (lamports) = CU limit × CU price (micro-lamports) / 1,000,000
total fee = 5,000 × signatures + priority fee

Note that the limit, not the actual usage, is what you pay for. That is why good wallets set a tight CU limit based on simulation: a 200,000 CU default with a high price pays for computation that never happens. Since early 2025 the whole priority fee goes to the validator, which gives validators a direct reason to include higher-paying transactions.

The Solana priority fee calculator does this arithmetic for any CU limit and price.

Why fees are local on Solana

Solana runs transactions in parallel and charges for contention on specific accounts. When everyone tries to trade the same new token, competition is for the accounts of that token's market, and priority fees for those transactions rise. A simple SOL transfer between two wallets does not touch those accounts and usually lands with a minimal priority fee at the same moment. This is why the “current priority fee” shown by trackers varies so much by what you are doing.

Failed transactions still cost the fee

A transaction that is processed but fails — for example a swap whose slippage limit was exceeded — still pays the base fee and the priority fee, because validators executed it. Transactions that never get processed (an expired blockhash, a dropped packet) cost nothing; you can simply resend. If your wallet shows an error like “blockhash not found”, the transaction did not land, and nothing was charged.

What this means for swaps on KOT.CASH

• Sending SOL to a deposit address: you pay the base fee and whatever priority fee your wallet adds — fractions of a cent.
• Sending USDT or USDC on Solana: same fee, but make sure you keep some SOL in the wallet; the token cannot pay its own fee.
• Receiving SOL or SPL tokens as a payout: the payout fee is included in the quote, and if a new token account has to be created for you, that cost is handled on the sending side.
• The provider waits for 200 Solana confirmations before crediting a deposit — about a minute and a half at roughly 400 ms per slot.

Choosing a priority fee in practice

For ordinary transfers, let the wallet decide. Phantom, Solflare and Backpack read recent fee levels from the network and add a priority fee that is usually a tiny fraction of a cent. Raise it only when a transaction keeps failing to land during a busy moment, such as a popular token launch, and only for transactions that touch the congested market. A sensible approach is to step up the CU price by an order of magnitude at a time rather than jumping straight to the maximum the wallet offers.

Developers and bots should also set the CU limit from a simulation rather than the default 200,000 per instruction. Halving the limit halves the priority fee at the same price, and a tighter limit makes it slightly easier for the block producer to fit the transaction in.