Transaction Lifecycle
Every Ethereum transaction travels through six distinct stages before becoming final. Understanding this lifecycle is essential for building reliable dApp transaction UX with proper loading states and error handling.
6 Stages of a Transaction
Stage 1: Construction
- Build tx object: to, value, data, gasLimit, maxFeePerGas, nonce
- nonce must be exactly account's current transaction count
- Estimate gas or hardcode (risky)
Stage 2: Signing
- Hash the RLP-encoded transaction with chainId (EIP-155)
- Sign hash with private key using secp256k1 → produces v, r, s
Stage 3: Broadcast
- Send raw signed transaction to node via eth_sendRawTransaction
- Node validates: signature, nonce, sufficient balance
- Returns transaction hash immediately (before confirmation)
Stage 4: Mempool (Pending)
- Transaction is in the mempool awaiting inclusion
- P2P gossip propagates to other nodes
- Validators/miners select transactions ordered by maxPriorityFeePerGas
- Can be stuck here if baseFee > maxFeePerGas
Stage 5: Inclusion (Soft Confirmation)
- Validator includes tx in a block
- 1 confirmation = block is proposed
- Transaction hash is now in a block (but can be reorged)
Stage 6: Finality (Hard Confirmation)
- Ethereum: finality after 2 epochs (~12.8 minutes, 64-96 blocks)
- For most dApps: 1-12 confirmations is sufficient
- Large financial transactions: wait for economic finalityCommon Mistakes
- Treating 'transaction sent' as 'transaction confirmed' - the hash is available immediately after broadcast, but the tx may take 12+ seconds to confirm and can still revert
- Not handling receipt.status === 0 - a receipt means the tx was included but status 0 means it REVERTED. Always check status before declaring success.
- Nonce management in high-throughput systems - if you send multiple txs simultaneously from the same EOA, you must manually manage nonces. Two txs with same nonce = only one included.
- Forgetting about L2 finality differences - Arbitrum/Optimism transactions confirm quickly (seconds) but achieve Ethereum finality after 7 days (optimistic rollup fraud proof window).
Tip
Tip
Practice Transaction Lifecycle in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Once deployed, smart contracts are immutable - code is law
Practice Task
Note
Practice Task - (1) Write a working example of Transaction Lifecycle from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with Transaction Lifecycle is skipping edge case testing - empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready web3 code.
Key Takeaways
- Every Ethereum transaction travels through six distinct stages before becoming final.
- Treating 'transaction sent' as 'transaction confirmed' - the hash is available immediately after broadcast, but the tx may take 12+ seconds to confirm and can still revert
- Not handling receipt.status === 0 - a receipt means the tx was included but status 0 means it REVERTED. Always check status before declaring success.
- Nonce management in high-throughput systems - if you send multiple txs simultaneously from the same EOA, you must manually manage nonces. Two txs with same nonce = only one included.