How Solana Priority Fees Actually Work in 2026

Solana priority fees, compute units, and Jito tips explained with real numbers. Stop paying for failed transactions and overpaying for urgency.

Your swap just failed. You paid the base fee anyway. Now you're sitting here wondering whether you set the priority fee too low, too high, or incorrectly. This post explains exactly what happened and what to do differently.

Two fees on every Solana transaction

Every transaction you send on Solana carries two separate fee components.

The first is the base fee: 5,000 lamports per signature [solana-fees]. One signer pays 5,000 lamports. Two signers pay 10,000 lamports. The network splits that fee 50% burned and 50% awarded to the validator processing your block [solana-fees]. It is mandatory, constant, and not negotiable.

The second is the priority fee: optional, variable, and the only mechanism that determines whether your transaction lands in the next block or sits in the queue while others jump ahead.

What compute units actually are

To understand priority fees, you need to understand compute units (CUs).

Every instruction your transaction executes consumes CUs. A simple SOL transfer burns almost none. A token swap touching multiple programs and accounts can consume hundreds of thousands. Solana enforces a hard cap of 1,400,000 CUs per transaction [solana-fees]. The entire block has a combined cap of 48,000,000 CUs [helius-fees]. When the block fills up, transactions with no priority fee get displaced by those with one.

The default compute budget assigned to each instruction is 200,000 CUs [solana-fees]. If your transaction needs more and you have not explicitly set a higher limit, execution fails at the CU cap and you still pay the base fee. That is the silent cause behind many "transaction failed" errors.

Priority fees are priced in micro-lamports per compute unit. The formula:

priority fee = ceil(compute_unit_price * compute_unit_limit / 1,000,000)

So a transaction with a 200,000 CU limit at a price of 1,000 micro-lamports/CU costs:

ceil(1000 * 200000 / 1000000) = 200 lamports

That is less than the base fee and certainly not the reason your transactions are failing under normal conditions. Priority fees become load-bearing only when block space is contested and prices climb to reflect real competition.

Setting the compute budget

There are two optional instructions you add to a transaction to control its compute budget.

SetComputeUnitLimit caps how many CUs your transaction can use. Too low and execution fails at the cap. Calibrated accurately (via simulation) and you reduce your priority fee because the price multiplies against a smaller budget.

SetComputeUnitPrice sets your bid in micro-lamports per CU.

One ordering constraint matters: add SetComputeUnitLimit before your other instructions [helius-fees]. If you place it after and the transaction hits the 200,000 CU default before reaching the SetComputeUnitLimit instruction, the transaction fails before it can change the budget.

Most bots handle this by simulating the transaction first to measure actual CU consumption, then adding a small buffer before submitting. If you are building your own tooling, simulate before you send.

What the 2024 congestion actually looked like

In early 2024, Solana faced prolonged congestion driven by a surge in token launches, NFT mints, and bot activity. Block space was competitive. Transactions without priority fees were being deprioritized or dropped before reaching the leader.

The situation compounded quickly. Most wallets at the time were setting no priority fee at all, or using a static low value regardless of conditions. Once traders discovered that even a modest fee beat the zero-fee crowd, everyone raised their bids to stay competitive. The effective floor kept climbing as participants outbid each other in successive blocks.

Network upgrades and improved fee tooling stabilized things, but fee spikes still occur around major token launches. The lesson from that period: during contested windows, the fee market can move faster than static settings can track. Dynamic fee estimation based on recent block data is the standard approach now, not a fixed lamport value.

How Jito tips fit in

Jito tips and priority fees are separate mechanisms that serve different purposes.

Priority fees go to the validator through the standard Solana fee market. Jito tips are paid to Jito's block engine, which distributes them to participating validators and their stakers [jito-docs]. Because the majority of stake-weighted validators run Jito's software, a tip buys priority within their ordering logic on top of whatever the base fee market does.

The key distinction: bundles use only the tip. If your transaction is sent as part of a Jito bundle, priority fees have no effect on ordering [jito-docs]. For a single transaction routed through Jito's endpoint, Jito recommends splitting your total fee budget roughly 70/30 between priority fees and tip [jito-docs], so both the Solana-side and Jito-side ordering work in your favor.

Current Jito tip percentiles show where the market sits:

• 25th percentile: roughly 0.000006 SOL [jito-docs]
• 50th percentile: roughly 0.00001 SOL [jito-docs]
• 75th percentile: roughly 0.000036 SOL [jito-docs]
• 99th percentile: roughly 0.01 SOL [jito-docs]

The minimum tip is 1,000 lamports [jito-docs], but that floor does nothing for you in contested conditions. Targeting the 50th percentile puts you ahead of most organic traffic. During active launches you need the 75th percentile or higher to compete with bots that set their tips dynamically.

When to override T7 Pilot's auto-fee

T7 Pilot routes through Jito's broadcast endpoint with automatic fee estimation. It reads recent block data to size an appropriate bid, then submits with both a priority fee and a tip. For most trades under normal network conditions, you do not need to change anything.

Three situations justify a manual override.

A token is actively being traded. When a new mint gets called out in multiple groups at once, dozens or hundreds of bots submit within milliseconds. The auto-fee based on recent blocks may lag the current fee market. A temporary fixed higher total fee budget gets you into the competitive range without waiting for the estimator to catch up.

You are deliberately not in a rush. If you are copy-trading a wallet that bought five minutes ago, there is no value in landing in the very next block. Dropping to a lower percentile saves lamports across many trades. Over a week of frequent copy-trading, that difference is real.

The network is in full congestion. If transactions are failing repeatedly despite reasonable fee settings, the problem is usually an overloaded RPC endpoint, not the fee level. Raising fees against an overloaded endpoint costs more for the same failure rate. Switch to a dedicated RPC endpoint first before touching the fee settings at all.

The actual cost in numbers

On a typical swap consuming 150,000 CUs at a modest priority fee setting:

priority fee = ceil(10000 * 150000 / 1000000) = 1,500 lamports
base fee     = 5,000 lamports
jito tip     = ~10,000 lamports (50th percentile)
total        = ~16,500 lamports = 0.0000165 SOL

At the 75th-percentile tip, the total climbs to roughly 0.000053 SOL per transaction. Small individually, but real over hundreds of trades.

Where traders actually lose money on fees is failed transactions. A transaction that fails at execution still charges the base fee. If your compute limit is misconfigured and your swap fails three times before succeeding, you paid four base fees for one effective trade. Getting the CU limit right matters more than squeezing micro-lamports off the price.

The way to diagnose this: pull up a failed transaction in Solscan and check the compute units consumed. If it maxed out the budget, raise your CU limit. If the error is something else entirely, the fee level was not the issue, and raising it will not help.

Risk Warning: This article is for educational purposes only and does not constitute financial advice. Cryptocurrency trading involves substantial risk of loss. Always do your own research and never trade with money you cannot afford to lose.