From your wallet to a block: the journey of a transaction

The spinner you've never looked behind

Picture Alice sending Bob 1 ETH from her phone. She types the amount, taps Send, and the wallet shows Pending… with a spinner. Forty seconds later it flips to Confirmed. To Alice it feels like one event. It is actually a small journey through a global, leaderless network — no bank routes the payment, no server holds the queue. In the last four guides you dissected the block and the transaction, and learned the two ways a ledger records money (UTXOs and accounts). This guide ties the rung together by following one transaction from Alice's wallet all the way into a confirmed block.

We'll break the trip into seven stops: build, sign, broadcast, gossip, wait, include, confirm. Each stop is a real, separate mechanism, and knowing them is the difference between staring at a stuck spinner in confusion and knowing exactly which stop your money is parked at.

Stops 1–4: build, sign, and let it loose on the network

First the wallet builds the transaction object: who pays, who receives, how much, and the bookkeeping fields you met last time — the nonce (Alice's personal transaction counter, here her 7th, so nonce 6) and the fee fields. Then it signs: the wallet hashes the transaction and produces a digital signature with Alice's private key. The signature is the authorization; no password is ever sent.

{
  "type": "0x2",                  // EIP-1559 ("type-2") transaction
  "chainId": 1,                   // 1 = Ethereum mainnet
  "nonce": 6,                     // Alice's 7th transaction
  "to":   "0xBob...",
  "value": "1 ETH",
  "gasLimit": 21000,              // a plain ETH transfer costs exactly this
  "maxPriorityFeePerGas": "2 gwei",   // the tip Alice offers the proposer
  "maxFeePerGas":         "40 gwei"   // the most she'll pay per gas, total
}

Next it broadcasts. The wallet doesn't email a bank; it hands the signed blob to a node — usually the RPC endpoint behind your wallet — via a JSON-RPC call. That node is Alice's on-ramp to the network. It checks the transaction is well-formed and the signature is valid, then does the magical part: it tells its neighbours.

{
  "jsonrpc": "2.0",
  "method": "eth_sendRawTransaction",
  "params": ["0x02f86b0106847735940084773594008252089..."],
  "id": 1
}

Now the fourth stop, gossip. Nodes form a peer-to-peer network: each one is connected to a few dozen others, with no central hub. When a node hears a valid new transaction it hasn't seen, it forwards it to its peers, who forward it to theirs. This flooding — called transaction propagation — reaches most of the network within one to two seconds. There was no master list; the transaction simply spread, like a rumour, until nearly everyone knew it.

Stop 5: the mempool, a waiting room with no fixed seats

Alice's transaction is now valid and known, but not yet in the ledger. It sits in the mempool (memory pool): the set of transactions each node is holding, signed and waiting to be put into a block. This is the Pending state your wallet shows.

Here's the first surprise that trips people up: there is no single, official mempool. Each node keeps its own pool of what it happens to have heard, so the contents differ slightly from node to node. There's no global queue and no guaranteed ordering — the mempool is a churning, per-node set, not an orderly line. This shifting, competitive behaviour is what people mean by mempool dynamics.

A pool isn't infinite, so nodes prioritise by fee and evict the cheapest transactions when full. A transaction can therefore sit for seconds, for hours, or — if its fee is too low — be quietly dropped and never included at all. The mempool is a waiting room, not a promise.

Stop 6 (part 1): the fee market decides who goes first

A block has a finite gas limit — on Ethereum, about 30 million gas of room, with the protocol targeting 15 million. A plain transfer uses 21,000 gas, so very roughly a thousand-odd simple transfers fit in one block. When the mempool holds more than fits, it becomes an auction, and the price you pay is the gas fee.

Since EIP-1559 (2021), Ethereum's fee has two parts. The base fee is set by the protocol, not by you: it rises when blocks are fuller than target and falls when they're emptier, and — crucially — it is burned (destroyed), so paying it doesn't bribe anyone. On top, you add a priority fee, a tip that goes to the block producer. The tip is your bid for speed.

gas_used         = 21,000 gas      # a plain ETH transfer
base_fee         = 20 gwei / gas   # set by the protocol, BURNED
priority_fee     = 2 gwei / gas    # Alice's tip, goes to the proposer

effective_price  = base_fee + priority_fee = 22 gwei / gas
total_fee        = 21,000 * 22 gwei = 462,000 gwei = 0.000462 ETH
                   |__ burned : 21,000 * 20 = 420,000 gwei
                   |__ tip    : 21,000 *  2 =  42,000 gwei  -> proposer

# maxFeePerGas = 40 gwei was just a ceiling. Base fee was only 20,
# so Alice pays 22 and the unused headroom is NOT charged.

Two numbers in the transaction control all of this. `maxFeePerGas` (40 gwei) is the ceiling — the most Alice will ever pay per gas; if the base fee ever climbs above it, her transaction simply waits. `maxPriorityFeePerGas` (2 gwei) is her tip. Because the base fee was only 20, she pays 22 and the extra headroom up to 40 is not charged. Bid a higher tip and a rational producer picks you sooner; bid too low and you wait — or get evicted.

Stop 6 (part 2): a proposer packs the block

Roughly every 12 seconds, one validator is chosen as the block proposer for that slot (this is proof-of-stake — the next rung is all about it). Its job: assemble the next block. A profit-maximising proposer sorts the mempool by tip-per-gas and greedily fills the block with the most lucrative transactions until the gas limit is reached. Alice's 2 gwei tip puts her comfortably in the next block; a 0.01 gwei tip might wait through many.

1. Select: from its mempool, the proposer takes valid transactions, ordered by tip (highest first), skipping any whose nonce isn't next-in-line for that sender.
2. Execute: it runs each transaction against the current world state — debiting Alice 1 ETH plus fee, crediting Bob — and computes the resulting state root.
3. Seal: it packs the chosen transactions into the block body, fills the header (previous-block hash, state root, timestamp), and broadcasts the new block to the network.
4. Verify: every other node re-executes the same transactions, checks the result matches, and — if so — adopts the block as the new chain tip.

Stop 7: confirmed, then confirmed harder — and finally final

The moment Alice's transaction lands in a block, the wallet flips to Confirmed — that's one confirmation. But here is the second surprise: one confirmation is not certainty. The chain can briefly disagree on its newest block (two proposers, network lag), and a competing block can win, causing a short reorg (reorganization) that drops the loser's transactions back into the mempool.

That's why people wait for confirmations: each new block built on top of Alice's makes reversing hers exponentially harder, because an attacker would have to out-build the honest network from that depth. This is probabilistic safety — more blocks on top, more confidence. Bitcoin's folk rule of *6 confirmations* (~1 hour) is exactly this idea.

Modern proof-of-stake adds something stronger: finality. On Ethereum, validators vote on checkpoints, and after about two epochs (~13 minutes) Alice's block becomes finalized — reversing it would require an attacker to destroy at least one-third of all staked ETH, billions of dollars, deliberately burned. That's not 'very unlikely'; it's economically suicidal. Probabilistic confirmations say probably won't revert; finality says can't revert without catastrophic, provable self-punishment. The proof-of-stake rung will build this out in full.

When the spinner won't stop: stuck and replaced transactions

Now you can diagnose the most common failure. Alice's transaction is Pending for ten minutes. Why? Almost always: the base fee rose above her `maxFeePerGas`, or her tip was below what proposers are taking, so no one picks her. She has three honest options.

1. Speed up (replace): re-broadcast a new transaction with the SAME nonce (6) but a higher fee. Whichever version a proposer includes, the other becomes invalid — you can't spend nonce 6 twice. This is replace-by-fee.
2. Cancel: send a 0 ETH transaction to yourself, again with nonce 6 and a higher fee. If it's included first, it consumes the nonce and the original payment can never land.
3. Wait: if the fee spike was temporary, the base fee falls within a few blocks and the original transaction gets picked up on its own. Patience is free.

That's the whole journey: Alice built and signed a transaction, broadcast it to one node, watched it gossip across the peer-to-peer network, wait in the mempool, get included by a fee-paying auction, and then confirm — first probabilistically, then with true finality. A bank did none of this; a few thousand strangers' computers, following the same rules, did all of it. Next rung, we open up exactly how those computers agree on which block wins — consensus and proof-of-stake.