THE CRYPTO FIELD GUIDEEDITION 001 / 07 OCT 2026Search the atlas ↗
MARKETSBTC——ETH——SOL——Indicative USD · Loading source
Solana / Guide

Priority fees: pay attention to the compute budget

Why a Solana fee setting involves both a unit price and a requested computation limit.

Solana conceptual editorial illustration for Priority fees: pay attention to the compute budget
Conceptual editorial illustration, not a photograph or measurement of an event.
THE TAKEAWAY

A higher priority fee can influence scheduling, but it cannot guarantee a valid, successful transaction.

Two inputs drive the calculation

A Solana priority fee is calculated from the requested compute-unit limit and the price per compute unit, with the price expressed in micro-lamports. It is added to the base transaction fee. Because the requested limit matters, an unnecessarily large compute budget can increase the priority fee even if execution consumes less computation. The budget should accommodate the operation, but it is not a free number to inflate without examining the cost.

Work through the units

Suppose a hypothetical transaction requests 200,000 compute units and specifies 5,000 micro-lamports per unit. Multiplying gives one billion micro-lamports, equal to 1,000 lamports. That is the priority component, not the entire transaction cost. Doubling the requested unit limit at the same unit price doubles this component. This arithmetic illustrates the mechanism; it is not a suggested fee or an estimate of current congestion.

Price cannot repair every failure

Transactions can fail for reasons unrelated to scheduling priority, such as invalid instructions, insufficient funds, stale state or an expired blockhash. A swap can also violate its output condition after the market changes. Paying more for priority does not make those conditions disappear. Separate a transaction that was never observed, one that executed with an error and one that succeeded but has not appeared in an application's index.

Use observations, not folklore

Inspect a recent simulation and the application's full fee estimate, including possible account creation costs. Relevant account activity can matter when evaluating recent priority fees, so a network-wide number may poorly describe one congested operation. Before retrying, check the prior signature and whether the transaction remains valid. Ask which limit was requested, what price was applied and whether the displayed total includes every component. Keep any operational fee cap explicit rather than letting repeated automatic retries conceal cumulative spending.

READ THE ORIGINAL EVIDENCE

Sources & context

  1. Solana terminology: prioritisation fees ↗
  2. Solana exchange integration: fee estimation ↗

Sources checked 7 October 2026. This is explanatory coverage, not personalised investment advice. Our corrections policy.

CONTINUE EXPLORING

The next layer of context.

More Solana