The Life of a Transaction
Asha wants to pay Meera 4 coins for fixing her bicycle. She taps "send", and some seconds or minutes later Meera sees the payment arrive. In between, the transaction passes through the same five stages on almost every blockchain. Knowing the stages tells you where a payment can get stuck, and why "sent" is not the same as "settled".
The rule
Sign, broadcast, validate, include, confirm.
- Sign. Asha's wallet builds the transaction ("Asha pays Meera 4, fee 0.1") and signs it with her private key. The signature proves it came from her and that nobody has changed it (section 2).
- Broadcast. The wallet sends it to a few nodes, which pass it to their neighbours, which pass it on again. This gossip spreads it across the network within seconds.
- Validate. Each node checks it. Is the signature valid? Does Asha really have 4.1 coins available? Have those coins already been spent? A valid transaction waits in the node's mempool, its waiting room for pending transactions.
- Include. A block producer picks transactions from its mempool, usually preferring higher fees, and packs them into a new block. Other nodes re-check the whole block before accepting it.
- Confirm. The block joins the chain. Every later block stacked on top adds one more confirmation and makes the transaction harder to reverse.
Two everyday operations need no new block at all. Reading, such as looking up a balance or an old payment, is free and immediate: any node answers from its own copy. Syncing a new node means downloading the blocks and checking each one, starting from the genesis block.
The shortcut
When a payment misbehaves, find the stage. Each stage has its own typical failure:
| Stage | What typically goes wrong |
|---|---|
| Sign | Wrong key, so the signature fails |
| Broadcast | Wallet offline, so nobody heard it |
| Validate | Not enough funds, or coins already spent |
| Include | Fee too low, so it waits in mempools |
| Confirm | Too few blocks on top to be confident yet |
Was it broadcast?
A block explorer, a website that reads the chain through nodes, lists the transaction as pending. So it was signed and broadcast.
The trap is treating "pending" as "paid". Until a transaction is inside a block, and ideally a few blocks deep, it is only a request.
Drills
Answer fast — trust the rule.
What is the correct order of a transaction's life?
Where does a valid transaction wait before it is put into a block?
Asha's payment has been pending for an hour while newer ones confirm. Which stage is stuck, and why?
Which operation needs no new block and no fee?
Why does each extra block on top make a transaction safer?
Remember
- Sign, broadcast, validate, include, confirm.
- Shortcut: when a payment is stuck, find the stage. Pending for a long time usually means the fee is too low.
- Trap: pending is not paid. Reading the chain is free and needs no block.