The Life of a Transaction

1.1 What happens after you click "Confirm"

Mint had sent dozens of transactions by now. Click send, wait a bit, see "confirmed." But one afternoon a transaction sat on "pending" for twenty minutes, and Mint realised there was a whole process happening behind that word that Mint knew nothing about.

"Where does my transaction go while it's pending?" Mint asked.

"On a journey," said Hash. "And once you understand the journey, you'll understand fees, stuck transactions, MEV, Layer 2s, and most of the frustrations people have with crypto."

Module 1 explained what a blockchain is. Module 2 explained how to hold keys safely. This module explains how blockchains actually process your transactions, and why that matters for every trade you make. This first chapter gives the full journey in one view. Each later chapter zooms into one stage.

1.2 The seven stages

Here's the life of a typical transaction, using Ethereum as the main example. Bitcoin follows the same broad shape, with differences we'll cover in Chapter 3.

Stage	What happens	Covered in
1. Create	Your wallet builds the transaction: recipient, amount, data, fee settings	Chapter 2
2. Sign	Your private key signs it, proving you authorised it	Module 2
3. Broadcast	Your wallet sends it to a node, which shares it with other nodes	This chapter
4. Wait in the mempool	The transaction waits with other pending transactions	Chapter 4
5. Get included	A block producer selects it and puts it in a block	Chapters 2 and 11
6. Confirm	The block is added to the chain, and more blocks build on top	Chapter 5
7. Finalise	The transaction becomes practically irreversible	Chapter 5

Chapter 1 · The life of a transaction

A transaction is created with a nonce, gas, and chain ID, then signed, then broadcast to the mempool. A block includes it, after which confirmations accumulate toward finality. Inclusion in a block does not guarantee success; a transaction can be included but fail.

1.3 Stage 1: creating the transaction

When Mint sends 0.1 ETH to Node, the wallet prepares a transaction containing several fields. The important ones are:

Field	What it means
From	Mint's address (proven by the signature)
To	Node's address, or a smart contract address
Value	The amount of ETH being sent, here 0.1 ETH
Data	Instructions for a smart contract, such as "swap these tokens." Empty for a simple ETH transfer
Gas limit	The maximum amount of computation Mint allows the transaction to use
Fee settings	How much Mint is willing to pay per unit of gas
Nonce	A per-account counter that starts at zero. A nonce of 47, for example, means Mint has already sent 47 transactions, so this is the next one. Keeps transactions in order
Chain ID	Which network this transaction is for, so it can't be replayed on another network

Most of these are filled in automatically by the wallet. But knowing they exist explains a lot. The gas fields explain fees. The nonce explains stuck transactions. The chain ID explains why a transaction signed for one network can't simply be copied to another.

1.4 Stages 2 and 3: signing and broadcasting

As Module 2 explained, the wallet signs the transaction with Mint's private key. Then it broadcasts the signed transaction by sending it to a node, usually one run by the wallet provider or an infrastructure company, through an RPC endpoint (Module 2, Chapter 9).

That node checks the transaction is valid: the signature matches, Mint has enough ETH for the value and fees, and the nonce is correct. If it passes, the node passes it on to its peers, who pass it on to theirs. Within seconds, the transaction has spread across much of the network. This peer-to-peer sharing is sometimes called gossip.

"So there's no central server receiving it?" Mint asked.

"No single one," said Hash. "Your wallet just needs to reach one honest node. The network does the rest."

1.5 Stage 4: the waiting room

Every node keeps a list of valid transactions that haven't yet been included in a block. This list is called the mempool, short for memory pool. Think of it as a waiting room.

There isn't one global mempool. Each node has its own, and they're mostly similar but not identical. Some transactions also skip the public mempool entirely and are sent privately to block producers, for reasons Chapter 11 explains.

How long a transaction waits depends mostly on how much it's willing to pay compared with everyone else in the waiting room. That's Chapters 2 and 4.

1.6 Stage 5: getting into a block

On Ethereum, a new block is produced every 12 seconds. For each block, one validator is chosen to propose it. In practice, most validators receive ready-made blocks from specialised block builders, who assemble transactions in the order that earns the most fees and other value.

Blocks have a capacity limit, measured in gas. When more transactions want in than a block can hold, the ones paying more generally get in first. Some never get in at all if their fees are too low, and they keep waiting.

When Mint's transaction is included, the Ethereum Virtual Machine executes it. For a simple transfer, that's straightforward: subtract 0.1 ETH and fees from Mint, add 0.1 ETH to Node. For a smart contract interaction, it runs the contract's code.

A transaction can be included and still fail. For example, a swap might fail because the price moved beyond Mint's slippage tolerance (Module 1, Chapter 8). A failed transaction is still recorded in the block, and Mint still pays for the gas used up to the point of failure, because validators did the work.

"I pay even when it fails?" said Mint.

"You paid for the computation, not the result," said Hash. "Like paying a mechanic for diagnosis even if they can't fix the car."

1.7 Stages 6 and 7: confirmation and finality

Once a block containing Mint's transaction is added to the chain, the transaction has one confirmation. Each new block built on top adds another confirmation, making the transaction harder to reverse.

Eventually, the transaction reaches finality: the point where reversing it would be practically impossible or extraordinarily costly. On Ethereum, that typically takes around 13 minutes. On Bitcoin, people commonly wait for about six confirmations, roughly an hour, for large amounts. Chapter 5 explains why these differ.

This is why exchanges sometimes credit a deposit only after a certain number of confirmations. They're waiting for the transaction to be safe from reversal.

1.8 Watching it happen

Node, ever the practical one, asked: "Can I see all of this?"

"Most of it," said Hash. "Paste your transaction hash into a block explorer."

A transaction hash is a unique identifier for your transaction, generated when you sign it. You can find it in your wallet's activity history. On a block explorer, the hash shows you the status (pending, successful, or failed), the block it was included in, the fee paid, and every detail of what happened. Chapter 6 is a full guide to reading block explorers.

1.9 The same journey everywhere

The details differ across blockchains: block times, fee systems, and how finality works. But almost every blockchain follows the same broad pattern: create, sign, broadcast, wait, include, confirm, finalise. Once you know this pattern, learning a new blockchain becomes much easier. You just ask how it handles each stage.

1.10 Try it yourself

Using your testnet wallet from Module 2, send a small amount of test ETH between two of your accounts. As soon as you confirm, copy the transaction hash from your wallet and open it on a testnet block explorer. Refresh the page and watch it move from pending to success. Note the block number, the gas used, and the fee.

Then send another transaction and deliberately set a very low fee, if your wallet allows custom fees. Watch how long it waits compared with the first.

Key takeaways from this chapter

1. Every transaction goes through seven stages: create, sign, broadcast, wait in the mempool, get included, confirm, and finalise.
2. A transaction includes fields like recipient, value, data, gas limit, fee settings, nonce, and chain ID.
3. Signed transactions spread across the network from node to node through gossip.
4. Pending transactions wait in mempools, and each node has its own.
5. Block producers generally include higher-paying transactions first when blocks are full.
6. A transaction can be included but fail, and you still pay for the gas used.
7. Confirmations accumulate as new blocks are added, until the transaction reaches finality.