What are priority fees on Solana?

An optional surcharge so the current block producer schedules your transaction ahead of competing ones. You set a price per compute unit in micro-lamports; the fee equals price times compute-unit limit divided by 1,000,000. Since February 2025, it goes 100 percent to the validator.

What are compute units?

Compute units (CU) measure the computational work of a transaction. Each instruction gets a default limit of 200,000 CU, and a whole transaction can request at most 1,400,000 CU. Setting the limit close to actual usage lowers your priority fee.

A separate SOL transfer to one of eight fixed tip accounts, with a documented minimum of 1,000 lamports. It is not part of protocol fees — it buys placement through the Jito block engine, for example for bundles of up to five atomically executed transactions.

Is part of Solana's fees burned?

Yes, but only from the base fee: 50 percent is burned and 50 percent goes to the validator. Priority fees have gone entirely to the validator since SIMD-0096 activated in February 2025. Jito tips are not burned.

Solana fees explained: base fee, priority fees, compute units, and Jito tips

Q: How much does a Solana transaction cost?

The base fee is 5,000 lamports per signature, which is 0.000005 SOL. Most transactions carry exactly one signature. On top of that, you can add an optional priority fee calculated per compute unit — for simple transactions often just a few hundred to a few thousand extra lamports.

A Solana transaction costs a base fee of exactly 5,000 lamports per signature — that is 0.000005 SOL. On top of that, you can add an optional priority fee, priced per compute unit, and in some cases a Jito tip as a separate channel. This article explains every building block — and which part gets burned.

Short answer: Solana fees consist of a fixed base fee (5,000 lamports per signature, i.e. 0.000005 SOL) and an optional priority fee (a price per compute unit in micro-lamports). Jito tips are a third, separate channel for guaranteed placement. Half of the base fee is burned; priority fees have gone entirely to the validator since February 2025.

In plain terms: You pay a fixed micro-amount for the ride — and optionally a surcharge to make your spot in the next block more likely. The surcharge scales with how much computing work you reserve for your transaction.

The base fee: 5,000 lamports per signature

Every transaction on Solana pays a fixed base fee of 5,000 lamports per signature. A lamport is the smallest SOL unit: 1 SOL equals 1,000,000,000 lamports. Most transactions carry exactly one signature — so they cost 0.000005 SOL. Even at triple-digit SOL prices, that is a fraction of a cent.

The base fee compensates validators for the cryptographic work of verifying signatures. It is always the same — whether you send a simple SOL transfer or a complex swap. A practical note: whoever sets up a wallet should always keep a small SOL reserve for fees alongside their tokens. Without SOL, no transaction leaves your wallet.

Compute units: your transaction’s computing budget

Before priority fees make sense, you need a second concept: compute units (CU). They measure how much computational work a transaction consumes — think of a fuel budget for the trip through the blockchain.

The ground rules from the Solana docs:

Each instruction gets a default limit of 200,000 CU.
Instructions of built-in programs (such as the System Program for SOL transfers) start with a default of 3,000 CU.
A whole transaction can request at most 1,400,000 CU.
With the SetComputeUnitLimit instruction, you can set the limit yourself.

Why this matters: the priority fee is charged on your requested limit, not on actual consumption. If you leave the limit generously at the default even though your transaction only needs a fraction, you overpay. Good wallets and apps estimate consumption up front and set the limit just above it.

Priority fees: the price per compute unit

The priority fee (officially: prioritization fee) is an optional surcharge so the current block producer schedules your transaction ahead of competing ones. You set it with the SetComputeUnitPrice instruction — as a price per compute unit in micro-lamports. One lamport equals 1,000,000 micro-lamports.

The formula from the official docs:

Priority fee (lamports) = compute-unit price × compute-unit limit ÷ 1,000,000, rounded up to the nearest lamport.

A worked example: you set a compute-unit price of 10,000 micro-lamports and leave the limit at 200,000 CU. The priority fee comes to 10,000 × 200,000 ÷ 1,000,000 = 2,000 lamports (0.000002 SOL). Together with the base fee, you pay 7,000 lamports — still 0.000007 SOL.

In quiet periods, transactions often land without any priority fee. In contested moments — say, a hyped token launch — the compute-unit price decides whether your transaction makes the next block or waits.

Local fee markets: congestion stays local

Solana processes transactions in parallel as long as they do not write to the same accounts. The concept of local fee markets builds on that: the scheduler caps how much of a block’s computing budget can go to any single write-locked account.

The consequence: when a single market overflows — say, the pool of a new token — the required priority fees rise mainly for transactions that want to write to exactly those accounts. The rest of the network remains largely unaffected and cheap. A traffic jam on one road does not make the whole road network expensive — an important difference from a global fee market, where every user feels the same price spike.

Jito tips: the separate channel

Beyond base fee and priority fee, there is a third channel that often gets confused: Jito tips. They are not part of protocol fees but ordinary SOL transfers to one of eight fixed tip accounts of the Jito network. The documented minimum is 1,000 lamports — though in contested phases that is rarely enough.

What it buys: Jito operates a block engine through which transactions and bundles (up to five transactions executed atomically and in fixed order) reach validators directly. The tip determines how competitive a bundle is in that auction. The surrounding world — sandwiching, arbitrage, block auctions — is covered in our article on MEV on Solana.

Relevant for users: regular apps and wallet infrastructure increasingly use this channel in the background to land transactions reliably — one example is the FullSend integration by Privy and Jito. If you spot a small extra SOL transfer to an unfamiliar account in a transaction, you are often looking at a Jito tip — no reason to panic, but a reason to look closely.

What gets burned?

The burn share sorts out like this:

Base fee: 50 percent is burned, 50 percent goes to the validator producing the block.
Priority fee: used to be half-burned as well. Since SIMD-0096 activated in February 2025, the validator receives 100 percent.
Jito tips: are not burned. They flow through the Jito system to the participating validators and their stakers.

The burn reduces the circulating SOL supply minimally — at these per-transaction amounts it is more of a protocol detail than a noticeable factor.

At a glance

Base fee: 5,000 lamports (0.000005 SOL) per signature — fixed, 50 percent of it burned.
Compute units: default 200,000 CU per instruction, maximum 1,400,000 CU per transaction.
Priority fee: compute-unit price (micro-lamports) × CU limit ÷ 1,000,000 — 100 percent to the validator since February 2025.
Local fee markets: fees only rise where accounts are contested — not network-wide.
Jito tips: separate SOL transfer to one of eight tip accounts, minimum 1,000 lamports — not part of the protocol fee.

Note: Not financial advice.

Sources

What is Solana? — the network fundamentals
MEV on Solana — bundles, auctions, and sandwiching in detail
Set up a Solana wallet — the practical entry point