Transaction not landing

Your transaction was sent to the network but never included in a block. It was either dropped by the leader, deprioritized due to congestion, or never reached the leader at all. No funds were moved and no fees were charged.

Why transactions get dropped

Solana processes thousands of transactions per second, but during congestion the number of submitted transactions exceeds block capacity. The network uses several mechanisms that can cause transactions to be dropped:

1. Insufficient priority fee. Validators order transactions by priority fee. During congestion, transactions with low or zero fees are dropped first.
2. QUIC rate limiting. The TPU (Transaction Processing Unit) limits connections from each IP. Public RPC endpoints share a connection across many users, so individual transactions compete for limited slots.
3. Stake-weighted QoS (SWQoS). Validators allocate 80% of their transaction capacity to staked connections. Transactions from unstaked connections (most public RPC nodes) compete for the remaining 20%.
4. Blockhash expiry. If the transaction is not included before its blockhash expires (~60-90 seconds), it is permanently dropped.
5. Transaction forwarding failures. The RPC node may fail to forward the transaction to the current leader in time.

How to fix

1. Add a priority fee

import {
  getSetComputeUnitLimitInstruction,
  getSetComputeUnitPriceInstruction,
} from "@solana-program/compute-budget";

// Add both instructions to your transaction
const setLimitIx = getSetComputeUnitLimitInstruction({ units: 200_000 });
const setPriceIx = getSetComputeUnitPriceInstruction({ microLamports: 50_000n });

Check recent fees with getRecentPrioritizationFees to set a competitive price.

2. Implement retry with fresh blockhash

Do not retry the same signed transaction forever. Once the blockhash expires, rebuild:

1. Send the transaction.
2. Poll getSignatureStatuses for confirmation.
3. Monitor getBlockHeight against lastValidBlockHeight.
4. If expired without confirmation, fetch a new blockhash, rebuild, re-sign, and send again.

3. Use staked connections

RPC providers with staked connections get preferential treatment through SWQoS. This is the single most effective improvement for transaction landing rate. Providers like Supanode offer fast transaction infrastructure with staked connections.

4. Send to multiple endpoints

Sending the same transaction to multiple RPC nodes increases the chance that at least one reaches the leader in time.

5. Use Jito bundles for MEV-sensitive transactions

For transactions where ordering matters (arbitrage, liquidations), Jito bundles provide guaranteed inclusion with tip-based priority.

Landing rate benchmarks

These are approximate ranges during moderate congestion. Rates vary with network conditions.

FAQ

How do I know if my transaction was dropped? If getSignatureStatuses returns null after the blockhash has expired, the transaction was dropped. It will never be processed.

Is it safe to retry? Yes. Either the original transaction lands (identified by its unique signature), or it does not and the retry with a new blockhash creates a new transaction. The same signed transaction cannot be processed twice.

What priority fee should I set? Use getRecentPrioritizationFees to check what recent transactions paid. During normal conditions, 1,000-10,000 microLamports per compute unit is often sufficient. During heavy congestion, 50,000-1,000,000+ may be needed.

Do I need a dedicated node? Not necessarily, but staked connections dramatically improve landing rate. A shared RPC with staked connections is often sufficient.

What is SWQoS? Stake-Weighted Quality of Service. Validators reserve 80% of their transaction processing capacity for connections backed by staked validators. This is why staked RPC connections have much higher landing rates.

Updated: 2026-10-19