If you've sent any Solana transaction since 2024, you've used priority fees — even if you didn't know it. They're how Solana prices congestion. Understanding how they work, when to pay more, and when paying more is wasted is one of the higher-leverage things to know if you're sending real volume.
First, a definition that matters: the priority fee is the on-chain gas fee at the Solana protocol level, used to compete for inclusion order during congestion — the higher you set it, the more likely you reach the front of the inclusion queue. This is not the same thing as the BoltTx tip: the BoltTx tip is what you pay BoltTx in exchange for submission-side priority. Tune both together for the fastest landing. This article is specifically about priority fees.
This piece walks through what priority fees actually are, how they're priced, common patterns for setting them, and why "max priority fee on every transaction" is a bad strategy that costs you real money.
What Priority Fees Actually Are
Solana transactions have two cost components:
Base fee. A flat 5000 lamports per signature. Negligible in dollar terms.
Priority fee. Optional, per-CU (compute unit) charge that signals to validators "include my transaction first." Priced in microlamports per CU.
The total priority fee for a transaction is compute_unit_price * compute_unit_limit. A transaction with a 100_000 microlamports/CU price and a 200_000 CU limit costs 200_000 * 100_000 / 1_000_000 / 1_000_000_000 = 0.00002 SOL in priority fees.
Validators sort their inclusion queue by priority fee. Higher priority fee = more likely to land in the next slot.
What Compute Units Are
A compute unit (CU) is Solana's unit of computational work. Each instruction consumes some CUs; transactions have a maximum CU budget; if a transaction exceeds its budget, it fails.
Two important values:
- Compute unit limit. The maximum CU your transaction can consume. Default is
200_000. Set explicitly withComputeBudgetProgram.setComputeUnitLimit. - Compute unit price. The priority fee per CU. Default is 0 (no priority fee). Set with
ComputeBudgetProgram.setComputeUnitPrice.
Setting these correctly is one of the most common ways to improve transaction reliability:
import { ComputeBudgetProgram, Transaction } from "@solana/web3.js";
const tx = new Transaction()
.add(ComputeBudgetProgram.setComputeUnitLimit({ units: 250_000 }))
.add(ComputeBudgetProgram.setComputeUnitPrice({ microLamports: 100_000 }))
.add(yourActualInstruction);
Why "Always Max Priority Fee" Is a Bad Strategy
The naive instinct is "pay the highest possible priority fee — I want my transaction to land."
This is bad strategy for a few reasons:
Most of the spend is wasted. Once you've outbid the second-place transaction, additional priority fee doesn't make you land any faster. The extra spend is wasted with no benefit to you.
Compounds across volume. A bot doing 1000 transactions/day with the max priority fee is paying 5-10x what it needs to. That's real money over a year.
Unprofitable on marginal trades. If a trade's expected value is small, paying the maximum priority fee can make the trade unprofitable on its own. You're now bleeding money on every marginal attempt.
Doesn't help when the network is calm. During off-peak hours, even a low priority fee lands transactions quickly. Maxing it out wastes money.
The right strategy is profit-aware priority fee setting: vary the priority fee based on the expected value of the transaction landing.
Setting Priority Fees Correctly
The formula that approximates a sensible priority fee:
priority_fee = max(floor, expected_profit * fee_fraction)
Where:
- floor is the minimum priority fee you need to be in the running. Varies by network conditions; observable from recent slots.
- expected_profit is the gross profit you expect from the transaction landing.
- fee_fraction is what fraction of expected profit you're willing to pay. 5-15% is a reasonable range.
For very high expected profit transactions (large arbitrage spreads, hot mints), you can pay aggressively up to a meaningful fraction of expected profit. For marginal transactions, just clear the floor and accept that some attempts won't land.
The data you need:
- Recent priority fee data per slot. What's the floor right now? What did the median landed transaction pay? Most RPCs expose this; if yours doesn't, you're flying blind.
- Your bot's expected profit estimates. This is strategy-side, not RPC-side. Your trading logic should tag each transaction with an expected gross.
- Per-signature telemetry to validate. Did the trade actually land? At what price? Did the priority fee predict landing?
Patterns for Different Strategies
How priority fee strategy varies by what you're doing:
Arbitrage bots. Wide-spread opportunities justify high priority fees; marginal opportunities should clear floor only. Accept that some marginal attempts won't land.
Sniper bots. During hot launches, set priority fees aggressively. The opportunity is time-limited and the expected value is high. Don't try to be cheap during the trigger window.
Market makers. Pay enough priority fee to land cancels and replaces predictably. Overpaying bleeds the spread; underpaying means you're stuck with stale quotes.
Volume bots. Low priority fee strategy. The whole point of a volume bot is many transactions; maxing the priority fee destroys economics.
DCA / scheduled buys. No urgency. Use a low priority fee and accept some retries.
Manual user transactions. Use whatever the wallet's default is; usually fine for one-off swaps.
Common Mistakes
Things that systematically cost money:
Static priority fee values. "I always pay 100k microlamports/CU" is leaving money on the table. Network conditions vary; your priority fee should too.
Ignoring the CU limit. Setting CU price right but CU limit wrong means you're paying priority fees on a budget that won't even fit your transaction.
Padding CU limit "just in case." A 500k CU budget on a transaction that uses 150k means you're paying priority fees on the wasted 350k. Profile your actual usage and budget at 1.2-1.5x measured.
Maxing the priority fee during a memecoin bot's idle phase. When nothing's happening, paying max on every probe is just burning money.
Not paying any priority fee when the network is busy. Some bot operators forget to set priority fees, transactions don't land, blockhashes expire, transactions silently fail.
How to Measure What You're Spending
A diagnostic worth running on your own bot:
- Sum total priority fees paid over the last week.
- Sum total gross profit from landed transactions.
- Compute the ratio.
- If priority fees are >15-20% of gross profit, you're overpaying.
- If priority fees are <2% of gross profit, you're probably underpaying (or not landing the transactions you want).
The right ratio varies by strategy. Arbitrage bots often pay 5-10% of gross to priority fees. Sniper bots can pay 15-25% during hot windows. Volume bots should pay <2%.
What to Do This Week
If you're not happy with your bot's economics:
- Audit your priority fee strategy. Are you using static values? Switch to profit-aware adjustment.
- Profile your actual CU usage. Use simulation to measure real consumption; set budgets at 1.2-1.5x.
- Get priority fee telemetry from your RPC. Recent floor values. Most production RPCs expose this.
- Tag transactions with expected profit. Your trading logic should already know this; surface it to the execution layer.
- Compute your priority-fees-as-percent-of-gross. This single metric tells you if you're over- or underpaying.
- Don't try to be perfect. A 70% solution to dynamic priority fee adjustment beats the 100% solution that's still in the design phase.
What BoltTx Provides
BoltTx is built for transaction-sending workloads where priority fee optimisation matters:
- Sub-second confirmation with consistent behaviour, so a well-set priority fee actually lands the transaction
- Dedicated SWQoS + prioritised connections — your transactions get priority landing capability under congestion
- Per-signature delivery telemetry — measure exactly which priority fee values led to landing in which slots
- Native Anti-MEV — your priority fee doesn't end up subsidising sandwich bots also bidding on your transaction's path
The priority fee discussed above is always the on-chain gas fee at the Solana protocol level. The BoltTx tip is a separate thing — the more you tip, the higher the priority your transaction gets on BoltTx's submission side, and the faster it lands, and you only pay when the transaction actually lands. We recommend setting the priority fee meaningfully above the current network average, then combining it with a BoltTx tip — tuning both together gives you the fastest landing.
import { Connection } from "@solana/web3.js";
const connection = new Connection(
"https://bolttx.io/?api-key=YOUR_API_KEY",
"processed"
);
Free tier signup. Run real volume against it for a week with explicit priority fee strategies and compare your landing rate at each priority fee level against your current setup.
FAQ
What's a typical priority fee for a Solana DEX swap? Varies by network conditions. During congestion, 100k-500k microlamports/CU is common. During calm, much lower. Always check recent floor.
What happens if I don't set a priority fee? Default is 0. Your transaction will land if there's no congestion, may not land if there is. For production sending, always set explicitly.
Should I set the same priority fee on simulation and real submission? You can simulate without one (it's just simulation). When submitting for real, set the priority fee based on expected value.
What's the difference between Jito tips and priority fees? Priority fees are the on-chain gas fee at the Solana protocol level. Jito tips are MEV protection / bundle inclusion fees that go through Jito's auction. Different mechanisms; sometimes both are used.
Can I get priority fee data from any RPC?
Most expose it via getRecentPrioritizationFees. Quality varies. Production RPCs should expose recent floor values reliably.