How to get a BTC transaction confirmed if it's stuck in the mempool for a long time
Got a transaction stuck in a pending state with little hope of getting confirmed soon? Let’s learn why this happens and how it can be fixed.
Transactions get stuck because the transaction fee you set was too small. A fee that’s “too low” simply means that miners are filling their blocks with other transactions that pay them higher fees. Unless transaction volumes decrease, your transaction may not get confirmed and the funds won’t reach their intended destination.
However, it should be noted that your funds are NEVER at risk of permanent loss when pending. They will either get confirmed eventually, or they’ll be “forgotten” by nodes after a certain period of time and you’ll regain access to them in your wallet.
In the meantime, you may have some options to speed up your transaction, depending on what features are offered by the wallet you used to send it. We’ll go through each of those options in this article.
The mempool (short for “memory pool”) is a collection of pending transactions that have been validated by nodes but not yet confirmed (i.e. included in a block of the blockchain) by miners.
It is built into the network that transactions with too low of a fee will be rejected right away. In other words, nodes will not include the transaction in their mempool (aka memory pool) and it will not propagate to other nodes. At the time of writing, the minimum transaction fee required to enter the mempool is about 5 sat/vBtye (satoshis per vByte of data).
You can think of a transaction fee as paying for the block space that is consumed by your transaction. Block space is measured in vBytes. That’s why transaction fees in Bitcoin are not dependent on the amount of funds being transferred, but on the amount of data that needs to be included in the blockchain.
This chart helps you visualize how transaction fees can change over time. When demand for block space is high (i.e. high transaction volume), fees go up. Essentially, you as a user have to compete with other users to incentivize profit-driven miners to include your transaction in their block.
As mentioned above, your transaction may eventually be “forgotten” if you set too low of a fee. This is because each node’s mempool is not infinite in space, but rather limited to 300MB in the typical node implementation. When the mempool reaches full capacity, nodes will typically get rid of the lowest fee transactions in order to add higher fee transactions. Once this occurs, the funds in your “forgotten” transaction become accessible to you again.
The graph below will help you to see how this happens in practice. On the left side of the graph, the mempool is clearing out regularly, meaning that even 1-2 sat/vByte transaction fees were sufficient if you were okay with waiting a while for confirmations. On the right side, however, your transaction will never even be included in the mempool if the fee is below 5-6 sat/vByte.
Your transaction can also be “forgotten” because of node restarts and mempool expiry times. On average, it takes a few days for this to occur and for you to regain access to your funds. However, it depends on transaction volumes and other variables, so it can sometimes take much longer.
For those cases, we’ll explain the other methods you can try for getting your transaction confirmed.
What if you were to create a new transaction sending the same funds to the same destination but with a higher fee? Uh-oh... from the perspective of a node seeing the new transaction, you’ve just attempted a double-spend. When detected, nodes simply drop the newer transaction.
Bitcoin nodes follow a “first-seen” policy, which means that node software considers the first transaction they receive as valid, and any subsequent transaction they see attempting to spend the same coins will be considered invalid and will not propagate.
So, what options exist if a transaction is stuck in the mempool and you don’t want to wait for it to be confirmed or forgotten? Below are the most common solutions.
In 2016, a policy was proposed in BIP 125 to allow replacement transactions. It essentially enables you (ie. the sender) to notify nodes in advance when you want a transaction to be replaceable.
Let’s say you send a transaction and you’d like to be able to replace it in case you set the fee too low. If the RBF feature was enabled and the nodes implemented the RBF policy, you’re in luck. When the replacement transaction is sent to the nodes, they will replace the old transaction with the new one and broadcast it to their node peers.
Then miners will see the new, higher-fee transaction and they’re more likely to include it in a future block because they will earn more by doing so.
Remember, this can only be initiated by the sender. If you’re the receiver, you’ll want to look into a Child Pays for Parent transaction.
As we explained in our article about Taproot and Chain Analysis, UTXOs cannot be partially spent. Instead, they are always spent in full, but any leftover amount — called “change” — is just sent back to you as a fresh UTXO.
In a child pays for parent (CPFP) scenario, you can get your pending transaction confirmed by sending another transaction to yourself using the change from that pending transaction. You effectively create a “child” transaction to pay yourself the change but with a higher fee, as shown below.
Unlike an RBF transaction, a CPFP transaction can be initiated by any party receiving a UTXO in the parent transaction. In other words, either party A2 or B from the example above can use the funds they receive in the parent transaction to cover a higher transaction fee in a child transaction.
Here’s why it works for getting stuck transactions into a block. While miners would like to only include the child transaction because it has a higher fee, that isn’t possible. The child transaction is based on the unconfirmed parent transaction, so it’s only valid if the parent transaction is also on the blockchain. They become a package deal.
This means the cumulative transaction fees of the two transactions must be sufficient (in terms of sat/vByte) to get confirmed. In other words, the average of the two fees must be greater than the current fee level required to get a new transaction confirmed.
In practice, creating a CPFP transaction is much more difficult as it requires spending from an unconfirmed transaction, something that many wallets do not allow.
Finally, if RBF and CPFP aren’t options, you can try a more roundabout way of getting your transaction included in a block: a transaction accelerator.
This is a service offered by miners where they will take an external payment (e.g. using an altcoin, PayPal, or WeChat Pay) to include your transaction in one of their blocks. Basically, you provide adequate financial incentive to miners by paying them an extra fee on the side. We do not offer this service at Slush Pool, but a quick google search for “BTC transaction accelerator” will yield some results.
These external payments for transaction fees are known as “out-of-band” payments and they can potentially result in lower revenue for miners, so this is controversial. Stratum V2 brings greater transparency to out-of-band payments, as you can read about in this article from Deribit Insights.
It’s up to every wallet developer to choose which of the options described above they want to include for their users. For example, exchange wallets typically force a fixed fee no matter the amount being sent. That makes sense, as stuck transactions will inevitably create unhappy users and support headaches for them. Self-custody wallets (where you control your own keys) will often have more available options to boost a stuck transaction.
As a BTC user, you have the opportunity to be your own bank. That comes with many advantages including censorship and seizure resistance, but it also means that you can get into confusing situations like having a stuck transaction. We hope this article helped you understand what to do and how to prevent this from happening again in the future.
Bitcoin mining software company: Slush Pool, Braiins OS+ & Stratum V2.
By miners, for miners.
Industry leaders in transparency and innovation, with more than 1.25 million BTC mined since 2010.
Increase hashrate on S9s to 17+ TH/s, improve efficiency as much as 20%, and get 50% lower pool fees on Slush Pool
Cutting-edge firmware with an implementation of Stratum V2 and mining software written from scratch in Rust language.
Quality improvements including reduced data loads, empty block elimination, hashrate hijacking prevention, and more.