The worst outcome on Solana is not a failed transaction. A failed transaction tells you what went wrong: the log says slippage, or insufficient funds, or a program error, and you fix it. The worst outcome is the one where you sign, the wallet says "sent", and a minute later the signature does not exist. No error, no log, no fee charged, no explanation.
That silence has causes. There are seven places in the validator where a transaction is discarded without any record reaching you, and each one is a specific rule with a specific number. Knowing which door closed does not bring the transaction back, but it tells you what to change so the next one gets through.
Door One: The Leader's Floor, Closed Before Your Signature Is Checked
A leader buffers up to 100,000 transactions. When that buffer reaches 99% full, the scheduler publishes a floor — the priority of the lowest transaction it still holds — and the signature-verification stage discards any incoming packet below it before verifying it. The floor lifts only when the buffer drains back to 95%.
Below the floor your transaction never existed as far as that leader is concerned. Votes are exempt; everything else is not. And "priority" here is not your fee, it is your fee divided by the block space you requested — a transaction with a default 1.4-million-unit compute limit sits far lower than its fee suggests. Right-sizing that limit is the cheapest way through this door.
Door Two: The Two-Second Memory That Eats Your Resend
Every packet that reaches a validator is hashed into a bloom filter of 63,999,979 bits. If the same bytes arrive again within 2 seconds, the second copy is dropped as a duplicate. The filter resets when it ages past two seconds or when its false-positive rate reaches 0.1%.
Two consequences. Resending the identical signed transaction within two seconds achieves nothing; the copy is discarded. And roughly one in a thousand honest, distinct transactions is dropped as a false duplicate, with no counter you can see. If you resend, resend after two seconds — or resend as a new transaction with a fresh blockhash.
Door Three: The Connection Your RPC Does Not Have
Leaders accept transactions over QUIC, and they allocate capacity by the stake of the sender. A connection from an unstaked sender gets 128 concurrent streams. A staked sender's allowance scales with its share of stake, saturating at 512. A validator whose stake is below one fifty-thousandth of the total is treated as unstaked.
Your wallet never talks to the leader; your RPC provider does. If the provider forwards through an unstaked node, your transaction is competing for one of the smallest lanes at the door, and under load the lane is full. Nothing tells you this. The transaction is simply not admitted, and the provider's retry loop tries again into the same full lane.
Door Four: Forwarding Only Goes One Hop, and Only for the Staked
If a node that is not the leader receives your transaction, it may forward it to the upcoming leaders — but only if the packet came from a staked node, and never a packet that was itself forwarded. Forwarding targets the leaders at 2, 6 and 10 slots ahead, and is capped at 12 MB per second per node.
On the receiving side, a leader's fetch stage discards forwarded packets unless it is due to lead within 20 slots, about 6 seconds at today's 300 ms slots. A forwarded transaction that arrives at a validator whose window is 30 slots away is dropped on arrival.
Door Five: The Retry Service's Limits
When you send through an RPC node, it keeps your transaction in a retry pool and rebroadcasts every 2 seconds to the next 2 leaders. The pool holds 10,000 transactions; beyond that, a new transaction is sent once and then forgotten. A transaction that landed but failed on chain is dropped from the pool immediately and never retried. One that landed but has not been rooted is retained, so it can be resent if its fork dies.
Two settings decide your fate here. maxRetries: 0 means exactly one broadcast, no retries. And the node's idea of who the leader is refreshes every 1,000 ms — more than three slots at today's 300 ms — so under a fast leader rotation it can be aiming at the previous leader for most of a four-slot window, which now lasts 1.2 seconds.
Door Six: The Leader That Cannot Be Reached in Time
Direct-to-leader senders open QUIC connections to the next few leaders ahead of time. If a leader does not complete the handshake within 2 seconds, the sender sleeps another 1.6 seconds before retrying — by which time that leader's four-slot window, 1.2 seconds long at today's 300 ms slots, is long over. One unreachable leader costs you its entire window.
The address book is stale too. The list of validator addresses is refreshed every 5 minutes in the widely used client; a validator that restarts on new ports is unreachable to almost every sender for up to five minutes, and validators that do not advertise a QUIC port are skipped entirely as probably delinquent.
Door Seven: The Block Is Full in a Way You Cannot See
A block has four independent ceilings, and three of them scale with slot time. At today's 300 ms slots they are 75 million compute units in total, 30 million per writable account and 15 MiB of entries, alongside 100 MB of new account data, which does not scale. From epoch 1037, at 250 ms slots, they become 62.5 million, 25 million and 12.5 MiB. A transaction that would breach any of them is not failed — it is held until the next block. Then the next. On a hot pool that has already absorbed its 30 million units, every transaction writing to it waits, while its blockhash ages.
After 150 slots — about 45 seconds at today's 300 ms slots, 37.5 seconds from epoch 1037 when 250 ms slots take effect — the blockhash expires and the transaction can never land. The node stops retrying, the status query returns null, and the transaction has vanished, having never been invalid for a single moment. Correction, 17 September 2026: this post first read its durations off 400 ms slots — 150 slots as about a minute, 20 slots as about 8 seconds, a four-slot leader window as 1.6 seconds — and gave the old ceilings of 60 million compute units per block, 24 million per writable account and 20 MiB of entries. Mainnet has run 300 ms slots since epoch 1024 (26 August 2026), the 250 ms gate activated on 16 September 2026 and takes effect in epoch 1037, and the block limit has used a 100-million-unit baseline since 28 July 2026, which is 75 million at 300 ms. Every slot-derived number above has been recomputed.
How to Tell Which Door It Was
There is no report. You infer.
- Status null once the blockhash has expired — 45 seconds at today's 300 ms slots. It never landed. Rule out the fee first — compute your rank, not your price — then the account: if the pool you wrote to shows a high floor in the last 150 slots, it was contention, and the fix is timing and a smaller compute reservation, not a bigger tip.
- Status null immediately after a resend. You hit the two-second filter. Wait, or rebuild with a new blockhash.
- Landed on simulation, vanished in practice, repeatedly, on one provider. Ask what stake sits behind their sending node. The lane at the leader's door is theirs, not yours.
- Everything landed except during one leader's window. That leader was unreachable or rotating; the retry service aimed at the wrong node for part of the window. Nothing you did caused it, and nothing but the next window fixes it.
And if the transaction cannot afford to expire at all — a payout, a signed approval, anything with a human in the loop — the blockhash is the wrong tool. A durable nonce replaces it with one that lasts until you choose, which is its own post and its own set of hazards.
Dropped Transactions: Questions People Actually Ask
Why does my Solana transaction disappear with no error?
Because it was discarded before execution. The leader’s priority floor, a 2-second duplicate filter, stake-weighted admission, forwarding rules, retry-pool limits and block ceilings all drop transactions silently, and a transaction that never executes leaves no log.
How long does a Solana transaction stay valid?
150 slots after its blockhash: about 45 seconds at today’s 300 ms slots, 37.5 seconds from epoch 1037 when 250 ms slots take effect, and a minute under the 400 ms slots mainnet ran until August 2026. If it has not landed by then it can never land, and the signature status stays null.
Does resending the same Solana transaction help?
Not within two seconds; an identical packet is dropped as a duplicate. After that, resending helps only if the cause was reachability. If the cause was the fee floor or a full account, rebuild with a smaller compute limit or wait for the account to clear.
Is skipPreflight the reason my transaction vanished?
Skipping preflight removes the simulation that would have told you about an on-chain error, so a transaction that would fail is broadcast anyway. It does not by itself cause a drop, but it removes the only warning you had.
Constants read from the Agave validator source at commit beee69b958: core/src/banking_stage, core/src/sigverify_stage.rs, streamer/src/nonblocking/swqos.rs, send-transaction-service and cost-model/src/block_cost_limits.rs. Every one of these numbers changes with releases — re-read them before you depend on one.