Transaction lifecycle: send, mempool, confirm

What are the steps?

1. Send. The client signs the transaction and sends it to a node. The node returns the hash. Nothing has executed yet.
2. Pending. The transaction joins a pool of pending transactions and waits (ethereum.org).
3. Included. A block producer puts it in a block. Now it runs and changes state, or reverts.
4. Receipt. The block’s receipt records the outcome: status, gas used, effective gas price, logs.
5. Final. Over time the block becomes harder and harder to undo.

The gap between step 1 and step 4 is where most surprises live.

What can go wrong after send?

• It reverts. It’s included and pays for its gas, but nothing it tried to change sticks.
• It’s replaced. Another transaction from the same sender with the same nonce is mined instead, for example a speed-up or a cancel. viem reports this as replaced, repriced or cancelled (viem docs).
• It never lands. It sits in the pool until whoever is waiting gives up.

Why does this matter for agents?

An agent’s tool usually returns at step 1, with a hash. The trace marks the tool call as fine and moves on. Steps 2 to 4 happen outside the trace. This post walks through a real example where the tool call looks fine and the transaction reverted.