This is the most common and most misdiagnosed failure mode in Solana development, and almost all of the confusion comes from one conflated idea: a transaction that didn't land is not the same as a transaction that failed.

Dropped is not the same as failed

There are two completely different outcomes that both look like "it didn't work":

Reverted — the transaction reached a leader, landed in a block, executed, and hit an error. Insufficient funds, slippage exceeded, a failed constraint. This transaction exists: you can look up the signature, it consumed fees, and the error tells you what went wrong.

Dropped — it never made it into a block. Nothing to look up, no fee charged. From the chain's perspective it never happened.

The signature sendTransaction returns tells you almost nothing, because it's computed locally when you sign. A node returning it means "I received your bytes and I'll try," not "this is on-chain." Treating that as success is the root bug in a surprising number of production apps.

Everything below is about the second category.

The blockhash clock started before you called

Every Solana transaction carries a recentBlockhash, and it's valid for 150 slots — roughly a minute. This is the deduplication mechanism: it's what stops a transaction from being replayed forever.

The critical detail: the clock starts when the blockhash was produced, not when you signed. Fetch a blockhash, show a confirmation modal, wait for the user to click, then sign and submit — you may have burned 40 of those 150 slots before your bytes left the machine.

Once it expires the transaction is permanently unlandable. Not delayed, dead. So: fetch the blockhash as late as possible, immediately before signing, not at the top of your request handler.

Where transactions actually get lost

Assuming a valid, unexpired blockhash, there are a handful of places a submission disappears:

The node never forwarded it. After accepting your transaction, an RPC node rebroadcasts it toward upcoming leaders on a timer until it confirms or the blockhash expires. That queue is finite, and under load submissions get evicted from it — silently, no error surfaced to you.

You read the blockhash from a node that's ahead of the one you submitted to. This one bites multi-provider setups specifically. If provider A is at the chain tip and provider B is 30 slots behind, a blockhash fetched from A may be unknown to B. B rejects it — usually as "blockhash not found" — even though the blockhash is perfectly valid. The mirror case is worse: submit to a node that's behind and it may accept, sit on the transaction, and forward it too late.

Preflight ran against a lagging node. By default sendTransaction simulates first, against that node's current state. A node several slots behind simulates on stale account data and rejects transactions that would have succeeded — a balance that's already been topped up, a PDA that's already initialized. The transaction was fine; the simulator's worldview wasn't.

Congestion. Blocks have a compute ceiling, and under contention you compete on priority fee. This is the one everyone reaches for first. It's real — but unlike the others, you can't fix it with better plumbing.

Notice that three of those four are RPC-layer problems, not chain problems.

Retrying is your job

The most important mental shift: the RPC node's rebroadcasting is a courtesy, not a guarantee. If you want reliable landing, you own the retry loop.

The rules that matter:

• Rebroadcast the exact same signed bytes. Don't rebuild, don't re-sign. Same signature means the network deduplicates for free. Rebuilding with a fresh blockhash creates a second transaction — and a double-execution risk.

• Poll getSignatureStatuses, don't just wait. Confirmation subscriptions drop. Polling is boring and it works.

• Stop when the blockhash expires, not when a fixed timer runs out. Track the last valid block height and give up there — retrying past expiry is pure noise.

• Consider maxRetries: 0 plus your own loop rather than leaving retry policy to whichever node you happened to hit.

One provider is a single point of failure on the write path

Everything above assumes your submission reaches a healthy node. With one endpoint, every failure mode above is unmitigated: your transaction's fate depends entirely on whether that node is at the tip, has queue headroom, and simulates correctly right now.

The fix is to stop submitting to one node. Because Solana deduplicates by signature, sending identical signed bytes to several providers at once is safe — at most one copy lands, and the others are discarded by the network. It costs you a little extra request volume and buys you independence from any single node's queue, slot position, or mood.

That turns submission from "hope this node cooperates" into "first one to get it into a block wins."

Three things to get right if you do this:

1. Send with skipPreflight: true. Otherwise every target runs its own simulation — that's N× the simulation cost, and providers sitting at slightly different slots will disagree with each other. One rejects, another accepts, and you get failures that depend on which node answered first. Simulate deliberately, once, on the read path instead.

2. Don't bundle submissions into a JSON-RPC batch. A batch is an array of calls and gets forwarded as one unit to one endpoint. A sendTransaction buried inside a batch gets none of this. Submit transactions as individual requests.

3. Keep your providers close together in slot height. Fanning out doesn't help if half the fleet is 50 slots behind — that's the blockhash mismatch problem again, just parallelized. Providers need to be health-checked on slot freshness, not just on whether they're answering.

Wiring it up

You can build this yourself: a submission fan-out, a status poller keyed to blockhash expiry, per-provider slot tracking so you never read a blockhash from a node 40 slots ahead of the one you submit to.

Or put a proxy in front of your providers that already does it. RPC Plane is a self-hosted binary you point your app at instead of a single provider URL. Enable write broadcasting and sendTransaction fans out to every healthy provider at once, returning the fastest success. It scores providers on slot freshness continuously, so a node that drifts behind stops receiving your reads and your submissions — and it treats -32005 "node is behind" as retryable, moving to the next provider instead of handing you a failure. The routing docs cover the write path, including submission-only endpoints that accept sendTransaction and nothing else.

Either way the lesson holds: most "Solana is unreliable" stories trace back to a write path that assumed one RPC node would behave. Assume it won't, own your retry loop, and treat a signature as a receipt for an attempt — never as proof of anything.

Related: Solana RPC Failover: Multi-Provider Redundancy Done Right covers the read-path side — health scoring, circuit breakers, and routing strategies.