Pushing a transaction means handing its raw bytes to a node so the network can see it again. It fixes exactly two problems: a broadcast that never reached the network, and a transaction that nodes dropped after two weeks unconfirmed. It cannot raise a fee. You need the raw hex, which any wallet that signed the transaction can show you, and one working endpoint, of which there are many. The error a node sends back tells you what is actually wrong, and the table below translates each one.
Every accelerator with a free button is doing one thing: taking the bytes of your transaction and posting them to a Bitcoin node. There is nothing in that you cannot do yourself in under a minute, and doing it yourself has one advantage no accelerator offers. You see the raw reply from the node, and that reply tells you the truth about your transaction.
This guide is the manual version of what our relay automates. Read it if you want to understand what the button does, if you want to push to a specific node, or if you just prefer to hold the transaction in your own hands.
Transaction ID and raw hex are different things
A transaction ID is a 64 character hash of the transaction. It is a label. Given only the label, a node cannot reconstruct the transaction, so a node that does not already have your transaction cannot do anything with the ID alone. This is the reason a txid based accelerator does nothing for a transaction the network has forgotten.
The raw hex is the transaction itself, serialized as hexadecimal. A typical single payment is a few hundred characters that start with the version bytes, usually 01000000 or 02000000. That string is everything a node needs, and pushing it is the only way to reintroduce a transaction the mempool has dropped.
When a push helps, and when it does not
A push helps when the network never received the transaction, or when nodes dropped it after the 14 day mempool expiry. A push does nothing when the network already holds the transaction, which is the usual case, because a node that has it simply answers that it already has it. And a push can never change the fee, because the fee is inside the signed bytes.
Where to find the raw hex
If your wallet signed the transaction, your wallet has the hex. If the transaction was ever seen by the network, a block explorer also has it, even after mempools drop it, because explorers keep what they saw.
| Source | Where | Notes |
|---|---|---|
| Electrum | History tab, right click the transaction, View Transaction, then Export or Copy | The window shows the hex and offers to copy it. Also shows whether the transaction is signed. |
| Sparrow | Transactions tab, right click the transaction, Copy Transaction as Hex | Also available from the transaction's own view via Save or Copy. |
| Bitcoin Core | getrawtransaction <txid> in the console or bitcoin-cli | Returns the hex for any transaction your node has seen. Your own wallet transactions are always available. |
| mempool.space | https://mempool.space/api/tx/<txid>/hex | Plain text hex. Works for transactions the explorer has seen, including dropped ones. |
| blockstream.info | https://blockstream.info/api/tx/<txid>/hex | Same format, independent operator. |
Phone wallets vary. Many show the hex somewhere in the transaction details screen, some do not expose it at all. If yours does not, the explorer route works for any transaction that was broadcast at least once, and that covers nearly every real case.
Check the hex before you push it
Paste it into a decoder first. mempool.space has one at /tx/push that shows the inputs, outputs and fee before sending, and Bitcoin Core's decoderawtransaction does the same offline. You are checking three things: the outputs go where you expect, the fee is what you expect, and the string is complete. A truncated paste is the most common reason a push fails, and the decode error for it is unmistakable.
Where to push it
Any node that exposes a broadcast endpoint will take raw hex. These four cover the different ways of doing it.
| Endpoint | How | What comes back |
|---|---|---|
| StuckBTC relay | Paste the hex instead of a txid on the homepage | Twenty nodes, each reply shown separately, live |
| mempool.space | POST the hex as the body to https://mempool.space/api/tx | The txid on success, the node's error text on failure |
| blockstream.info | POST the hex as the body to https://blockstream.info/api/tx | Same as above, independent operator |
| Bitcoin Core | sendrawtransaction <hex> | The txid, or an RPC error with a reason string |
From a terminal, the explorer route is one line:
curl -X POST https://mempool.space/api/tx -d "02000000000101d6fa..."If it prints a 64 character hash, that node accepted the transaction and is relaying it. If it prints anything else, that is the node telling you why not, and the next section decodes it.
Why pushing to many nodes beats pushing to one
Bitcoin nodes gossip, so one acceptance is usually enough for the transaction to spread. Usually is the operative word. A node can be behind the chain tip, can have a stricter fee policy than its peers, or can be sitting on an old conflicting transaction. Pushing to a spread of independent nodes turns one answer into a survey, and the survey is what tells you whether the problem is the network or your transaction. That is the only reason the relay exists.
What the error means
Nodes answer in the language of Bitcoin Core, and the strings are precise. The table covers the ones people actually hit. Several are not errors at all.
| Reply | What it means | What to do |
|---|---|---|
txn-already-in-mempool or txn-already-known | The node already has it. Your transaction is fine and propagated. | Nothing. If it is not confirming, the fee is the issue, not the broadcast. |
Transaction already in block chain | It confirmed. | Nothing. Check the explorer, the money has moved. |
bad-txns-inputs-missingorspent | An input is already spent, or the parent is unknown to this node. | If a replacement confirmed, this transaction is dead by design. If the parent was dropped, push the parent's hex first. |
min relay fee not met | Fee rate is below this node's floor. Since Bitcoin Core 29.1 the default is 0.1 sat/vB. | Bump with RBF or CPFP. Pushing harder cannot help. |
mempool min fee not met | The node's mempool is full and it is only admitting transactions above a dynamic floor. | Try other nodes, which may have room. If they all say it, bump the fee. |
txn-mempool-conflict | The node holds a different transaction spending the same input. | Your replacement did not qualify, usually because its fee is not higher than what it replaces. Raise it and push again. |
insufficient fee, rejecting replacement | This is an RBF attempt whose fee increase is too small. | The replacement must pay more in absolute fee and at least the minimum relay increment on top. Raise it. |
TX decode failed | The hex is not a complete transaction. | Almost always a truncated paste. Copy the whole string again. |
non-mandatory-script-verify-flag or a signature error | The transaction is malformed or unsigned. | Export from the wallet again after signing. Do not edit hex by hand. |
dust | An output is too small for nodes to relay. | Rebuild the transaction without the tiny output. |
too-long-mempool-chain | Too many unconfirmed ancestors or descendants for this node's limit. | Wait for some parents to confirm, or bump the oldest parent so the chain clears. |
Notice how many of these are the node saying your transaction is already fine. In our relay logs the single most common reply is some form of already known, which is a node politely explaining that the rebroadcast was unnecessary.
The one thing no push can do
A push cannot raise the fee. The fee is the difference between inputs and outputs, and both are inside the signed bytes. If every node answers with a fee error, the fix is a new transaction with a higher fee, which is RBF from the sender or CPFP from the receiver. Any service that says it can push a low fee transaction through by broadcasting it more is describing something that does not exist.
Two real cases where the push is the fix
The broadcast that never happened
A wallet on a flaky connection can sign a transaction, show it as sent, and never actually deliver it. The wallet history says pending, the explorer says not found, and nothing changes for hours. That mismatch is the signature of a failed broadcast, and it is worth checking before anything else. The guide to a transaction that disappeared walks through the diagnosis. The fix is exactly this article: export the hex, push it, watch a node answer with the txid.
The transaction that was dropped
Bitcoin Core forgets an unconfirmed transaction after 14 days by default. When that happens, the explorer stops showing it, your wallet may still list it, and the coins have not moved. The transaction is not dead; it is just no longer in anyone's mempool. If its fee rate is now enough to confirm, pushing the hex brings it back and it will confirm. If the fee is still too low, push the hex and then bump it, or just build a new transaction from the same coins with a proper fee, which in most wallets is what happens automatically once the old one is forgotten.
Doing it with the relay instead
The homepage box accepts either a transaction ID or raw hex. Given hex, the relay posts it to twenty independent nodes in parallel, streams each reply as it lands, and labels every one with the state the node actually reported: relayed, already held, out of date with the number of blocks behind, or rejected with the node's reason. Then it reads the fee against the next block and tells you whether a bump is needed and roughly what it costs in sats.
That is all it does, and all it needs to. It never asks for a key, never touches your coins, and never shows a green tick for a node that said no.
Push it to twenty nodes at once
Paste a transaction ID or the raw hex. Every node's reply appears as it arrives, and the diagnosis follows.
Frequently asked questions
How do I push a Bitcoin transaction manually?
Get the raw transaction hex from the wallet that signed it, or from a block explorer's /api/tx/TXID/hex endpoint, then POST that hex to a node's broadcast endpoint such as https://mempool.space/api/tx, or run sendrawtransaction in Bitcoin Core. A successful push returns the 64 character transaction ID.
What is the difference between a txid and raw hex?
The txid is a hash that names the transaction. The raw hex is the transaction itself, serialized. A node that does not already hold the transaction can do nothing with the txid alone, which is why a dropped transaction can only be reintroduced with its hex.
Where do I find the raw hex of my transaction?
In Electrum, right click the transaction in History and choose View Transaction, which shows and copies the hex. In Sparrow, right click the transaction and choose Copy Transaction as Hex. In Bitcoin Core, run getrawtransaction with the txid. If the transaction was ever broadcast, mempool.space or blockstream.info return it at /api/tx/TXID/hex.
What does txn-already-known mean when I push?
The node already holds your transaction. That is good news: the transaction propagated and there is nothing wrong with the broadcast. If it is not confirming, the fee is too low, and only a fee bump with RBF or CPFP will fix that.
What does bad-txns-inputs-missingorspent mean?
One of the transaction's inputs is either already spent or unknown to that node. If a replacement transaction confirmed, the original is dead by design. If the parent was dropped from mempools, push the parent's hex first and then this one.
Can pushing a transaction make it confirm faster?
No. Pushing puts the bytes in front of nodes; it does not change the fee, and the fee is what decides when miners include a transaction. Pushing fixes a transaction the network never received or has dropped. A transaction the network already holds is not helped by any rebroadcast.
What does min relay fee not met mean?
The transaction's fee rate is below the node's minimum for relaying. Since Bitcoin Core 29.1 the default floor is 0.1 sat/vB. The fix is a replacement with a higher fee via RBF from the sender, or a CPFP child from the receiver.