BitcoinDev Logo
Feedback

Transaction Lifecycle

Understanding the complete lifecycle of a Bitcoin transaction helps developers build robust applications and users understand what happens when they send bitcoin.

Transaction Structure

A Bitcoin transaction consists of:

  • Version: Identifies consensus rules
  • Inputs: References to previous transaction outputs (UTXOs)
  • Outputs: Creates new UTXOs with spending conditions
  • Locktime: Optional time-based spending restriction
  • Witness Data (SegWit): Signature data separated from transaction

For detailed transaction construction, see Transaction Construction.

Transaction States

A transaction goes through several states:

StateDescription
1. CreatedInputs selected, outputs defined, fees set—not yet signed.
2. SignedAll inputs signed; valid and ready to broadcast, still local only.
3. BroadcastSent to peers, propagating; not in mempool yet, may be rejected.
4. MempoolValidated by nodes, waiting for inclusion; replaceable (RBF) or droppable (low fee).
5. PendingIn a block with 0 confirmations; reversible by reorg, not final.
6. Confirmed1+ confirmations; on chain, increasingly secure, generally final.
7. Deeply Confirmed6+ confirmations; extremely secure, reversal practically impossible; standard for high value.

Code Examples

Tracking Transaction Status

Reorganizations (Reorgs)

A reorganization occurs when the blockchain splits and a different chain becomes the longest:

Original Chain:
Block 100 → Block 101 → Block 102

Reorg:
Block 100 → Block 101A → Block 102A (longer chain)
         → Block 101B (orphaned)

Transactions in Block 101B are now unconfirmed again

Impact

Transaction Status:
- Was: Confirmed (in block 101B)
- Now: Unconfirmed (block orphaned)
- Risk: May not re-confirm

Orphan Transactions

Definition

Orphan transactions are transactions that reference outputs that don't exist or are invalid:

Orphan Transaction:
- References UTXO that doesn't exist
- Or references unconfirmed parent
- Cannot be validated
- Dropped from mempool

Handling

1. Transaction references unconfirmed parent
2. Parent confirms → Orphan becomes valid
3. Orphan can now be included in block

Best Practices for Developers

  1. Wait for confirmations: Don't trust 0-conf for high value
  2. Handle reorgs: Transactions can be unconfirmed again
  3. Monitor status: Track transaction through lifecycle
  4. Use RBF: Allow fee bumping for stuck transactions

Resources