By Admin2026-11-04300 min

Why Solana Transactions Have Fees

Solana Transaction-Fees Compute-Units Priority-Fees Blockchain Web3-Education tecneural-software-solutions tecneural tecneural-usa tecneuralmadurai

Understand base fees, priority fees and compute units before you approve.

You approve a transfer or interact with an app, and your wallet shows a network fee. Why is there a charge, and why can two transactions cost different amounts? The answer starts with the work the network performs and the resources your transaction requests.

Solana transactions pay fees in SOL. A base fee compensates for signature verification, while an optional priority fee can improve scheduling priority when transactions compete. Fees also place a cost on submitting work to a network with limited capacity. [1]

THE NETWORK FEE HAS TWO PARTS

Base fee: Signature-based charge

Priority fee: Optional scheduling fee

Total fee: Base fee + Priority fee = Paid in SOL

Figure 1. Total network fee = base fee + priority fee. Transfers and app-specific charges are separate.

Start with the base fee

The documented base rate is currently 5,000 lamports per chargeable signature. A simple transaction with one signature and no extra signature-verification precompiles therefore starts at 5,000 lamports, or 0.000005 SOL. One SOL equals one billion lamports. [1, 2]

Count signatures, not just instructions. Additional signatures verified by supported precompile programs can also enter the base-fee calculation. Of the base fee, 50% is burned and 50% goes to the block-producing validator; the priority fee goes entirely to that validator. [1, 2]

CHECK THE TRANSACTION FORMAT

This guide labels legacy/v0 compute-price examples separately from v1, which sets a total priority fee directly in its message configuration. Inspect the actual format rather than applying one formula to every transaction. [4]

Compute units measure execution work

A compute unit (CU) measures execution work. Operations consume units while a program runs. A transfer and a multi-step interaction can use different amounts. The SOL transferred is a separate quantity. [2, 3]

Term — Meaning for legacy/v0 transactions

CU consumed: The execution work actually used by the transaction.
CU limit: The maximum execution budget requested for the transaction.
CU price: An optional price in micro-lamports per requested CU, used to calculate the priority fee.

Requested budget and actual use differ

ILLUSTRATIVE EXECUTION BUDGET

80,000 CUs used | 20,000 spare

Figure 2. A 100,000-CU limit leaves headroom above 80,000 CUs consumed. This is an arithmetic example, not a benchmark.

For legacy/v0 transactions, the priority fee uses the requested CU limit, even if execution consumes less. At a nonzero CU price, an unnecessarily large limit raises the fee. A limit that is too small can cause execution to fail when the budget is exhausted. [2, 3]

Legacy/v0 transactions configure this with SetComputeUnitLimit and SetComputeUnitPrice. The documented maximum CU limit for those transactions is 1,400,000. When no explicit limit is supplied, defaults depend on instruction type and count; do not assume every transaction has a 200,000-CU budget. [3]

Estimate before choosing a limit

Use simulateTransaction to inspect execution errors, logs and unitsConsumed without broadcasting a transaction. Add suitable headroom to an estimate, then validate representative cases. Simulation uses a snapshot of chain state; conditions may change before execution, so a successful simulation is not a promise of success. [5]

TWO DIFFERENT CONTROLS

The limit sets how much execution work is allowed. The price sets the legacy/v0 priority-fee rate. Raising a price does not give a program more compute capacity.

A priority fee is a scheduling incentive

A higher priority fee can improve a transaction's scheduling priority, but inclusion also depends on resource constraints and competing work. It cannot repair a bad instruction, supply a missing signature or make an expired transaction valid. [1, 2]

LEGACY / V0 FORMULA

Priority fee in lamports = round up (CU limit x CU price in micro-lamports / 1,000,000).

One lamport contains 1,000,000 micro-lamports. [2]

Worked example: one signature

Assume a 5,000-lamport base fee, a 100,000-CU limit and a price of 10,000 micro-lamports per CU. These chosen values illustrate the calculation; they are not a current fee recommendation.

Calculation — Result

100,000 x 10,000 / 1,000,000 = 1,000 lamports priority fee
5,000 + 1,000 = 6,000 lamports total network fee
6,000 / 1,000,000,000 = 0.000006 SOL

Change one input, compare the result

Requested CU limit | Price: micro-lamports/CU | Priority fee: lamports

100,000 | 10,000 | 1,000
200,000 | 10,000 | 2,000
100,000 | 20,000 | 2,000

All three rows use the same formula and exclude the base fee. If actual consumption stays at 80,000 CUs, the requested-limit calculation still applies. Keep units visible: confusing micro-lamports with lamports changes the number by a factor of one million.

V1 USES A DIRECT TOTAL

In the documented v1 format, set the priority fee as an absolute lamport amount in the message configuration. Here, 1,000 lamports of priority fee plus 5,000 of base fee still totals 6,000. V1 limits belong in the message configuration; ComputeBudget instructions do not set them. [4]

Use the message and the receipt

For supported legacy/v0 messages, getFeeForMessage returns the network fee in lamports for the serialized message. Include the intended budget and price settings. getRecentPrioritizationFees supplies recent samples, optionally filtered by writable accounts; historical samples are inputs to an estimate, not guaranteed future prices. [6, 7]

A PRACTICAL FEE REVIEW WORKFLOW

Simulate: Inspect work + errors
Set budget: Choose limit + fee
Review fee: Check before signing
Verify result: Read confirmed receipt

Figure 3. Estimation helps before submission; the confirmed transaction records what actually happened.

Three details worth checking

Failure can still cost. When an on-chain transaction reaches execution and fails, its instruction state changes revert but the transaction fee remains charged. A simulation or rejected submission is not the same event. Check chain status before treating a wallet error as a charged execution. [8]

A balance change includes more than fees. Transfers, account-creation funding and application charges can also move SOL. Distinguish these from the network fee. Use getTransaction to inspect the confirmed result and its metadata rather than equating every balance reduction with a fee. [9]

Keep the units in the interface. Show the final total in SOL and the fee components in lamports. Label any app charges separately. If an app sponsors fees, make the fee payer clear so the user can understand who is paying.

THE TAKEAWAY

Read the base fee, transaction format and priority setting together. For legacy/v0, right-size the requested CU limit as well as the price. After submission, verify the actual status and fee.