An unconfirmed transaction is a cryptocurrency transaction broadcast to a blockchain network but not yet included in a validated block. It exists between initiation and finality, meaning the fund transfer is visible to network participants but not yet permanently recorded on the ledger.
When a user sends a cryptocurrency payment, their wallet software assembles the transaction, signs it with their private key, and broadcasts it to the peer-to-peer network. Each node receiving the broadcast performs validity checks: verifying the digital signature, confirming the sender's wallet has sufficient funds, and ensuring proper formatting. Once accepted as valid, the node places the transaction in a local data structure called the mempool, a temporary holding area where pending transactions wait to be selected by a miner or validator.
The mempool is not a single centralized waiting room. Every full node maintains its own version, and each node's pool can vary slightly depending on which transactions have propagated to it. The total size of the Bitcoin mempool fluctuates constantly; during high demand it can hold tens of thousands of unconfirmed transactions.
Miners and validators do not process transactions in strict chronological order. Instead, they select transactions by fee rate, typically measured in satoshis per virtual byte (sat/vB) on Bitcoin. Transactions with higher fees are more profitable to include, so miners prioritize them. Those with lower fees are pushed back and may wait much longer for confirmation.
Several conditions can leave a transaction stuck in the mempool for an extended period.
Network congestion is the most common cause. When transaction volume spikes, the mempool fills faster than blocks can absorb. Bitcoin's block size is capped at about 1 MB, limiting how many transactions can be processed per block. During peak periods, fees rise sharply as users compete for limited block space.
An insufficient transaction fee is another primary reason. If a sender sets a fee too low for current network demand, miners will skip the transaction in favor of more profitable ones. The transaction can remain unconfirmed for hours or days.
Conflicting inputs can also cause a stall. If two separate transactions attempt to spend the same output (a situation known as a double-spend attempt), only one can be accepted by the network, and the other will eventually be discarded.
A transaction receives its first confirmation the moment it is included in a mined block. Each subsequent block added on top of that one adds another confirmation, deepening the transaction's position in the chain and making any attempt to reverse it progressively more expensive and computationally impractical.
Bitcoin follows the widely adopted standard of six confirmations before a transaction is considered final. Achieving that threshold requires an attacker to control more than 51% of the network's total hashing power for a sustained period, a feat that would cost billions of dollars in hardware and electricity on the current Bitcoin network.
Ethereum operates on a much faster block time of roughly 12 seconds, and most exchanges accept a deposit after 35 or more confirmations, which typically takes just a few minutes. Litecoin produces a block every 2.5 minutes, while networks like Solana can finalize transactions in under a second due to their proof-of-stake architecture.
Different exchanges and service providers set their own confirmation requirements. Bitstamp, for example, requires 3 Bitcoin confirmations before crediting a deposit, while others may require fewer for smaller amounts or more for large-value transfers.
If an unconfirmed transaction sits in the mempool too long without being picked up, nodes eventually drop it to free memory. On Bitcoin, the default timeout for most nodes is about two weeks. Once dropped, the transaction is cancelled, and the sender's funds remain in their wallet as if it never occurred. The user can then try the transfer again, ideally with a higher fee to avoid delay.
The specific timeout behavior can vary by node software and configuration, so there is no single universal expiry rule across all networks or clients.
Users who find their transactions stalled in the mempool have a few practical options to speed up confirmation.
Replace-By-Fee (RBF) allows a sender to broadcast a new version of an unconfirmed transaction that uses the same inputs but carries a higher fee. Nodes that support RBF will replace the original transaction in their mempool with the updated one. The higher fee then incentivizes miners to pick it up sooner. This mechanism only works if the original transaction was flagged as RBF-eligible at the time it was created.
Child-Pays-for-Parent (CPFP) is an alternative strategy available when the recipient holds the unconfirmed output. By creating a new transaction that spends the unconfirmed funds and attaches a high fee to the new transaction, the recipient effectively subsidizes the confirmation of the parent. Miners, calculating the combined fee of both transactions, are incentivized to include the parent in a block to unlock the profitable child.
Transaction accelerators offered by mining pools represent a third option. Some services allow users to submit their transaction ID for priority inclusion in the next block mined by that pool, sometimes for an additional fee.
.webp)