Solana is known for low transaction costs, but its fee system is not simply “one tiny fixed fee.” A transaction pays a base fee tied to signatures and can add a priority fee based on the compute-unit limit requested by the sender. Choosing an unnecessarily high limit can overpay even when the program uses less computation.
Quick answer: Solana’s total transaction fee is the base fee plus any prioritization fee. The priority fee is calculated from the requested compute-unit limit and the compute-unit price, not from the compute units actually consumed.
Solana fee components
At the protocol level, think of the total as:
Total fee = base fee + prioritization fee
Other costs can appear in the user experience—exchange withdrawal charges, swap slippage, application fees, rent-related account funding, or token-account creation—but they are not all validator transaction fees.
The base fee
Solana’s official fee documentation lists a base fee of 5,000 lamports per signature at the time this article was reviewed. A lamport is the smallest unit of SOL:
1 SOL = 1,000,000,000 lamports
A simple one-signature transaction therefore has a 5,000-lamport base fee under that parameter. Multi-signature transactions can require more signatures and a higher base fee.
Protocol parameters can change, so applications should use current network data instead of hard-coding an old value.
Compute units
A compute unit (CU) measures the computational work a Solana transaction can perform. Programs consume compute as instructions execute. The transaction requests a compute-unit limit—a budget that prevents unlimited work.
The official documentation describes a maximum of 1.4 million compute units per transaction. Individual instructions also have defaults and limits. A transaction that exceeds its allowed compute budget fails, but the network still performed work to process it.
Priority fees
A sender can offer an optional price per compute unit to improve scheduling priority when block space is contested. The fee uses micro-lamports per CU, where one micro-lamport is one millionth of a lamport.
Prioritization fee in lamports = ceil(CU limit × CU price in micro-lamports ÷ 1,000,000)
The result is rounded up to the next whole lamport when the division is not exact.
Suppose a transaction requests 200,000 CUs and sets a price of 5,000 micro-lamports per CU:
200,000 × 5,000 ÷ 1,000,000 = 1,000 lamports
If it has one signature and the base fee is 5,000 lamports, the total protocol fee is 6,000 lamports.
Why requested CU limit matters
The prioritization fee is based on the requested limit, not actual consumption. If the example transaction uses only 80,000 CUs but requested 200,000, it still pays the priority calculation based on 200,000.
Developers can simulate a transaction, add a safety margin, and request a limit close to expected consumption. Too little budget can cause failure; too much can waste priority fees and may affect how the scheduler evaluates the transaction.
How priority is determined
Paying a larger priority fee can improve a transaction’s relative position, but it is not a guarantee of immediate inclusion. Solana’s scheduling formula considers the prioritization fee relative to requested resources, including compute units and other execution costs. Network leaders, account contention, transaction validity, block limits, and timing still matter.
A high CU price combined with an excessively high CU limit can be expensive. A low price with a well-sized limit may still wait during contention. Wallets and applications normally estimate both values using recent network conditions.
Why failed Solana transactions still cost a fee
Validators must verify signatures, load accounts, and attempt execution before learning that a transaction fails. The fee compensates network work and discourages spam. Common failures include:
- insufficient token balance or SOL for fees;
- slippage tolerance exceeded in a swap;
- compute budget exceeded;
- account state changed before execution;
- program error or invalid instruction data; and
- an expired recent blockhash.
Raising the priority fee does not fix invalid instructions or inadequate slippage settings.
Token accounts and rent-related balances
Solana tokens are held in token accounts. Receiving a new token may require creating an associated token account if one does not already exist. That can require a rent-exempt balance in addition to the transaction fee. The balance is not identical to a validator fee and may be recoverable when an eligible account is closed.
A wallet should distinguish the network fee from account-creation funding. If the preview combines them, open the detailed simulation.
Swap costs are larger than gas alone
For a decentralized swap, the economic cost can include:
- Solana base and priority fees;
- liquidity-provider or protocol fee;
- bid-ask spread;
- price impact from order size;
- slippage between quote and execution;
- associated token-account creation; and
- MEV or adverse transaction ordering.
Do not compare a Solana swap with a centralized exchange using network fee alone. Our CEX vs DEX guide explains the broader execution and custody differences.
Practical ways to avoid overpaying
- Use current wallet software. Fee estimation improves as applications update network integrations.
- Review the detailed preview. Separate network fee, priority fee, app fee, and token-account funding.
- Do not blindly maximize priority. Choose a level appropriate to urgency and current contention.
- Developers should simulate compute. Add a reasonable buffer instead of always requesting the maximum.
- Check slippage independently. A transaction can have a tiny protocol fee and a poor execution price.
- Keep enough SOL. Token balances cannot normally pay base fees unless an application sponsors the transaction.
- Verify every instruction. Low fees do not reduce phishing or malicious-program risk.
Solana fees vs Ethereum gas
Both networks charge for scarce computational and block resources, but the mechanisms differ. Ethereum calculates gas used multiplied by gas price components, including a protocol base fee and priority fee. Solana uses a signature-based base fee plus an optional priority fee based on requested compute budget. A number labelled “gas” in a multi-chain wallet may be a generic interface term rather than the protocol’s exact model.
For basic blockchain concepts, see how blockchains work.
Frequently asked questions
What is a lamport?
A lamport is the smallest native unit of SOL. One SOL equals one billion lamports.
Is the Solana priority fee mandatory?
No. It is optional, but applications may recommend one when the network or specific accounts are contested.
Does a higher priority fee guarantee success?
No. It can improve scheduling priority but cannot make an invalid transaction valid or guarantee inclusion by a specific time.
Why did my wallet charge more than the base fee?
The transaction may have multiple signatures, a priority fee, token-account funding, an application fee, or another economic cost shown in the same preview.
This article reflects official Solana documentation reviewed on 31 July 2026. Network parameters and wallet behavior can change.