Transaction Lifecycle: From Mempool to Block

Send a payment through a bank and it settles the moment the bank's ledger updates — you never see the queue. Send crypto and you see every stage: your transaction sits in public view, waiting, before anyone agrees it happened. That waiting room is the mempool, and what happens between it and a finished block is the actual mechanics of "sending money" on a blockchain.

The queue everyone can see

When you sign a transaction and broadcast it, it propagates node to node across the network and lands in each node's mempool (memory pool) — a local, unconfirmed holding area. It is not one shared queue; every node keeps its own view, though in practice they converge quickly. Crucially, the mempool is public: anyone running a node can see your transaction, your fee, and often what it's trying to do, before it's confirmed.

Who picks your transaction, and why

Block space is limited, so whoever assembles the next block — a miner under proof-of-work, a validator (often via a specialized builder) under proof-of-stake — has to choose which pending transactions to include. The dominant selection rule is simple: rank by fee per unit of block space and take the highest payers first, because that's what maximizes the builder's revenue. This is why a transaction sent with a low fee during a busy period can sit in the mempool for hours while an identical one with a higher fee confirms in the very next block.

Worked example

Two users broadcast transfers at the same moment. User A attaches a fee that works out to 8 gwei per unit of gas; user B attaches 40 gwei. The next block has room for roughly 60% of pending transactions by weight. The builder sorts the mempool by fee density and fills the block from the top: B's transaction, paying five times more per unit of space, is included in that block. A's transaction is left behind, re-evaluated against the next block's queue — where, if network congestion has eased and average fees have dropped, it may finally clear, or if congestion is rising, it may need to be resubmitted with a higher fee (a "fee bump") to avoid an indefinite wait.

What this means in practice

Inclusion in a block is not the finish line. Blocks can occasionally be reorganized — a competing block wins out and displaces the one that briefly held your transaction — so exchanges and clearing systems wait for a number of confirmations (later blocks built on top) before treating a transaction as settled, with the required depth scaling with the value at risk. The mempool's public visibility also has a dark side: because a pending transaction's intent is visible before it's final, block builders and searchers can insert their own transactions around it, extracting value from information the sender never intended to publish.