Archived article · Original source date: 2024-08-13
This article is preserved from the previous Solana Bulls site as a historical archive. It reflects its original context; references to products, people, market conditions, eligibility, or rules may no longer be current.
Editorial note: This article is educational and is not financial, investment, legal, or tax advice. Products, protocols, yields, fees, liquidity, regulations, and tax treatment can change; verify current primary sources and evaluate the specific risks before acting.
Solana's fee model is designed to price signature verification and optional transaction priority while discouraging spam. Fees remain workload-dependent, and low average fees do not guarantee immediate inclusion.
The two components of a Solana transaction fee
The base fee is charged per signature. The current protocol value is 5,000 lamports per signature, although applications should rely on current RPC and documentation rather than hard-coding assumptions indefinitely.
An optional priority fee is calculated from the requested compute-unit limit and compute-unit price. Setting a higher price can improve scheduling priority, but an unnecessarily high compute limit can cause a user to overpay because the fee uses the requested limit rather than actual consumption.
Compute budgets and transaction design
Programs consume compute units as they execute. Applications should simulate transactions, estimate an appropriate compute-unit limit, choose priority fees deliberately, and handle recent-blockhash expiry, retries, and confirmation states.
Transactions also declare the accounts they read and write. Transactions competing for the same writable accounts can face local contention even when the rest of the network has capacity, so there is no single global gas auction that describes every Solana workload.
Who receives the fees
Under the current fee distribution, 50% of the base fee is burned and 50% goes to the block-producing validator. Priority fees are not burned; 100% go to that validator.
Failed and expired transactions
A transaction can still be charged fees when execution fails because validators performed signature verification and processing work. An expired transaction that never lands is a different submission state, so wallets and applications should present simulation, submission, execution, and confirmation errors clearly.
Practical guidance
- Use current fee estimates instead of fixed historical averages.
- Simulate before signing when the wallet or application supports it.
- Review compute limits and priority-fee settings for high-value transactions.
- Treat low fees as a network characteristic, not a guarantee of safety, profitability, or inclusion.
Fee parameters and validator economics can change through implemented network upgrades. Consult the current Solana fee documentation when building or making operational decisions.