Solana Transaction Fees and Local Fee Markets, Explained
June 11, 2026
Solana is famous for fees of a fraction of a cent, but "Solana fees are cheap" is only half the story. The mechanism behind those low fees, the local fee market, is one of the most misunderstood parts of the network, and misunderstanding it is exactly why some users overpay while others watch their transactions silently fail. This guide explains how fees actually work in 2026, account by account.
Quick answer
A Solana fee has two parts: a fixed base fee of 5,000 lamports (0.000005 SOL) per signature, and an optional priority fee you bid to improve ordering. The crucial detail is that fee pressure is local: it attaches to the specific accounts your transaction writes to, not the whole network. That is why fees stay low even when one part of the chain is congested.
5,000
Lamports base fee per signature
100%
Priority fee to validator (SIMD-0096)
~12M
CU per-account write ceiling
~150
Blocks a blockhash stays valid
On this page
What are the two parts of a Solana fee?
Every Solana transaction fee, as described in the official documentation, has two components.
Fixed
Base fee
Fixed at 5,000 lamports (0.000005 SOL) per signature. Most transactions carry a single signature, so this is what you usually pay. At a SOL price of 100 dollars that is 0.0005 dollars, half a tenth of a cent. It is split 50% burned and 50% paid to the validator, and it does not rise with demand the way Ethereum gas does.
Optional
Priority fee
Also called the prioritization fee. You add it to improve the chance that the current leader schedules your transaction ahead of competing ones. Following a 2025 protocol change (SIMD-0096), 100% of the priority fee now goes to the validator rather than being partly burned, which sharpens validators' incentive to include high-priority transactions.
Not really a fee: there is also a small refundable deposit, often called rent, of roughly 0.002 SOL to open a new account such as a token account. It is returned when the account is closed, so it is not a cost in the way the base and priority fees are.
How is the priority fee calculated?
The priority fee follows a single formula.
Here is the compute-unit price you set, in micro-lamports per compute unit, and is the compute-unit limit you request for the transaction. The single most important and counter-intuitive point: the priority fee scales with the compute-unit limit you request, not the compute you actually use. Request a huge limit "to be safe" and you pay for that headroom whether or not the transaction needs it.
The practical rule: raise the compute-unit price before the compute-unit limit. Price buys priority; limit only buys headroom, and over-requesting headroom just inflates your fee.
What is a local fee market, and why does it matter?
This is the concept almost no consumer guide explains properly, and it is the key to understanding Solana fees.
On Solana, fee pressure is local to the writable accounts a transaction touches. When many transactions compete to write to the same account at the same time, a local fee market forms around that specific account, and only transactions touching that congested account need to pay elevated priority fees. Someone sending a simple transfer, or swapping on a quiet pool during a chaotic token launch elsewhere, pays essentially nothing extra, because the fee spike is isolated to the accounts the launch is writing to.
This is structurally different from Ethereum, where a single popular mint raises gas for every transaction on the network, including unrelated transfers. On Solana the congestion is real but contained.
The trap behind most overpaying: people see a "Solana is congested" headline, crank their priority fee, and waste SOL. Because fee markets are local, you only compete with other transactions writing to the same accounts you do. If your target account is not the hot one, a modest priority fee is plenty.
A concrete example: there is a per-account ceiling of roughly 12 million compute units per block (the Max Writable Account Units limit), well under the full block limit. During very high-profile token launches, the hot token accounts pushed toward that 12 million ceiling while the broader network had plenty of room. A bot pricing off a network-wide number walked straight into a fully contended account with a bid set for an empty one.
How does Solana order transactions without a mempool?
Unlike Ethereum, Solana has no global mempool, no shared waiting room where every transaction bids against every other. Instead, a mechanism called Gulf Stream forwards transactions directly to upcoming block leaders, using a leader schedule that is published a full epoch in advance. The current leader orders pending transactions by priority fee within their local fee markets and includes as many as fit the block's compute budget.
This design is efficient, but it has a consequence: a returned transaction signature only means your node accepted the bytes, not that a leader did. If your transaction is priced correctly but submitted through a lagging node, it can still be dropped.
Why do Solana transactions fail or get dropped?
There are four common causes. Diagnosing which one is hitting you is the whole game.
| Cause | Type | Fix |
|---|---|---|
| Priority fee too low for its local market | Construction | Price from recent fees on the accounts you touch, not a network-wide number |
| Compute budget set incorrectly | Construction | Set a realistic compute-unit limit using simulation, not a blanket maximum |
| Slot congested, packet never reached the leader | Infrastructure | Use a faster or stake-weighted submission path |
| Blockhash expired before inclusion | Infrastructure | Submit promptly; a blockhash is valid for roughly 150 blocks (about 60 to 90 seconds) |
The first two are construction problems: the transaction was built wrong. The last two are infrastructure problems: the transaction was fine but could not reach the leader in time or referenced state that aged out. It is worth stressing that dropped transactions are usually not the network failing. During congested periods in 2025, network-wide failure rates ran high, yet Solana also maintained continuous uptime for well over a year, which means most drops trace to how transactions were built or submitted, not to outages.
How should you estimate the right priority fee?
The native method, getRecentPrioritizationFees, checks a cache of recent blocks and returns fees paid by transactions locking the accounts in your list. This is account-aware, which is exactly what you want. By contrast, the default fee call in the standard web3 client returns a single network-wide value, which is the misleading global number that causes overpaying.
A reasonable approach:
Query the right accounts
Query recent priority fees for the specific accounts your transaction writes to, not a network-wide figure.
Price to a percentile
Set your compute-unit price to a percentile of that distribution: a middle percentile in normal conditions, a higher percentile when competing for a contested account.
Size the compute limit honestly
Set a realistic compute-unit limit using simulation rather than a blanket maximum, so you do not pay for headroom you never use.
Recalculate dynamically
Recalculate as conditions change, because fees that worked an hour ago may not work now.
Several infrastructure providers expose congestion-indexed priority-fee estimates if you prefer not to build the logic yourself.
Priority fees versus Jito tips
These are frequently confused, and using the wrong one quietly burns money.
Priority fee
A native scheduler signal: it improves your ordering inside the leader's normal transaction queue. This is the right tool for ordinary ordering.
Jito tip
A separate payment for bundle inclusion through an auction path, used when you specifically need atomic execution of a bundle. Reach for it only when atomicity is the point.
They are not interchangeable. For ordinary ordering, the native priority fee is the correct tool; a Jito tip is for cases where a bundle must execute atomically or not at all.
How do the 2026 upgrades affect fees?
Fees do not exist in isolation from Solana's other changes. The Alpenglow upgrade removes on-chain vote transactions that currently consume most of every block, which frees space and eases congestion that would otherwise push up priority fees. Larger block limits do the same by adding capacity for parallelizable transactions. And Firedancer has been observed to fill blocks more evenly, smoothing the spikes that force users into priority-fee competition in the first place.
Key takeaways
- • A Solana fee is a base fee (5,000 lamports per signature) plus an optional priority fee.
- • Priority fee scales with the compute-unit limit you request, not the compute you use.
- • Fee pressure is local to the accounts you write to, not the whole network.
- • Most "dropped" transactions are build or submission errors, not network failures.
- • Price from recent fees on your specific accounts, and use Jito tips only for atomic bundles.
Frequently asked questions
How much does a Solana transaction cost?
Every transaction pays a base fee of 5,000 lamports (0.000005 SOL) per signature, a fraction of a cent at typical SOL prices. An optional priority fee is added during congestion. Even in busy periods, total fees usually stay well under one cent.
What is a local fee market on Solana?
Fee pressure attaches to the specific writable accounts a transaction touches, not the whole network. If a token launch congests one pool, transactions touching unrelated accounts still pay almost nothing. This differs from Ethereum's global gas market.
Why do Solana transactions fail or get dropped?
Four common causes: the priority fee was too low for the transaction's local fee market, the compute budget was set wrong, the slot was congested so the packet never reached the leader, or the blockhash expired before inclusion.
How is the Solana priority fee calculated?
Priority fee in lamports equals the ceiling of compute-unit price (in micro-lamports) times the requested compute-unit limit, divided by 1,000,000. It scales with the limit you request, not the compute you use, and 100% goes to the validator.
What is the difference between a priority fee and a Jito tip?
A priority fee improves your ordering in the leader's normal queue. A Jito tip pays for bundle inclusion through an auction path, used when you need atomic execution. They are not interchangeable.
Stop guessing at the chain. Start watching it.
Fees, whales, and holder shifts move together during a launch. SolanaHolderBot tracks holder growth, whale moves, and distribution changes in real time, so you see what is happening before it shows up in the price. Set it up in minutes.
Try SolanaHolderBot
More from the Solana 2026 series
Solana
Overview: Solana in 2026
Every major network upgrade, summarized and cross-linked.
Solana
Alpenglow: sub-150 ms finality
Removing on-chain votes frees block space and eases fee pressure.
Solana
Firedancer: independent validator client
Fills blocks more evenly, smoothing the spikes behind fee competition.
Solana
Throughput, TPS and block limits
How larger blocks add capacity for parallelizable transactions.
Sources and further reading
- Solana Documentation: Fees (primary reference for the fee formula and distribution)
- Helius: Solana Local Fee Markets
- Helius: Solana Fees in Theory and Practice
- Solana: Understanding Solana Transaction Fees
Last updated 27 June 2026. Fee parameters and protocol behavior can change with new SIMDs; verify against the official Solana documentation before relying on specifics. SOL-denominated fees mean the dollar cost moves with the SOL price.