Ethereum transaction lifecycle
What actually happens after Send?
Follow a transaction from wallet broadcast through pending flow, builder/relay markets, proposer selection, and finality. The goal is a clean walkthrough backed by live network data, not another wall of protocol jargon.
Lifecycle controls
Want extraction details? Use the dedicated MEV Lab for advanced analysis, pre-vs-post PBS diagrams, and estimate methodology.
Transaction Flow
Select a step to update the explanation and data panel below.
Step 1 · Wallet send
Signing and broadcast
Your wallet creates a signed transaction and submits it to Ethereum peers. At this point the transaction is validly formed, but it is not included in a block yet.
The private key signs the transaction locally. Nodes can reject malformed, underpriced, or nonce-conflicting transactions before they spread very far.
Track any transaction hash to see whether it is still pending, included in a block, or missing from the configured execution node.
Wallet send
A wallet signs your transaction locally, then broadcasts it to peers. It is now visible to the network, but it is not included in chain history until a block proposal contains it.
Technical note: the network does not guarantee first-come-first-served ordering. Fee pressure and builder strategy strongly influence what gets included next.
Track a transaction
Enter a transaction hash (or type latest) to stitch together its journey: execution inclusion, relay context, and an approximate finality check.
Enter a hash (or "latest") and click Track.
Wrap-up: lifecycle map
- Wallet send: user signs and broadcasts a transaction.
- Mempool queue: pending transactions compete via fee pressure.
- Builders/searchers: candidate blocks are optimized and bid.
- Relays: candidate payloads are delivered to proposers.
- Validators/proposers: one proposal is published per slot.
- Finality: justified/finalized checkpoints lock history.
For extraction economics and pre-vs-post PBS context, continue in MEV Lab.