Every action on Ethereum — every swap, every mint, every stake — is a transaction that travels the same path: signed by your wallet, broadcast to the network, picked up by a validator, included in a block, and eventually reaching finality. Understanding the whole path — and where things can go right or wrong at each stage — is what turns "transactions are magic" into "transactions are a series of comprehensible steps."
Step 1: Construction
Everything starts in your wallet. When you click "Swap 1 ETH for USDC" on Uniswap, your wallet:
1. Constructs a transaction object with the destination address (Uniswap router), the calldata (encoded call to the swap function), and value (0 ETH, since the swap function moves ETH via calldata parameters). 2. Sets gas parameters: gasLimit (how much gas you're willing to burn maximum), maxFeePerGas (the ceiling), maxPriorityFeePerGas (the tip). 3. Sets the nonce (the sequential number of transactions from your address — must be exactly one higher than your last).
The wallet shows you a summary and asks for confirmation. What you're really approving is: "I authorize this specific calldata to be executed from my address."
Step 2: Signature
You approve. Your wallet signs the transaction with your private key. The result is a signed transaction — the original data plus a signature that any node can verify against your public key.
For a hardware wallet (Ledger, Trezor), the signing happens on the device itself. The private key never leaves. The device shows you the transaction on its screen and signs only after you confirm. This is why hardware wallets are more secure — even a compromised computer can't extract the key.
For a software wallet (MetaMask), the key is decrypted with your password, used to sign, then re-encrypted. Malware on your computer could intercept this. This is the tradeoff for using a hot wallet.
Step 3: Broadcast to the mempool
Your wallet sends the signed transaction to a node. Usually this is your wallet provider's RPC endpoint (MetaMask uses Infura by default, or your configured RPC).
The node validates the transaction: signature is valid, sender has enough ETH to cover gas, nonce is correct, gas limit isn't insane. If everything checks out, the node adds the transaction to its mempool — a pool of unconfirmed transactions.
The node also gossips the transaction to its peers, who validate independently and add it to their own mempools. Within a few seconds, most nodes on the network have the transaction.
This is where things become public. Anyone watching the mempool (arbitrage bots, MEV searchers, sandwich attackers) sees your transaction. They can now decide whether to react.
Step 4: Mempool competition
Your transaction sits in the mempool waiting to be included in a block. Validators pick transactions to include based on which will pay them the most (highest priority fee first). If your gas price is competitive, you'll be included in the next block. If not, you'll wait.
Modern wallets estimate a competitive gas price for you. But the mempool state changes constantly:
- New transactions come in that outbid you.
- Big gas users (NFT mints, MEV) suddenly appear.
- The base fee shifts.
If your priority fee is too low, you might wait many blocks or forever. The mempool can also purge low-fee transactions if it overflows during busy periods.
If you underpaid, you have options:
- **Replace-by-Fee (RBF)**: re-sign the same nonce with a higher gas price. Wallets support this as a "speed up" button.
- **Cancel**: re-sign the same nonce as a zero-value transfer to yourself with higher gas. Cancels the original by taking its nonce.
- **Wait**: if you're not in a hurry, the base fee usually drops and your transaction eventually goes through.
Step 5: Block inclusion
A validator (currently one of ~1M active Ethereum validators, selected pseudo-randomly per slot) is chosen to propose the next block. They gather transactions from the mempool, prioritize by fee, and construct a block.
On Ethereum post-Merge, most validators use MEV-Boost to receive pre-built blocks from block builders. The validator picks the highest-paying block bid and signs off on it.
Your transaction is now in a proposed block. But that block isn't final yet — it needs to be verified and voted on by other validators.
Step 6: Attestation and finality
Ethereum has two finality mechanisms:
**Attestation**: within seconds of a block being proposed, other validators attest to whether the block is valid. Enough attestations means the block is confirmed on the beacon chain.
**Justification and finality**: on a longer time scale (12-15 minutes typically), blocks become "justified" and then "finalized" via the beacon chain's consensus mechanism (Casper FFG).
For most practical purposes, your transaction is safe once it's been in a block for 12 confirmations (~144 seconds). Reversal after this would require an extremely well-coordinated attack on the validator set.
For high-value transactions (exchange deposits, large bridge transfers), waiting for actual finality (~15 minutes) is standard. Bridges and exchanges specify their required confirmations.
Step 7: State change
Once your transaction is included in a block, the state change happens:
- Your ETH balance decreases by (gas_used * gas_price).
- Any state changes from the transaction (token transfers, contract calls) take effect.
- Events are emitted (Transfer, Approval, Swap, etc.) that off-chain systems watch for.
For a token swap, your token balances update. For a contract deployment, the new contract now exists at its address. For a governance vote, your voting weight is recorded.
What can go wrong
Various failure modes at each step:
**Signing errors**: rare in modern wallets but possible with custom RPCs or badly-configured wallets. If a signature is invalid, no node will accept the transaction.
**Broadcast failures**: RPC provider is down, network partition. Wallet usually shows an error and lets you retry.
**Mempool eviction**: your low-fee transaction gets pushed out of mempools by higher-fee transactions during congestion. You might need to re-broadcast or RBF.
**Reverts**: the transaction is included in a block but the contract reverts (insufficient balance, slippage exceeded, unauthorized caller). You pay for the gas used up to the revert, but the state change doesn't happen. Etherscan shows revert reasons.
**Frontrunning / MEV**: your transaction is included after a searcher's front-running transaction that manipulated the state you expected. Common for large swaps on public mempools.
**Reorgs**: rare on Ethereum post-Merge but possible. A recently-confirmed block gets replaced during finalization. Your transaction may re-enter the mempool. Wait for full finality on high-value operations.
Layer 2 differences
L2s have similar lifecycles but different specifics:
- Block times are faster (Arbitrum ~250ms, Optimism ~2s, Base ~2s).
- Sequencer is a single entity (usually the L2 team) that orders transactions.
- Data eventually posts to Ethereum L1, which is where the "finality" comes from — L2 finality is typically minutes to hours after L1 confirmation.
- Fees are much lower because you're not competing for L1 block space.
The mempool dynamics are simpler on L2s because a single sequencer decides ordering. Sandwich attacks and complex MEV are less common but not zero.
The one-sentence version
An Ethereum transaction goes from your wallet → to the mempool → to a validator's block → to attestation → to finality. Each stage has its own risks and its own timing. Understanding the whole path is what lets you diagnose "why is my transaction stuck" and "why did my transaction fail" rather than guessing.
