BR Academy
Intro to Blockchain: How It Works and Why It Matters
0%
Exit course
Transactions and Fees·Lesson 14 of 25·12 min

From Broadcast to Confirmation

The Concept

A signed transaction doesn't go straight into a block the instant it's created. It passes through a predictable sequence of stages, and understanding each one explains both why transactions sometimes take a few minutes to "settle" and why different situations call for waiting different amounts of time before treating a payment as final.

  1. Signed — the sender's wallet produces the signature covered in the previous lesson. The transaction now exists but no one else has seen it yet.
  2. Broadcast — the wallet sends the signed transaction out to the peer-to-peer network. It propagates node to node within seconds.
  3. Mempool — each node that receives it checks that it's valid (correct signature, sufficient balance, a nonce that makes sense) and, if so, holds it in its mempool — literally "memory pool," a waiting room of pending transactions that haven't been included in a block yet. At this stage the transaction shows as "pending."
  4. Included in a block — a block producer (a miner under Proof of Work, a validator under Proof of Stake — Module 5) selects transactions from the mempool, often prioritizing higher fees, and bundles them into a new block.
  5. Confirmations — once that block is accepted by the network, the transaction has 1 confirmation. Every subsequent block built on top adds one more confirmation, and each additional confirmation makes the transaction progressively harder to reverse, because undoing it would now require rewriting multiple blocks' worth of cryptographic linking (Module 2), not just one.

The practical upshot: "pending" means still in the mempool, not yet decided; "1 confirmation" means included but still relatively easy (in principle) to reverse in a worst-case scenario; "many confirmations" means settled in practice.

It's worth understanding what can go wrong at the mempool stage specifically, since that's the only point in the lifecycle where a transaction's outcome is genuinely uncertain. If a sender attaches too low a fee, block producers — who are economically motivated to prioritize the highest-paying transactions first — may simply never pick it up, leaving it stuck pending indefinitely during busy periods. Most wallets let you "speed up" a stuck transaction by rebroadcasting the same nonce with a higher fee, which replaces the original in the mempool outright, since only one transaction per nonce can ever be confirmed. Separately, a transaction can also be dropped from the mempool entirely if nodes run low on memory and prune their lowest-fee pending transactions — another reason fee levels matter beyond just getting a faster confirmation.

It's also worth distinguishing "confirmed" from "final" precisely. Even a transaction with several confirmations is still, in principle, reversible if an attacker could somehow out-produce the rest of the network's combined block-building power for long enough to rewrite those blocks — the subject of the 51% attack lesson in Module 5. In practice, the computational or financial cost of doing that rises so steeply with each additional confirmation that, past a certain point (which varies by chain and by the value at stake), it is treated as settled for all practical purposes.

It helps to see why this staged design is deliberate rather than accidental. A blockchain has no central server deciding "this transaction happened" the instant someone clicks send — thousands of independent nodes around the world have to independently reach the same conclusion about the order and validity of every transaction, with no single party trusted to simply declare the answer. The mempool stage is where that independent checking happens: each node verifies the signature and balance for itself before relaying the transaction onward, so a malformed or fraudulent transaction gets quietly dropped by every honest node rather than ever reaching a block. Confirmations exist for the same underlying reason — reaching agreement across a decentralized network takes a little time and a little redundancy, and confirmations are simply that redundancy made visible and countable.

It's also worth knowing that two honest, independent block producers occasionally produce competing blocks at nearly the same moment — a temporary fork. When this happens, the two versions of the chain briefly coexist until the network converges on one, following the rule (covered precisely in Module 5) that the chain with the most accumulated work or stake wins. A transaction that was in the "losing" block isn't lost; so long as it's still valid, it simply returns to the mempool and gets picked up again in a subsequent block, sometimes delaying its first confirmation by a block or two. This is a normal, self-correcting part of how a leaderless network reaches agreement, not a malfunction.

Worked Example

Trace one transaction through all five stages using the language a real block explorer would show:

  • T+0 seconds: Wallet signs the transaction. Status: not yet visible to anyone else.
  • T+2 seconds: Broadcast completes; a public mempool-tracking site shows it as "Pending."
  • T+2 to 60 seconds: It sits in the mempool alongside thousands of others, waiting to be selected.
  • T+~60 seconds: A new block includes it. The explorer updates its status to "Confirmed — 1 confirmation," with a block number now attached.
  • T+10 minutes: Five more blocks have been added on top. The explorer now shows "6 confirmations."

A block explorer (the subject of this module's last lesson) is exactly where you'd watch this progression happen in real time for any transaction you search.

Exercise

Explain, in two or three sentences, why a merchant selling a $10 coffee might reasonably accept a transaction the moment it shows 1 confirmation, while an exchange processing a $50,000 deposit might wait for 30 or more confirmations before crediting the account. Ground your answer in what each additional confirmation actually makes harder to reverse, not just "because it's safer" — tie it to the cost and difficulty of rewriting an increasing number of linked blocks.

Recap

  • A transaction's journey runs sign → broadcast → mempool (pending) → included in a block → accumulating confirmations.
  • Each confirmation is one more block built on top, making reversal progressively more costly and less practical; a stuck low-fee transaction can usually be replaced by rebroadcasting the same nonce at a higher fee.
  • How many confirmations to wait for is a risk decision scaled to the value at stake, not a fixed universal rule.

Resources

← Anatomy of a Transaction Gas, Fees, and Mempool →