LESSON 9 OF 10·Expert10 min

Transaction Landing: Priority Fees, Jito, and Why Your Buys Fail

On Solana, the trade you missed usually failed to land, not to fill. A practical guide to compute-budget priority fees, Jito bundles and tips, blockhash freshness, and RPC choices that get your transactions confirmed.

On Solana, the trade you “missed” almost never failed to fill — it failed to land. In a hot launch, thousands of transactions compete for block space and most get dropped. Getting yours included, reliably, is a real and learnable edge. This is about your own transactions confirming — not about attacking anyone else’s.

Why transactions drop

  • Too little priority: validators order by fee-per-compute-unit under load; a fee-less tx starves.
  • Blockhash expiry: a transaction is only valid for ~150 blocks (~60s). Sign late and it’s dead on arrival.
  • Compute limit hit: exceed your requested compute units and the tx fails mid-execution.
  • Weak RPC path: a congested or unstaked RPC may never forward your tx to a leader in time.

Priority fees: the compute budget program

Two instructions set your priority. setComputeUnitLimit caps the compute you’ll use; setComputeUnitPrice sets the price (in micro-lamports) per compute unit. Priority fee ≈ limit × price. Size the price to current conditions — pull the recent prioritization-fee percentiles and bid around the 75th+ during congestion.

ADD PRIORITY FEE
import { ComputeBudgetProgram } from "@solana/web3.js";

tx.add(
  ComputeBudgetProgram.setComputeUnitLimit({ units: 120_000 }),      // measure, don't over-ask
  ComputeBudgetProgram.setComputeUnitPrice({ microLamports: 250_000 }) // scale with congestion
);
Over-asking on the compute limit wastes fee budget; under-asking gets you a compute failure. Simulate first to measure actual units used, then set the limit just above it.

Jito bundles & tips

For the hottest moments, a naked transaction — even a well-priced one — can still lose the race. Jito bundles submit an ordered group of transactions that land atomically (all or nothing) via the block engine, with a tip paid to a Jito tip account to compete for inclusion. This is how serious execution (and, yes, bundled launches) gets guaranteed same-block ordering.

  • Bundles are atomic — useful when you need several actions to land together or not at all.
  • The tip is separate from the priority fee; it’s your bid to the block engine.
  • Understanding bundles is also what lets you detect them (see Sniper & Bundle Forensics).

The reliability checklist

TacticWhy it helps
Fetch a fresh blockhash right before signingAvoids expiry drops in the ~60s validity window
Right-size compute limit via simulationPrevents compute-exhaustion failures and wasted fees
Scale priority fee to live percentilesKeeps you in the ordering under congestion
Use a staked / low-latency RPC or senderGets the tx to a leader before the window closes
Retry with the same blockhash until expiryRe-broadcast survives transient drops
Consider a Jito bundle for hot entriesAtomic, ordered inclusion when it matters most

FAQ

Higher priority fee = guaranteed landing?
It dramatically improves odds under load but never guarantees inclusion — blockhash freshness, compute sizing, and your RPC path all have to be right too. Landing is a system, not one knob.
Is using Jito 'cheating'?
No — it's standard Solana infrastructure for reliable, ordered execution. This lesson is about getting your own transactions confirmed, which every serious on-chain app does.
How do I know what fee to pay?
Query recent prioritization fees for the accounts you're touching and bid around the upper percentiles when it's hot. Static fees either overpay in calm or underpay in chaos.