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.
How Solana Transactions Get Processed
To understand priority fees, you need to understand how Solana processes transactions.
Every Solana transaction goes through these stages:
- Submission: Your wallet or app sends the transaction to an RPC node
- Forwarding: The RPC node forwards it to the current block leader (validator)
- Scheduling: The leader places your transaction in its processing queue
- Execution: The leader executes the transaction and includes it in a block
- Confirmation: The block is voted on and confirmed by the network
Transactions can fail at multiple points:
- Not forwarded: The RPC node is overloaded or the transaction expires before being forwarded
- Not scheduled: The leader's queue is full and your transaction is dropped
- Execution failure: The transaction is processed but the instruction fails (slippage exceeded, insufficient balance, etc.)
- Expired: The transaction's blockhash expires before it can be processed (default ~60 seconds)
Priority fees primarily help with step 3 — they influence where your transaction sits in the leader's processing queue.
Anatomy of Solana Transaction Fees
Solana transactions have three fee components:
Base Fee
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.
Priority Fee (Compute Unit Price)
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.
Jito 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:
- Jito tips are processed before non-tipped transactions
- They support transaction bundles (multiple transactions executed atomically)
- They are only paid if the transaction succeeds (unlike priority fees, which are paid regardless)
Many trading bots use Jito tips in combination with priority fees for maximum reliability.
How Much Should You Pay?
The right priority fee depends on what you are doing and how congested the network is.
Network Congestion Levels
| 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 |
By Transaction Type
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.
Setting Priority Fees in Common Tools
Phantom has built-in priority fee management:
- Open Settings → Transaction Settings
- Choose from presets: Normal, Fast, Turbo, or Custom
- "Fast" is suitable for most transactions
- Use "Turbo" or "Custom" with higher values when sniping or during congestion
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:
- Settings → Transaction Priority
- Options: Low, Medium, High, Ultra
- You can also set custom micro-lamport values
Jupiter includes fee settings in its swap interface:
- Click the gear icon in the swap widget
- Under "Transaction Priority," select Dynamic (recommended), or set a custom value
- Jupiter's dynamic fee estimation adjusts to current network conditions
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.
Trading Bots
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.
Dynamic Fee Strategies
The most effective approach is not setting a fixed fee but dynamically adjusting based on conditions.
Strategy 1: Recent Fee Sampling
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.
Strategy 2: Program-Specific Fee Estimation
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.
Strategy 3: Escalating Retry
If your transaction is not confirmed within a few seconds:
- Submit with a moderate fee
- Wait 2-3 seconds
- If not confirmed, resubmit with 2x the fee (new blockhash)
- Wait 2-3 seconds
- If still not confirmed, resubmit with 5x the original fee
This avoids overpaying when the network is calm while ensuring eventual execution during congestion.
Using Helius Fee Estimation
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.
Common Priority Fee Mistakes
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.
Final Thoughts
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.
FAQ
Why do my transactions still fail even with high priority fees?
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).
Are Jito tips refunded if my transaction fails?
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.
How do priority fees compare to Ethereum gas fees?
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.
Will Solana's fee system change in the future?
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.
