To push a Bitcoin transaction is to hand a signed transaction to a node so it can relay it to the rest of the network. A push fixes a transaction that was never broadcast and a transaction that was dropped after fourteen days, because in both cases no node holds it. A push does nothing for a transaction the network already has, because every node ignores a copy of something it already holds. There is no such thing as pushing to miners; miners run nodes like everyone else, and the only direct route to them is a paid out of band service.
People arrive at this page with a transaction ID, a wallet that says pending, and a search for push bitcoin transaction or push btc transaction to miners. The phrase comes from an old Blockchain.com tool called pushtx, and it has stuck. This guide explains what the act really is, which two problems it solves outright, the one problem it cannot touch, and what each public endpoint says back when you try it.
What a push actually is
A Bitcoin transaction is a small signed message. Your wallet builds it, signs it with your keys, and then has to get it to the network. That last step is the push. The wallet connects to one or more nodes and sends the raw transaction bytes. A node that accepts it stores it in its mempool and gossips it to its peers, who gossip it to theirs, until within a few seconds nearly every node on the network holds a copy. Miners, who run nodes too, pick from that shared pool when they build a block.
Four words describe the same act. Broadcast is the formal term. Push comes from the pushtx tools. Send raw is the name of the node command, sendrawtransaction. Rebroadcast means doing it again for a transaction that has already been sent once. None of them changes the transaction. The fee, the inputs and the outputs are fixed when the wallet signs. A push only changes who has heard about it.
The two problems a push fixes
One: the broadcast never happened
The wallet signed the transaction and showed it as sent, and the hand off to the network failed quietly. A dropped mobile connection, a wallet that talks to a single server that was down, a firewall blocking outbound peer connections, or a node that rejected the transaction on a policy rule while the wallet reported success anyway. The sign of this case is that no explorer has ever seen the transaction, not even briefly. Our guide to the not found error walks through how to tell it from a typo or a wrong chain.
Two: it was dropped
The transaction was visible for a while and then vanished. Most nodes discard an unconfirmed transaction after 336 hours, fourteen days, and a node whose mempool hits its 300 MB memory limit evicts the lowest paying transactions early. Either way no node holds it any more, and nothing that nobody holds can be mined. A push puts it back. Whether it then confirms depends on the fee it was dropped for, which has not changed; the guide to vanished transactions covers when to push the old one and when to send a new one instead.
In both cases the push is the entire fix, and it costs nothing.
The one problem a push cannot touch
A transaction that is pending because its fee is too low. The network already holds it. Every one of the twenty nodes we push to will answer "already held", which is the node's polite way of saying it knew before you arrived. Pushing again, or pushing harder, or pushing every fifteen minutes as one paid service offers, changes nothing, because a node that already has a transaction ignores a second copy by design.
This is the single most common misunderstanding in the whole accelerator category, and it is the one the paid rebroadcast services depend on. If your transaction is visible on an explorer, a push is not your fix. A fee bump is. The sender does it with RBF, the receiver with CPFP, and either costs only the shortfall.
There is no push to miners
Miners do not have a separate inbox. They run Bitcoin nodes, those nodes are part of the gossip network, and they see your transaction the same way everyone else does, within seconds of a successful push. The only way to put a transaction in front of a miner that the gossip network would not, is to pay the pool out of band to treat it as higher fee than it is. That is what a paid pool accelerator sells, and it is a different thing from a push.
Push to twenty named nodes, free
Paste the transaction ID or the raw hex. Every node answers for itself: relayed, already held, out of date, or rejected with the reason.
How the relay on this site pushes
When you press Transmit with a transaction ID, we first fetch the raw transaction from a public explorer. If no explorer has it, we tell you so, and that is itself the diagnosis: the transaction needs its raw hex pushed from your wallet. If we find it, we hand the raw bytes to twenty independent nodes at once: public Esplora and mempool instances run by different operators in different countries, plus the push endpoints of the big explorers. Each one answers for itself and the scope shows the answer.
| Answer | Meaning | What it tells you |
|---|---|---|
| Relayed | The node accepted the transaction and is passing it on | That node did not have it before. The push did something here |
| Already held | The node knew the transaction before we arrived | Good news for propagation, and proof that pushing again changes nothing |
| Out of date | The node is behind the chain tip, and we say how far | Ignore it; a stale node cannot help you and we will not pretend it can |
| Rejected | The node refused, with the reason it gave | Usually a fee below that node's own policy, which is not a verdict on the transaction |
| Unreachable | No answer in time | Nothing about your transaction, something about that server today |
Rejected deserves a note. Some operators run their nodes with a minimum relay fee of 1 sat/vB, higher than the 0.1 sat/vB default since Bitcoin Core 29.1. A 0.15 sat/vB transaction will be rejected by those nodes with "fee below this node policy" and accepted by the rest. Twenty answers side by side show you that pattern instead of hiding it behind a single green badge.
Pushing raw hex instead of a txid
If no explorer has the transaction, there is nothing for us to fetch, so you paste the raw hex yourself. It is a long string of hexadecimal characters your wallet can show or export, under names like raw transaction, transaction hex or export signed transaction. We push those bytes to all twenty nodes exactly as above. The raw hex guide shows where the hex lives in each wallet and how to push it by hand against any endpoint if you prefer.
Every public push endpoint, and what it says back
You do not need us or anyone to push a transaction. These endpoints are public, free and need no account. We sent each one a deliberately broken transaction on 10 October 2026 and recorded the exact reply, so you know what a rejection looks like before you see one.
| Service | How to push | Reply to a broken transaction |
|---|---|---|
| mempool.space | POST the hex to /api/tx | "sendrawtransaction RPC error: TX decode failed. Make sure the tx has at least one input." |
| blockstream.info | POST the hex to /api/tx | Same wording, same software |
| Any mempool instance (emzy.de, bitaroo, ninja and the rest) | POST the hex to /api/tx | Same wording; these are the nodes behind our relay |
| Blockchair | POST data=hex to /bitcoin/push/transaction | "Invalid transaction. Error: TX decode failed…" |
| BlockCypher | POST {"tx":hex} to /v1/btc/main/txs/push | "Error validating transaction: insufficient priority and fee for relay." |
| Trezor Blockbook | GET /api/v2/sendtx/hex | "-22: TX decode failed…" |
| Blockchain.com pushtx | The old form | Returns a bare 400. The tool that named the whole practice no longer gives a readable answer |
Every one of those replies comes straight from the node's own sendrawtransaction call. The error code -22 means the bytes could not be decoded at all, usually a truncated or mistyped hex. The errors that matter for a real transaction are different, and they are the subject of the next section.
What the real rejections mean
- min relay fee not met. The fee rate is below that node's minimum. Default 0.1 sat/vB, but some operators set 1 sat/vB. Try other nodes; if all reject, the fee is genuinely too low and a push was never the fix.
- txn-already-known or txn-already-in-mempool. Already held. The network has it. Stop pushing and bump instead.
- missing inputs. The transaction spends an output the node cannot find: either already spent by a replacement, or produced by a parent the node does not have. Push the parent first, or check whether a replacement already confirmed.
- insufficient fee, rejecting replacement. You pushed a replacement that does not pay enough more than the original. RBF rules require the new transaction to pay a higher absolute fee plus the relay increment.
- txn-mempool-conflict. Another transaction in the mempool spends the same input. One of them will confirm, the other will never be mined.
- non-mandatory-script-verify-flag or mandatory-script-verify-flag-failed. The signature or script is invalid. The wallet produced something the network will not accept, which is rare and worth investigating, never pushing harder.
Push, bump, or pay: the decision
| Situation | Explorer shows | The fix | Cost |
|---|---|---|---|
| Never broadcast | Not found, ever | Push the raw hex | 0 sats |
| Dropped after 14 days | Was visible, now not found | Push the raw hex, or send a new payment at a clearing rate | 0 sats, or the new fee |
| Low fee, you sent it | Unconfirmed | RBF bump from your wallet | The shortfall, often ~100 sats |
| Low fee, you received it | Unconfirmed | CPFP spend from your wallet | A few hundred to a few thousand sats |
| Low fee, nobody can bump | Unconfirmed | Wait, or a pool accelerator that names its pools | 0, or far more than the shortfall |
| Fee is fine, under an hour | Unconfirmed | Nothing. Blocks are random | 0 sats |
Notice that a push appears only in the first two rows. Everything else is a fee question, and the hour by hour guide reads a pending transaction off the clock to tell you which row you are in.
Is it safe to push a transaction through a website?
Yes, with one rule. A transaction ID and a signed raw transaction are both public information. The raw hex contains your signatures, which prove you authorised this exact transaction and nothing else; it cannot be altered to pay someone different without invalidating the signature, and it cannot be used to spend anything else you own. The rule is simple: never give any site a seed phrase or a private key. A push needs the signed transaction, never the keys that signed it. Any accelerator that asks for more is a theft attempt, not a service.
After the push
A successful push to even one well connected node reaches the rest of the network within seconds, so the twenty node fan out is belt and braces rather than necessity. After that, the transaction's fate is its fee rate. If it pays at or above the rate the next block is clearing, expect one to three blocks. If it pays below, it has rejoined the queue it was dropped from, and the next step is a bump or a replacement. Paste the transaction ID back into the checker a minute after the push and it will tell you which.
The bottom line
A push is the right fix for exactly two problems, a transaction that never reached the network and a transaction the network has forgotten, and it is free, public and instant for both. For a transaction the network already holds, a push is theatre, however many nodes it reaches or however often it repeats. Check which case you are in first, push if it is one of the two, and bump if it is not.
Twenty nodes, one paste
Txid or raw hex. Relayed, already held, out of date or rejected, with latency, for every node. Then the diagnosis.
Frequently asked questions
What does it mean to push a Bitcoin transaction?
To hand a signed transaction to a Bitcoin node so it can store it in its mempool and relay it to the rest of the network. Push, broadcast, rebroadcast and send raw all describe the same act. A push does not change the transaction's fee, inputs or outputs; it only changes which nodes have heard about it.
Can I push a Bitcoin transaction to miners?
Not directly. Miners run ordinary Bitcoin nodes and see your transaction through the same gossip network as everyone else, within seconds of a successful push. The only way to put a transaction in front of a miner beyond that is to pay the pool out of band to treat it as higher fee, which is what paid pool accelerators sell and is not a push.
Does pushing a stuck transaction again speed it up?
No, if the network already holds it. Every node ignores a copy of a transaction it already has, so a second push changes nothing. Pushing helps only when no node holds the transaction: a broadcast that never happened or a transaction dropped after fourteen days unconfirmed.
How do I push a Bitcoin transaction for free?
Paste the raw transaction hex into any public push endpoint: mempool.space or any mempool instance at /api/tx, blockstream.info, Blockchair, BlockCypher or a Trezor Blockbook server. Or paste the txid or hex into the relay on this site, which pushes to twenty of those nodes at once and shows each answer. None of it costs anything or needs an account.
What does TX decode failed mean when I push?
The node could not read the bytes you sent as a transaction at all. Almost always the hex is truncated, has a stray character, or is not the raw transaction but something else such as a txid. Copy the full signed transaction again from the wallet and retry.
What does min relay fee not met mean?
The transaction's fee rate is below that node's minimum for relaying. The Bitcoin Core default is 0.1 sat/vB since version 29.1, but some operators set 1 sat/vB. If other nodes accept it, the transaction will propagate. If every node rejects it, the fee is too low and the fix is a bump, not another push.
Is it safe to paste my raw transaction into a push tool?
Yes. A signed raw transaction is public information that authorises only that exact transaction. It cannot be altered to pay someone else without breaking the signature, and it cannot spend anything else you own. Never give any tool a seed phrase or private key; a push needs the signed transaction, never the keys.