Solana’s optional priority fee increases a transaction’s scheduling priority; it does not guarantee inclusion, success or faster execution. For legacy and versioned-v0 transactions, the fee equals the requested compute-unit limit multiplied by the compute-unit price, divided by 1,000,000 micro-lamports per lamport and rounded up to a whole lamport. It is based on the requested limit, not actual compute consumed. Solana’s v1 format instead stores an absolute priority-fee total in lamports, so the per-CU formula should not be carried across to v1.
01 / TWO COMPONENTS
Base Transaction Fees Versus Priority Fees
Every Solana transaction pays a base fee in SOL. Official documentation currently defines it per signature. The optional priority component adds an economic incentive for the leader to schedule the transaction relative to competing transactions.
The components are calculated differently and distributed differently. A base fee exists even when the priority price is zero. Neither component is a swap-pool fee, trading-platform charge, optional block-engine tip, slippage or price impact. The broader Solana trading fees guide maps those other layers.
02 / COMPUTATIONAL BUDGET
Compute Units and Compute-Unit Price
A compute unit (CU) measures computational work performed by Solana’s runtime. For legacy and v0 transactions, a compute-budget instruction can request the maximum CUs the transaction may consume, while another assigns a price in micro-lamports to each requested CU.
The limit is a ceiling, not a prediction of actual consumption. Solana’s documentation explicitly states that the priority fee uses the requested limit. If a transaction requests 300,000 CUs but consumes 180,000, its fee calculation still uses 300,000. Developers can simulate transactions and include a safety margin rather than using an unnecessarily large limit.
03 / FORMULA
How the Prioritisation Fee Is Calculated
For legacy and v0 transactions, official documentation gives:
micro-lamport fee = compute-unit price × compute-unit limit
priority fee in lamports = ceiling(micro-lamport fee ÷ 1,000,000)
The ceiling matters when division does not produce a whole lamport. For example, 1 micro-lamport per CU across a 200,000-CU limit yields 0.2 lamports before rounding and therefore a 1-lamport priority fee.
Solana’s current documentation says v1 transactions set the priority fee as an absolute lamport total in message configuration. ComputeBudget instructions do not configure v1 priority.
04 / DIMENSIONS
Micro-Lamports, Lamports and SOL
Keep the units attached through every step:
- 1 SOL = 1,000,000,000 lamports.
- 1 lamport = 1,000,000 micro-lamports.
- Therefore 1 SOL equals 1,000,000,000,000,000 micro-lamports.
A compute-unit price is not a SOL amount by itself. It is micro-lamports per CU. Multiply by the requested CU limit to obtain micro-lamports, then convert. Losing the “per CU” dimension is a common source of million-fold errors.
05 / CHANGING CONDITIONS
Why Priority Fees Vary
Applications can choose different compute limits and CU prices. Network demand, competition for writable accounts, the programs invoked and application estimates can influence what a sender considers competitive. A complex swap may need a different compute limit from a simple transfer.
There is no universal priority fee that works for every transaction or moment. Static presets can become stale. A higher value increases cost and may improve relative scheduling priority, but it cannot repair an invalid transaction or guarantee market execution.
06 / SCHEDULING
Network Congestion and Transaction Inclusion
Validators operate under block and account-related resource limits. During competition, the scheduler considers reward relative to estimated cost. A transaction can still be delayed, dropped or fail because of blockhash expiry, account contention, program conditions, compute exhaustion or changing state.
Priority affects scheduling economics, not final application outcome. A quickly scheduled swap can still fail its minimum-output condition. It can also execute with a result affected by current liquidity. Read the slippage guide for that separate risk.
07 / SEPARATE INCENTIVES
Priority Fees Versus Optional Tips
A protocol priority fee is part of Solana’s transaction-fee mechanics. Some submission paths can include a separate tip or “bribe” to a block engine, validator or delivery service. Axiom’s documentation presents priority fee and MEV-related bribe settings separately.
Do not add a labelled tip to “priority fee” and then describe the sum as Solana’s protocol formula. Identify the recipient and instruction. Platform fee, base fee, priority fee and optional tip are distinct even when one interface displays them together.
08 / VERIFY THE RECORD
How to Inspect Fees in a Transaction
- Open the transaction signature in a reputable explorer.
- Confirm status, fee payer and transaction version.
- Read the total network fee reported by the record.
- For legacy or v0, inspect Compute Budget instructions for CU limit and CU price.
- Separate other SOL transfers or tips from the protocol fee.
- Review compute consumed as an execution metric, not the legacy/v0 fee basis.
- Check application-level charges in program instructions and balance changes.
The Axiom guide covers pre-signing review, while the Axiom fee page focuses on platform charges.
09 / WORKED EXAMPLE
Hypothetical Priority-Fee Calculation
Assume a legacy or v0 transaction requests a 200,000 CU limit and specifies 1,000 micro-lamports per CU.
| Step | Calculation | Result |
|---|---|---|
| Multiply | 200,000 CU × 1,000 micro-lamports/CU | 200,000,000 micro-lamports |
| Convert to lamports | 200,000,000 ÷ 1,000,000 | 200 lamports |
| Convert to SOL | 200 ÷ 1,000,000,000 | 0.0000002 SOL |
The arithmetic is exact because the micro-lamport total divides evenly. This priority amount is added to the applicable base fee; it does not include platform, pool or optional-tip costs. It uses requested 200,000 CUs even if actual consumption is lower.
10 / COMMON ERRORS
Common Priority-Fee Misconceptions
- “Higher priority guarantees inclusion.” It only changes scheduling incentives.
- “I pay for CUs consumed.” Legacy/v0 priority uses the requested limit.
- “Micro-lamports are the same as lamports.” One lamport equals one million micro-lamports.
- “Priority includes the base fee.” They are separate components of total network fee.
- “A tip is the priority fee.” Optional delivery tips can be distinct transfers.
- “The per-CU formula applies to every version.” Current v1 transactions use an absolute lamport total.
An excessively low value can reduce competitiveness, while an unnecessarily high limit or price increases cost without guaranteeing success.
11 / PRIMARY EVIDENCE
Sources and Method
- Solana — Fees
- Solana — Fee structure and formula
- Solana — Compute budget
- Solana — Versioned transaction differences
- Axiom — Solana settings
Checked 19 October 2026. Formula, conversions and version caveat come from current official Solana documentation. The worked values are hypothetical.
12 / FAQ
Frequently Asked Questions
What is a Solana priority fee?
It is an optional network fee that increases scheduling priority relative to competing transactions.
How is it calculated?
For legacy and v0, multiply requested CU limit by micro-lamports per CU, divide by one million and round up to lamports.
Is the fee based on actual compute used?
No for legacy and v0. Official documentation says it uses the requested compute-unit limit.
Does priority guarantee confirmation?
No. It can improve scheduling priority but cannot guarantee inclusion, success or execution speed.
How many lamports are in one SOL?
One SOL equals one billion lamports.
Does the same formula apply to v1 transactions?
No. Current Solana documentation says v1 stores an absolute priority-fee total in lamports.
13 / THE TAKEAWAY
Keep the Units and Transaction Version Visible
Priority-fee reasoning is straightforward when every dimension remains attached: requested CUs multiplied by micro-lamports per CU, converted to lamports for legacy and v0. Then separate base fees, tips and trading costs—and remember that paying more changes incentives, not certainty.