Why do Solana transactions get dropped? (Inclusion, priority fees & Jito tips explained)

Solana transactions get dropped for four reasons: the priority fee was too low to win its local fee market, the compute budget was set wrong, the slot was congested and the transaction never reached the leader, or the blockhash expired before inclusion. Most "dropped bot" problems trace to the last one—and stale blockhashes are usually an RPC infrastructure problem, not a fee problem.

This matters because dropped transactions are not edge cases. During congested periods in 2025, Solana network-wide failure rates ranged from 20% to 45.5%, averaging roughly 39%. Yet Solana has maintained 100% uptime for 17+ consecutive months as of September 2025—which means these drops are almost never the network failing. They are transactions built or submitted wrong.

This guide is built around what we call The 4-Drop Diagnosis—the four root causes of a dropped Solana transaction, how to tell which one is hitting you, and how to fix each. 

How does Solana transaction inclusion actually work?

Solana has no mempool. Transactions route directly to upcoming block leaders via Gulf Stream, using a leader schedule published a full epoch in advance. The current leader's validator orders pending transactions by priority fee within local fee markets—competition is per-account, not network-wide—and includes as many as fit the block's compute budget.

Unlike Ethereum's global mempool auction, Solana forwards transactions directly to the leader through Gulf Stream. There is no shared waiting room where every transaction bids against every other. Instead, the leader processes transactions and prioritizes them by the priority fee attached—but with a crucial twist most guides get wrong: fee markets are local.

A local fee market means competition for blockspace is scoped to the specific accounts a transaction writes to. If you're swapping on a quiet pool during a viral memecoin launch on a different pool, you pay almost nothing extra—the fee spike is isolated to the accounts the memecoin's pool is writing to. This is structurally different from Ethereum, where a popular NFT mint raises gas for every transaction on the network. This single fact changes how you should think about priority fees.

Priority fees and the local fee market trap

A priority fee is an optional payment per compute unit that raises a transaction's inclusion priority. The base fee is fixed at 5,000 lamports per signature; the priority fee is what you tune. The common mistake: paying a blanket high fee during "congestion" when the congestion is local—you only need to outbid transactions touching your accounts.

Here is the counter-intuitive part. When people see "Solana is congested" headlines and crank their priority fee to the moon, they are usually wasting money. Because fee markets are local, you are not competing with the whole network—you are competing only with other transactions writing to the same accounts you are. If you are not trading the account that is hot, a priority fee in the 0.00002–0.00005 SOL range is typically enough to land.

The right way to calculate a priority fee:

1. Query recent priority fees for the specific accounts your transaction touches, via getRecentPrioritizationFees.
2. Set your fee to a percentile of that distribution—p50 for normal conditions, p75–p90 when you are competing for a contested account.
3. Set a realistic compute unit limit via simulation, not a blanket maximum.
4. Recalculate dynamically. Fees that worked an hour ago may not work now, and Helius's Priority Fee API exposes six congestion-indexed levels if you don't want to build the estimation yourself.

Since SIMD-0096 activated in mid-2025, 100% of the priority fee goes to the validator with none burned. That sharpens the validator's incentive to prioritize fee-paying transactions—which makes accurate fee-setting more important, not less.

When do Jito bundles help—and when are they a waste?

Jito bundles help when you need atomic execution or guaranteed ordering—arbitrage, liquidations, MEV, anything where a partial fill is a loss. They are a waste for simple, non-time-critical single transactions. Not every bot needs Jito. A DCA bot or a portfolio rebalancer gains nothing from a bundle and pays a tip for it.

A Jito bundle is a group of up to 5 transactions executed atomically and in order within one slot—all succeed or none do. That property is essential for some strategies and irrelevant for others.

When bundles genuinely help:

• Cross-DEX arbitrage—both legs must land together or neither
• Liquidations—oracle update plus liquidation call, atomic
• JIT liquidity—LP add and remove around a user's swap
• Front-run protection via jitodontfront
• Any multi-tx flow where ordering or atomicity matters

When bundles are a waste:

• Simple swaps with no atomicity requirement
• DCA, scheduled buys, rebalancing—latency-relaxed strategies
• Anything where a failed leg can just be retried next slot harmlessly

The tip is the cost. Competitive searchers surrender 50–70% of expected profit to Jito tips. For a strategy that doesn't need atomicity, that tip is pure overhead. The decision rule is simple: if a partial or out-of-order execution would cost you money, bundle. If it wouldn't, a well-tuned priority fee plus good RPC lands the transaction for a fraction of the cost.

The four reasons a transaction gets dropped

A Solana transaction gets dropped for exactly four reasons: (1) priority fee too low to win its local fee market, (2) compute budget set wrong, (3) slot congestion drops the packet before it reaches the leader, or (4) the blockhash expired before inclusion. Diagnosing which one is hitting you is the whole game.

The first two are construction problems—your transaction was built wrong. The last two are infrastructure problems—your transaction was built fine but couldn't reach the leader in time or referenced state that aged out. Note that transactions can also be silently dropped to a UDP packet loss or by landing on a minority fork, both of which present as the "no error" congestion case.

A blockhash on Solana is valid for roughly 150 blocks, which at ~400 ms slots works out to about 60–90 seconds of real time. That sounds generous. It isn't, when your RPC is lagging—every slot your RPC sits behind the chain tip is a slot of that budget already spent before your transaction even leaves your machine.

How do you diagnose a failing transaction before you send It?

Run simulateTransaction (or simulateBundle for Jito) against current chain state before you submit. Simulation catches compute-unit overruns, account-state mismatches, and logic errors for free—a failed simulation costs nothing, while a failed on-chain transaction still pays the base fee, the priority fee, and any tip.

Simulation is the single highest-leverage diagnostic step most bots skip. It returns the exact compute units the transaction will consume (use this to size your CU limit precisely, not blanket-max), any program error the transaction would throw, the account states it would read and write, and the logs that reveal why a swap or liquidation would revert.

Reading simulation errors is a skill. The common ones:

• "insufficient funds"—bankroll or rent issue
• "custom program error: 0x1771"—usually slippage exceeded (Raydium / Jupiter)
• "exceeded CUs meter"—compute budget set too low
• "AccountNotFound"—stale state, frequently an RPC freshness problem

The discipline: simulate, read the error, fix the specific cause, then send. Blind retry without diagnosis is how bots burn compute units and money—which is exactly the failure mode the last section addresses.

Slow RPC, stale blockhash, dropped transaction

A slow RPC hands you a blockhash that's already several slots old. By the time you build, sign, and submit, that blockhash is closer to expiry—or already on a minority fork the network abandoned. Slow RPC equals stale blockhash equals dropped transaction. This is the single most common, least-diagnosed cause of bot drops.

Here is the chain of causation most teams never trace. Your bot calls getLatestBlockhash. If your RPC node is lagging 3–5 slots behind the chain tip—common on shared and public endpoints during congestion—the blockhash you receive is already 1.2–2 seconds into its ~60–90 second lifespan, and worse, it may reference a slot that doesn't end up canonical.

There is a subtler failure too. If your RPC serves from a node that lagged and ended up on a minority fork, the blockhash you reference only exists on that abandoned fork. When the network converges on the canonical chain, your transaction references a blockhash that effectively never happened—and it is dropped silently, with no clear error to read.

In RPC Fast internal testing, transactions built against blockhashes from nodes lagging 3+ slots behind the chain tip showed a materially higher drop rate than those built against co-located, sub-1-slot-lag nodes—with the entire difference concentrated in congestion windows, exactly when a dropped transaction costs the most.

This is why "just raise your priority fee" is bad advice for a dropping bot. If the drop is a stale-blockhash problem, no priority fee fixes it. The fix is a low-lag RPC reading at the chain tip.

Retry logic that lands vs. retry logic that burns money

Retry logic that works re-fetches a fresh blockhash, escalates the priority fee on a percentile curve, and re-simulates between attempts. Retry logic that wastes compute units blindly resends the same transaction with the same stale blockhash and the same losing fee—which is how apps accidentally DDoS themselves and still don't land.

The wrong pattern—the one that burns money on every attempt:

while not confirmed:
    send(same_tx)        # same blockhash, same fee
    sleep(1)

Every resend uses the same expiring blockhash and the same losing fee. You pay base fees on every failed attempt, you add load to the network at the worst possible moment, and you still don't land—this is how apps accidentally DDoS themselves.

The right pattern—escalate the fee and refresh the blockhash every attempt:

for attempt in 1..3:
    blockhash = fresh_blockhash()       # refresh every attempt
    fee       = percentile_fee(attempt) # p50 -> p75 -> p90
    tx        = build_tx(cu_limit, fee, blockhash)
    if simulate(tx).ok:
        result = send(tx)
        if confirmed: return ok
    if error == contention: escalate
    if error == bad_route:  reroute
return fail_gracefully()

The differences that matter:

1. Fresh blockhash every attempt—kills the stale-blockhash drop, the most common bot failure.
2. Escalating fee on a percentile curve—only pays more when the first attempt actually fails, instead of overpaying every time.
3. Re-simulation between attempts—catches state changes that happened since the last try.
4. Bounded retries with graceful failure—stops instead of resending forever and contributing to congestion.

The 4-drop diagnosis (Checklist)

Before blaming the network for a dropped transaction, check in this order—most to least common for bots:

• Stale blockhash? Get a fresh blockhash from a sub-1-slot-lag RPC. This is the most common drop cause and the most overlooked.
• Compute limit wrong? Simulate to size the CU limit precisely instead of guessing or blanket-maxing.
• Slot congestion drop? Use SWQoS-staked submission plus a TPU-direct path so the packet reaches the leader.
• Fee too low? Calibrate dynamically against the accounts you actually touch—not a blanket high fee for "network congestion."

Notice the order. Fee is last, not first. For most dropping bots, the fee was never the problem.

Please, diagnose before you pay

Solana transaction inclusion looks like a fee problem and is usually an infrastructure problem. The network has not gone down in over a year and a half. When a transaction drops, the cause is one of four specific things—and three of those four have nothing to do with how much you paid. The reflex to crank the priority fee and resend is exactly backwards: it costs money, adds congestion, and leaves the actual cause untouched.

Run The 4-Drop Diagnosis instead. Check the blockhash freshness first, the compute limit second, the submission path third, and the fee last. Simulate before you send. Build retry logic that refreshes and escalates instead of blindly resending. Most of the time, the fix is a faster, fresher RPC—not a bigger fee.