An unconfirmed transaction that vanishes has not taken your coins anywhere. Either it never reached the network, or it was dropped after the fourteen day expiry. In both cases the inputs are still yours. This is also the one situation where rebroadcasting is genuinely the correct fix rather than theatre.
This one produces more alarm than any other failure mode, because the transaction is simply gone. Your wallet may still show it. Every block explorer says not found. It feels like the coins fell through a crack in the floor.
They did not, and the reason is worth internalising: an unconfirmed transaction never moved anything. Moving coins requires a miner to put the transaction in a block. Until that happens, the transaction is a signed request sitting in memory on various computers, and memory gets cleared. Clearing it does not spend anything.
What not found actually means
Block explorers show two different things and people conflate them. The blockchain is permanent. The mempool is temporary memory that every node manages independently.
When an explorer says not found, it is telling you the transaction is in neither. It is not in a block, and it is not in that node's mempool right now. That is the entire meaning. It carries no information whatsoever about your coins.
Cause one: it never propagated
The most common version. Your wallet built and signed the transaction, tried to send it, and the send failed without a clear error.
Why broadcasts fail silently
- A mobile connection dropped at the exact moment of sending.
- The wallet sat behind a firewall or restrictive network blocking outbound peer connections.
- The node it reached rejected the transaction on a policy rule and the wallet reported success anyway.
- The wallet was connected to a single server that happened to be down.
The signature of this case is that the transaction has never been visible anywhere, not even briefly.
Cause two: it was dropped after fourteen days
If it was definitely visible before and is now gone, this is almost certainly what happened. Bitcoin Core discards unconfirmed transactions after 336 hours, and nodes also evict the cheapest transactions early when the mempool fills.
Cheap transactions are dropped first, which is exactly why the ones that disappear are usually the ones priced near the relay floor. If that describes yours, resending it at the same fee will produce the same outcome a fortnight later. Raise the fee.
Cause three: it is not the transaction you think
Less dramatic, still common. A mistyped or truncated transaction ID. An ID from a different chain, which happens constantly with Bitcoin Cash and Litecoin. An identifier copied from the wrong row in a wallet history.
Before doing anything technical, copy the transaction ID directly from your wallet again and paste it fresh into an explorer.
Confirm which case you are in
We query twenty independent nodes rather than one explorer. If a single one of them still holds your transaction, we will find it.
Why checking twenty nodes matters here
Mempools are not synchronised. One node dropping a transaction says nothing about the others. A transaction can be absent from the explorer you happened to check and still alive on several nodes elsewhere.
That distinction changes what you should do next. If some nodes still hold it, the transaction is alive and can be bumped normally with a fee replacement. If none do, it needs reintroducing from your own copy.
How to export the raw transaction
To put a forgotten transaction back on the network you need the signed transaction itself, not the transaction ID. The ID is only a fingerprint, and no node can reconstruct a transaction from it. If nobody on the network has a copy, yours is the only one that exists.
| Wallet | Where to find it |
|---|---|
| Electrum | Open the transaction, then copy or export it. The result is a long hex string |
| Sparrow | Transaction tab, then the raw or hex view |
| Bitcoin Core | Console, then gettransaction <txid> and read the hex field |
| BlueWallet | Transaction details, then the raw transaction option |
| Hardware wallet suites | Usually not exposed. If the transaction is gone, simply create a new payment |
The raw hex is not sensitive
A signed transaction is meant to be published to the entire network. It contains no private key and reveals nothing your transaction would not reveal once it confirms. Pasting it into a broadcast tool is normal and safe. A seed phrase is a completely different thing and should never be pasted anywhere, ever.
Rebroadcasting it
With the hex in hand, push it to as many independent nodes as possible at once. One node accepting it is enough to put it back into circulation, and more nodes means it spreads faster from there.
This is the scenario where rebroadcast services earn their existence. Worth saying clearly, because the same service does nothing at all when the network already holds your transaction, which is the far more common situation described in our look at whether accelerators work.
If it gets rejected
A rejection is informative rather than alarming. Missing or spent inputs means the coins it wanted to spend have already been used by another transaction, so this one can never confirm and you should stop trying. A fee related rejection means the transaction is below what nodes will relay, and you need to build a new one at a higher fee instead.
If the inputs were already respent
Sometimes a wallet, seeing the transaction vanish, quietly rebuilds a new payment using the same coins. In that case the original can never confirm, because its inputs are gone.
Check whether a different transaction spending those same coins exists and confirmed. If so, the payment already happened under a different transaction ID, and there is nothing left to fix. Look at the receiving address rather than the transaction ID to work this out.
When to give up and just re-send
Recovering the exact original transaction is rarely important. What matters is that the payment reaches the recipient. If the coins show as spendable in your wallet and the old transaction is gone from the network, the simplest correct action is to send again at a sensible fee.
Do that rather than fighting to resurrect a transaction that was too cheap to survive in the first place, because it will simply get dropped a second time. Check what the current rate needs to be before you send.
The bottom line
A vanished transaction is a propagation problem, never a loss of funds. Check the ID first, check across many nodes rather than one, and if the network genuinely has no copy, rebroadcast your own or make the payment again at a fee that will actually hold.
Put it back on the network
Paste the transaction ID to search, or paste the raw hex to push it back out through twenty independent nodes. Free.
Frequently asked questions
My Bitcoin transaction disappeared. Are my coins gone?
No. An unconfirmed transaction never moved anything, so the coins are still controlled by your keys. If the transaction was dropped from mempools, the inputs simply become spendable again and your wallet balance returns to normal after a rescan.
Why can no explorer find my transaction ID?
Either the transaction never reached the network because the broadcast failed silently, or it was dropped after the fourteen day mempool expiry, or the transaction ID is wrong or from a different chain. Explorers only show what is in a block or currently in their own mempool.
How do I get a dropped transaction back onto the network?
You need the signed raw transaction hex, because no node can rebuild a transaction from its ID alone. Export the hex from your wallet and push it to as many independent nodes as possible. One acceptance is enough to put it back into circulation.
Is it safe to paste my raw transaction hex into a website?
Yes. A signed transaction is designed to be published to the whole network and contains no private key. It reveals nothing that would not be public once the transaction confirms. A seed phrase is entirely different and should never be pasted anywhere.
What if rebroadcasting is rejected?
The rejection reason matters. Missing or spent inputs means the coins were already used by another transaction, so this one can never confirm. A fee related rejection means the transaction is below what nodes will relay and you need to create a replacement at a higher fee.
Should I just send the payment again?
Usually yes, provided the original is genuinely gone from the network and the coins show as spendable in your wallet. Recovering the exact original transaction rarely matters. Send again at a fee above the current next-block rate so it does not get dropped a second time.