Unconfirmed Transaction

What Is an Unconfirmed Transaction?

An unconfirmed transaction is a Bitcoin transaction that has been signed, broadcast to the peer-to-peer network, and validated by nodes, but has not yet been included in a mined block. It exists in a pending state inside each node's mempool: a per-node data structure that stores valid-but-unconfirmed transactions. Every node maintains its own independent mempool with its own policy rules, so there is no single global mempool.

Until a miner selects the transaction and includes it in a valid block, it has zero confirmations. The transaction is not considered settled, and the spent funds could theoretically be redirected via a conflicting transaction. Understanding unconfirmed transactions is essential for anyone building on Bitcoin, as confirmation delays directly affect payment reliability and user experience.

How It Works

The journey from unconfirmed to confirmed follows the Bitcoin transaction lifecycle:

1. A wallet constructs a transaction spending one or more UTXOs, signs it with the appropriate private keys, and broadcasts it to connected peers
2. Each receiving node validates the transaction: correct signatures, unspent inputs, outputs not exceeding inputs, valid scripts, and compliance with local mempool policy
3. If valid, the node adds it to its mempool and relays it to peers. The transaction propagates across the network within seconds
4. The transaction waits in mempools as an unconfirmed transaction. Miners select transactions from their mempools based on fee rate (sat/vB), prioritizing the most profitable ones
5. When a miner finds a valid block containing the transaction, it receives its first confirmation. Each subsequent block adds another confirmation

Bitcoin targets an average block time of 10 minutes, adjusted every 2,016 blocks via difficulty adjustment. Under normal conditions with an adequate fee rate, a first confirmation typically arrives within 5 to 20 minutes. For full security, merchants and exchanges commonly wait for 3 to 6 confirmations (30 to 60 minutes).

Why Transactions Stay Unconfirmed

Several factors can cause a transaction to remain unconfirmed for extended periods or be dropped entirely:

• Low fee rate: the most common cause. Miners prioritize higher fee-rate transactions, so a transaction below the current marginal fee rate for block inclusion simply waits. During fee market spikes, even previously reasonable fees can become insufficient.
• Mempool congestion: when demand for block space exceeds supply, the effective minimum fee rate rises. Transactions below this dynamic threshold remain stuck.
• Mempool size limits: Bitcoin Core defaults to a maximum mempool size of 300 MB. When full, the lowest fee-rate transactions are evicted and the dynamic minimum mempool fee rises above the static minimum relay fee (1 sat/vB by default).
• Transaction expiry: transactions that remain unconfirmed for more than 336 hours (14 days) are dropped from the mempool by default.
• Non-standard scripts: transactions using scripts that fall outside standard policy rules are rejected by default-configured nodes, preventing relay across the network.
• Dust outputs: transactions creating outputs below the dust threshold (based on a dust relay fee of 3,000 sat/kvB) are rejected from the mempool.
• Chain limits: transactions exceeding ancestor or descendant limits are rejected. As of Bitcoin Core 31.0, the cluster mempool architecture enforces cluster limits of 64 transactions and 101 kB per cluster.

Checking Transaction Status

You can check whether a transaction is confirmed using Bitcoin Core's RPC interface or any block explorer:

# Check transaction status via Bitcoin Core RPC
bitcoin-cli gettransaction <txid>

# Check mempool entry directly
bitcoin-cli getmempoolentry <txid>

# View current mempool statistics
bitcoin-cli getmempoolinfo

The getmempoolinfo command returns the current mempool size, transaction count, and the dynamic minimum fee rate: useful context for understanding why a transaction may be stuck.

Fee Bumping: Unsticking Transactions

When a transaction is stuck in the mempool, two primary fee bumping techniques can accelerate confirmation:

Replace-by-Fee (RBF)

RBF replaces an unconfirmed transaction with a new version paying a higher fee. The replacement transaction spends at least one of the same inputs, effectively invalidating the original.

Originally defined as opt-in via BIP 125 (where the sender signals replaceability by setting an input's nSequence below 0xfffffffe), full RBF became mandatory in Bitcoin Core 29.0 (April 2025). Any unconfirmed transaction can now be replaced regardless of signaling.

# Bump fee on an existing unconfirmed transaction
bitcoin-cli bumpfee <txid>

# Or manually create a replacement with higher fee
bitcoin-cli createrawtransaction '[{"txid":"<txid>","vout":0}]' '{"<address>":0.01}'
# Sign and broadcast the replacement

The replacement must pay a higher absolute fee than all transactions it displaces and must cover its own relay cost. The number of evicted original transactions (plus descendants) cannot exceed 100.

Child Pays for Parent (CPFP)

CPFP takes a different approach: instead of replacing the stuck transaction, the recipient (or sender via a change output) creates a new child transaction spending one of its outputs with a high fee rate. Because Bitcoin consensus requires a parent to appear before its child in the blockchain, miners must include both transactions to collect the child's fee.

Miners evaluate the ancestor fee rate of the child: the combined fee divided by the combined virtual size of the child and all its unconfirmed ancestors. This has been supported in Bitcoin Core's mining algorithm since version 0.13.

RBF vs. CPFP

Zero-Confirmation (0-conf) Acceptance

Zero-confirmation acceptance means treating a transaction as valid before it receives any block confirmations. The transaction is visible in the mempool almost instantly after broadcast, making it attractive for merchants who want a fast checkout experience.

However, 0-conf carries inherent double-spend risk:

• Race attack: the attacker broadcasts two conflicting transactions simultaneously, hoping the fraudulent one reaches miners first
• Finney attack: a miner pre-mines a block containing a conflicting transaction, spends the same UTXO at a merchant, then releases the pre-mined block

With full RBF now mandatory, any unconfirmed transaction can be replaced at any time, making 0-conf acceptance riskier than ever. For small, in-person transactions where the cost of attack exceeds the transaction value, the risk may be acceptable. For larger amounts, online purchases, or irreversible services, waiting for at least one confirmation is strongly recommended.

Why It Matters

Unconfirmed transactions represent a fundamental limitation of Bitcoin's base layer: probabilistic settlement with variable confirmation times. For payments, this creates friction. Merchants must choose between accepting double-spend risk (0-conf) or imposing multi-minute waits (1+ confirmations).

This tradeoff drives demand for Layer 2 solutions that provide instant finality. Spark, for example, enables self-custodial Bitcoin and stablecoin transfers that settle instantly without waiting for on-chain confirmations. Users get the security of Bitcoin's base layer with the speed needed for everyday payments. The Lightning Network similarly offers near-instant settlement through off-chain payment channels, though with different tradeoffs around channel management and liquidity.

Understanding fee estimation and mempool dynamics is critical for anyone sending on-chain Bitcoin transactions. Overpaying wastes money; underpaying risks hours-long delays or transaction expiry. For a deeper look at how fees affect on-chain economics, see the Bitcoin fee market dynamics research article.

Risks and Considerations

Confirmation Delays

During periods of high demand, the mempool can swell beyond 300 MB, causing the lowest fee-rate transactions to be evicted. A transaction paying 2 sat/vB might confirm in minutes during low demand but remain stuck for days during a fee spike. If the transaction is not confirmed within 14 days (the default expiry), nodes drop it from their mempools entirely.

Double-Spend Window

Every unconfirmed transaction carries a theoretical double-spend risk until it receives its first confirmation. With full RBF mandatory across the network, any unconfirmed transaction can be replaced by a conflicting one paying a higher fee. This is by design: it allows legitimate fee bumping but also enables deliberate double-spending of unconfirmed transactions.

Cascading Dependencies

Spending the output of an unconfirmed transaction creates a chain of unconfirmed transactions. If the parent is replaced or dropped, all descendants become invalid. The cluster mempool in Bitcoin Core 31.0 enforces cluster limits (64 transactions, 101 kB) to prevent excessively long chains from degrading node performance.

Wallet UX Challenges

Wallets must carefully communicate the difference between broadcast and confirmed. Users often assume a broadcast transaction is final, leading to confusion when a stuck transaction eventually expires or is replaced. Good fee estimation at the time of broadcast is the best defense against confirmation delays, but it cannot fully account for sudden demand spikes.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.