How do I fix Solana "Blockhash not found" and dropped transactions?

Fixes for the error itself:

1. Fetch the blockhash with confirmed commitment. processed risks forks; finalized is safe but already uses up a chunk of the 150-block window.
2. Use the same commitment for preflight: preflightCommitment: "confirmed".
3. Fetch the blockhash as late as possible: right before signing, not when the user opens the form.
4. Pin fetch and send to the same RPC endpoint when you can.

Setting skipPreflight: true makes the error message go away, but it doesn't make an expired or forked blockhash valid. It only removes your early warning.

Why transactions get dropped

sendTransaction returning a signature means the RPC node accepted it, not that the network did. The RPC forwards your transaction to upcoming leaders. Under load, leaders drop packets and transactions that pay too little to get scheduled. The RPC node retries in the background, but its retry policy is generic, and if the transaction still hasn't landed when the blockhash expires, it's gone. No error is recorded on-chain because nothing ever happened on-chain.

To get transactions to land:

• Add a priority fee and set a realistic compute unit limit. The priority fee is charged on the limit you request, so simulate first and request close to what you use.
• Rebroadcast yourself until the transaction confirms or its blockhash expires, instead of relying on the RPC's default retries.
• Use an RPC provider with good transaction forwarding. Providers with staked connections (stake-weighted QoS) generally get transactions to leaders more reliably under congestion.

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

tx.add(
  ComputeBudgetProgram.setComputeUnitLimit({ units: 200_000 }), // from simulation, plus a margin
  ComputeBudgetProgram.setComputeUnitPrice({ microLamports: priorityFee }),
);

Base priorityFee on connection.getRecentPrioritizationFees() for the writable accounts your transaction touches, not on a hard-coded constant.

A send loop that handles expiry correctly

The key rule: rebroadcasting the same signed transaction is always safe, because the network deduplicates by signature. Re-signing with a new blockhash is only safe after the old one has expired. If you re-sign early, both versions can land and your transfer runs twice.

import { Connection, Keypair, Transaction } from "@solana/web3.js";

const sleep = (ms: number) => new Promise((r) => setTimeout(r, ms));

export async function sendAndConfirmWithRetry(
  connection: Connection,
  tx: Transaction,
  payer: Keypair,
): Promise<string> {
  const { blockhash, lastValidBlockHeight } =
    await connection.getLatestBlockhash("confirmed");
  tx.recentBlockhash = blockhash;
  tx.feePayer = payer.publicKey;
  tx.sign(payer);
  const raw = tx.serialize();

  const signature = await connection.sendRawTransaction(raw, {
    preflightCommitment: "confirmed",
    maxRetries: 0, // we handle retries ourselves
  });

  while (true) {
    // Read the height first, then the status, so a late landing isn't missed.
    const height = await connection.getBlockHeight("confirmed");
    const { value } = await connection.getSignatureStatuses([signature]);
    const status = value[0];

    if (status?.err) {
      throw new Error(`Transaction failed: ${JSON.stringify(status.err)}`);
    }
    if (
      status?.confirmationStatus === "confirmed" ||
      status?.confirmationStatus === "finalized"
    ) {
      return signature;
    }
    if (height > lastValidBlockHeight) {
      throw new Error("Blockhash expired; the transaction can no longer land. Safe to rebuild and re-sign.");
    }

    await connection
      .sendRawTransaction(raw, { skipPreflight: true, maxRetries: 0 })
      .catch(() => {}); // ignore transient send errors; the status check decides
    await sleep(2000);
  }
}

If you use connection.confirmTransaction, pass the full strategy object { signature, blockhash, lastValidBlockHeight } rather than the deprecated signature-only form. It throws TransactionExpiredBlockheightExceededError when the height passes, which is the same "safe to retry" signal as above.

When 150 blocks isn't long enough

Offline signing, multisig approval flows and hardware wallets that sit waiting for a human can easily exceed the window. For those, use a durable nonce: a nonce account whose stored value replaces the recent blockhash, with SystemProgram.nonceAdvance as the first instruction. The transaction then stays valid until the nonce is advanced, and advancing it invalidates any other transaction signed with the same nonce.

Checklist

1. Fetch the blockhash with confirmed, as late as possible, and keep lastValidBlockHeight.
2. Match preflightCommitment to the commitment you fetched with; avoid mixing RPC nodes between fetch and send.
3. Add a priority fee and a simulated compute unit limit.
4. Rebroadcast the same signed bytes until confirmed or until block height exceeds lastValidBlockHeight.
5. Only then rebuild with a fresh blockhash and re-sign.
6. Use durable nonces for anything that waits on a human or an offline signer.