Master Solana priority fees to avoid dropped transactions. Learn how fees work, how to set optimal amounts, and which tools automate fee management for you.
Nothing is more frustrating than submitting a Solana transaction and watching it silently disappear. No error, no confirmation — just nothing. Your swap never happened, your snipe never landed, your limit order never filled. In a market where seconds matter, dropped transactions are not just inconvenient — they cost real money.
The solution is understanding and properly configuring Solana's priority fee system. This guide explains how priority fees work, how to set them correctly for different situations, and how to use tools that handle fee optimization automatically.
To understand priority fees, you need to understand how Solana processes transactions.
Every Solana transaction goes through these stages:
Transactions can fail at multiple points:
Priority fees primarily help with step 3 — they influence where your transaction sits in the leader's processing queue.
Solana transactions have three fee components:
Every transaction pays a base fee of 5,000 lamports (0.000005 SOL) per signature. Most transactions have one signature, so the base fee is 0.000005 SOL. This is fixed and non-negotiable.
The priority fee is an additional fee you pay per compute unit (CU) consumed. It is calculated as:
Priority fee = Compute units consumed × Price per compute unit (in micro-lamports)
For example, if your transaction uses 200,000 CU and you set a price of 100 micro-lamports per CU:
200,000 × 100 = 20,000,000 micro-lamports = 20,000 lamports = 0.00002 SOL
The priority fee determines your position in the validator's processing queue. Higher fees get processed first.
Building a product on Solana data?
Skip the Geyser pipeline — embed KOL flow, deployer reputation, and the all-DEX firehose over REST, WebSocket, or webhooks. The Business tier (€400/mo) is the self-serve embed license at 500k calls/day — Enterprise adds white-label & redistribution.
Tools mentioned
Live health scores, average ratings, and direct links on MadeOnSol.
Transaction debugging for Solana with full source-code-level tracing
No-code Solana token creation and management toolkit
Restaking infrastructure for Solana middleware security
Human-readable transaction classification API for Solana and EVM chains
Guaranteed Solana transaction inclusion via ahead-of-time blockspace auctions
Build with MadeOnSol API
KOL tracking, deployer intelligence, DEX streaming, and webhooks. Free API key — 200 requests/day.
New customers try Pro free for 5 days — card, cancel anytime.
import { MadeOnSol } from "madeonsol";
// Get a free API key at madeonsol.com/pricing
const client = new MadeOnSol({ apiKey: "msk_your_key" });
const { trades } = await client.kol.feed({ limit: 10 });
const { alerts } = await client.deployer.alerts({ limit: 5 });
const { tools } = await client.tools.search({ q: "trading" });Building a product on Solana data?
MadeOnSol isn't an RPC or another generic token API — it's Solana memecoin intelligence that's painful to build in-house, pulled from dual-region gRPC shred streams: sub-second from the on-chain event to your app.
Signals you'd otherwise build
KOL & smart-money flow from 1,000+ labeled wallets, deployer reputation, coordination clusters, linked-wallet entity resolution, and an all-DEX firehose.
Embed it in your product
The Business tier (€400/mo, self-serve) licenses you to display MadeOnSol data inside your own product — 500k calls/day, 10 WS + 5 firehose connections. Enterprise above adds white-label & redistribution rights and custom endpoints.
Evaluate first, commit later
Test everything on a free ULTRA key — no commitment. If it fits, we scope volume or white-label pricing.
Keep reading
Guides
Everything you need to know about Solana transaction fees in 2026. Understand base fees, priority fees, Jito tips, compute units, and practical strategies to reduce costs without sacrificing speed.
Trading
Solana has no traditional mempool, but pending transactions are still observable. Learn how Solana mempool monitoring works with Jito bundles, gRPC streams, leader TPU forwarding, and ShredStream — plus practical tools and use cases for MEV detection, frontrun protection, and latency optimization.
Guides
A detailed comparison of trading fees across every major Solana DEX. Understand platform fees, pool fees, priority fees, Jito tips, and trading bot markups so you know exactly what each trade costs.
Education
Understand Solana's three commitment levels -- processed, confirmed, and finalized. Learn when to use each one and how they affect your dApps, trading bots, and transaction reliability.
Analytics
Learn to decode Solana transactions step by step. Understand signatures, instructions, token transfers, and how to use block explorers.
Trading
Understand how Solana transaction bundling works, why token launches use bundle buys on Pump.fun, and how to detect bundled tokens as a trader.
Enjoyed this article?
Real-time KOL trades, Pump.fun deployer intel, and 1,200+ ranked Solana tools — free to explore.
Open the KOL TrackerJito tips are a separate mechanism. Instead of paying the priority fee to the Solana runtime, you send a direct SOL transfer to a Jito validator's tip account. Jito tips are processed outside the normal fee system and offer additional guarantees:
Many trading bots use Jito tips in combination with priority fees for maximum reliability.
The right priority fee depends on what you are doing and how congested the network is.
| Congestion | Typical Priority Fee | Jito Tip | Total Cost |
|---|---|---|---|
| Low (normal) | 1,000-10,000 micro-lamports/CU | 0.0001 SOL | ~0.0003 SOL |
| Medium (busy) | 50,000-200,000 micro-lamports/CU | 0.001 SOL | ~0.005 SOL |
| High (congested) | 500,000-2,000,000 micro-lamports/CU | 0.01 SOL | ~0.05 SOL |
| Extreme (new launch) | 5,000,000+ micro-lamports/CU | 0.1+ SOL | ~0.5+ SOL |
Token swaps (normal conditions): 50,000-100,000 micro-lamports/CU + 0.001 SOL Jito tip. This gets your swap processed within 1-2 blocks during normal conditions.
Sniping a new token: 1,000,000+ micro-lamports/CU + 0.01-0.05 SOL Jito tip. You are competing with hundreds of other snipers, all trying to buy in the same block. The cost is higher, but so is the potential reward.
DeFi interactions (lending, staking): 10,000-50,000 micro-lamports/CU. These are rarely time-sensitive. A moderate fee ensures processing without overpaying.
Token transfers: 5,000-10,000 micro-lamports/CU. Simple transfers are low priority and low urgency. Minimal fees are sufficient.
NFT mints: 500,000-2,000,000 micro-lamports/CU + Jito tip. Popular mints have the same congestion dynamics as token launches.
Phantom has built-in priority fee management:
Phantom's auto-detection generally works well for regular transactions but tends to underpay during high congestion. For time-critical trades, manually set a higher fee.
Solflare provides similar controls:
Jupiter includes fee settings in its swap interface:
Jupiter's dynamic priority fee is one of the better auto-implementations — it samples recent transactions to estimate the optimal fee for the current block.
Most Solana trading bots have priority fee settings in their configuration:
BullX: Settings → Transaction Settings. Options for priority fee amount and Jito tip. BullX defaults to reasonable values that work for most trading scenarios.
Axiom: Settings panel includes priority fee and Jito tip configuration. Axiom also supports dynamic fees that adjust based on network conditions.
Photon: Settings → Gas Settings. Photon lets you set separate fee levels for buys and sells, which is useful — you might want higher fees for buys (speed matters) and lower fees for sells (less competitive).
Trojan: Use the /settings command in Telegram. Set priority fee in SOL. Trojan applies both priority fees and Jito tips.
BonkBot: Settings menu in Telegram includes priority fee adjustment.
The most effective approach is not setting a fixed fee but dynamically adjusting based on conditions.
Query the network for recent priority fees paid by successful transactions:
const recentFees = await connection.getRecentPrioritizationFees();
const sorted = recentFees
.map(f => f.prioritizationFee)
.sort((a, b) => a - b);
const p75 = sorted[Math.floor(sorted.length * 0.75)];
// Use the 75th percentile as your fee
This gives you a fee that is competitive with 75% of recent transactions. For time-critical operations, use the 90th or 95th percentile.
Different programs have different fee dynamics. A swap on Jupiter during a popular launch has different fee requirements than a simple SPL token transfer. Query fees for the specific program accounts your transaction interacts with:
const fees = await connection.getRecentPrioritizationFees({
lockedWritableAccounts: [poolAccountPubkey]
});
This returns fees specifically for transactions that touched the same accounts your transaction will touch, giving a more accurate estimate.
If your transaction is not confirmed within a few seconds:
This avoids overpaying when the network is calm while ensuring eventual execution during congestion.
Helius provides a priority fee estimation API that returns recommended fee levels:
const response = await fetch('https://mainnet.helius-rpc.com/?api-key=YOUR_KEY', {
method: 'POST',
body: JSON.stringify({
jsonrpc: '2.0',
id: 1,
method: 'getPriorityFeeEstimate',
params: [{
accountKeys: ['JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4'],
options: { recommended: true }
}]
})
});
Helius returns fee estimates segmented by priority level (low, medium, high, very high), making it easy to select the appropriate fee for your urgency level.
Mistake 1: Setting fees to zero. Some wallets and apps default to zero priority fee. During any period of non-trivial network activity, zero-fee transactions will be dropped. Always set at least a minimal priority fee.
Mistake 2: Setting compute unit limit too high. Your priority fee is per compute unit. If you request 1,400,000 CU (the maximum) but only use 200,000, you are paying for 7x more than needed. Use setComputeUnitLimit to set a realistic limit based on simulation.
Mistake 3: Using stale blockhashes. Every transaction includes a recent blockhash that expires after ~60 seconds. If your transaction sits in queue too long, it expires silently. Use getLatestBlockhash with confirmed commitment and consider the lastValidBlockHeight when implementing retries.
Mistake 4: Not using both priority fees AND Jito tips. During high congestion, using only one mechanism may not be sufficient. Priority fees help with the Solana scheduler, while Jito tips help with Jito validators specifically. Using both maximizes your chances.
Mistake 5: Same fee for all transaction types. A token snipe needs a very different fee than a simple transfer. Configure your tools with different fee profiles for different actions.
Priority fees are the single most impactful configuration setting for Solana traders. A well-configured fee strategy means your transactions land consistently, your snipes execute on time, and you stop losing opportunities to dropped transactions.
The good news is that most modern Solana tools — Jupiter, BullX, Axiom, Photon — have built-in fee management that works well for normal conditions. Where you need to take manual control is during high-congestion periods: popular launches, volatile market events, and competitive sniping situations.
Start with dynamic fee estimation, test with moderate values, and increase when speed is critical. The difference between a 0.001 SOL fee and a 0.01 SOL fee is trivial compared to the cost of a missed trade.
High priority fees increase your position in the validator's queue, but they do not prevent execution failures. If your transaction fails because of slippage (the price moved past your tolerance), insufficient balance, or a program error, the fee does not help. Check the transaction error in your wallet or on Solscan to distinguish between "not processed" (fee issue) and "processed but failed" (logic issue).
Jito tips are structured as a separate transfer instruction within your transaction. If the transaction fails during simulation (before landing on-chain), no tip is paid. If the transaction lands on-chain but a subsequent instruction fails, behavior depends on the implementation — most trading bots structure the tip as the last instruction so it only executes if the swap succeeds.
Solana priority fees are dramatically lower. A high-priority Solana transaction might cost 0.01-0.05 SOL ($1-5). An equivalent priority transaction on Ethereum during congestion can cost 0.1-1 ETH ($200-2000). Even during extreme Solana congestion, fees rarely exceed 0.5 SOL. The low absolute cost means you should generally err on the side of paying more rather than less. For the auction-based alternative to priority fees, see our Jito bundles explained; for detecting the activity that drives fee spikes in the first place, see Solana mempool monitoring.
Solana has been exploring local fee markets, where fees are determined per-account rather than globally. This means congestion on one popular program (like a token launch on Pump.fun) would not affect fees for unrelated transactions. This change would reduce the need for high priority fees during isolated congestion events, but the general principle of higher fees for higher priority will remain.