B++ 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 States

A transaction goes through several states:

1. Created → 2. Signed → 3. Broadcast → 4. Mempool → 
5. Pending → 6. Confirmed → 7. Deeply Confirmed

State Transitions

1. Created

Transaction is constructed but not signed:

Status: Created
- Inputs selected
- Outputs defined
- Fees calculated
- Not yet signed

2. Signed

Private keys sign the transaction:

Status: Signed
- All inputs signed
- Transaction valid
- Ready to broadcast
- Still local only

3. Broadcast

Transaction sent to network:

Status: Broadcast
- Sent to peer nodes
- Propagating across network
- Not yet in mempool
- May be rejected

4. Mempool

Transaction accepted by nodes:

Status: In Mempool
- Validated by nodes
- Waiting for miner selection
- Can be replaced (RBF)
- Can be dropped (low fee)

5. Pending

Transaction included in block:

Status: Pending (0 confirmations)
- Included in block
- Block not yet confirmed
- Can be reversed (reorg)
- Not yet final

6. Confirmed

Block with transaction confirmed:

Status: Confirmed (1+ confirmations)
- Block added to chain
- Increasingly secure
- Reversal very expensive
- Generally considered final

7. Deeply Confirmed

Many confirmations:

Status: Deeply Confirmed (6+ confirmations)
- Extremely secure
- Reversal practically impossible
- Standard for high-value transactions

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

For Users

  1. Be patient: Confirmations take time
  2. Check fees: Low fees = slow confirmation
  3. Verify addresses: Double-check before sending
  4. Use appropriate confirmations: 6+ for large amounts

Resources