Skip to main content

Unconfirmed Transaction | Bitcoin Glossary | Mapping Bitcoin

Unconfirmed Transaction

Protocolo

Also known as: pending transaction, 0-conf transaction

A Bitcoin transaction that has been broadcast to the network and is sitting in the mempool but has not yet been included in a mined block. Unconfirmed transactions have no guarantee of being finalized and can potentially be replaced or dropped.

Overview

An unconfirmed transaction is a valid Bitcoin transaction that has been broadcast to the network and accepted into the mempool of nodes but has not yet been included in a mined block. Until a transaction receives at least one confirmation, it exists in a liminal state — validated by nodes but not yet permanently recorded on the blockchain.

Lifecycle of an Unconfirmed Transaction

Transaction Created
       |
  Signed by wallet
       |
  Broadcast to peers
       |
  ┌──────────────────────┐
  │     MEMPOOL           │  <-- Unconfirmed state
  │  (waiting for miner)  │
  │                       │
  │  Can be:              │
  │  - Mined (confirmed)  │
  │  - Replaced (RBF)     │
  │  - Dropped (expired)  │
  └──────────────────────┘
       |
  Included in a block
       |
  1 confirmation (and counting)

Why Transactions Stay Unconfirmed

Several factors can cause a transaction to remain unconfirmed:

  • Low fee rate: If the transaction fee is too low relative to current demand, miners may not prioritize it.
  • Mempool congestion: During periods of high activity, the mempool fills up and lower-fee transactions may wait hours or days.
  • Dependent on another unconfirmed transaction: A child transaction cannot confirm until its parent confirms (though CPFP can help).
  • Non-standard transaction: Transactions that do not conform to node relay policies may not propagate widely.

Risks of Accepting Unconfirmed Transactions

Accepting payment based on an unconfirmed transaction carries risk because:

  • The sender can broadcast a conflicting transaction (a double-spend) that pays themselves instead.
  • With Replace-by-Fee (RBF), the sender can explicitly replace the original transaction with one that has a higher fee and different outputs.
  • During mempool purges, low-fee transactions may be dropped entirely.

Remedies for Stuck Transactions

  • RBF (Replace-by-Fee): The sender broadcasts a replacement transaction with a higher fee.
  • CPFP (Child-Pays-for-Parent): The recipient creates a child transaction with a high fee that incentivizes miners to confirm both the parent and child together.
  • Waiting: If the transaction eventually falls out of all mempools, the original UTXOs become spendable again.

For low-value, in-person payments, some merchants accept unconfirmed transactions as zero-confirmation transactions when the double-spend risk is considered acceptable.