# 06 — Transaction Lifecycle and MEV You sign a transaction and submit it to the network. A spinner, then a checkmark. It feels like one step. It isn't — and the gap between how it feels and what actually happens is where a surprising amount of engineering, product design, and outright predation lives. (The app that holds your key and presents that confirm button — a **wallet** — is [[07 Wallets and Account Abstraction]]; this module stays on what the network does once a signed transaction exists.) Let's walk the path a transaction actually takes, and meet the parties watching it along the way. ## The mempool Before a transaction reaches a block, it waits in a mempool. Nodes **gossip** transactions peer-to-peer — there is no central inbox: ```text User -> node -> mempool -> block proposer -> block ``` A **block proposer** is whoever wins the right to assemble the next block — a miner in proof-of-work, a selected validator in proof-of-stake. Here's the first surprise: the mempool isn't really a place. It's more like a rumor that every node hears slightly differently — each node keeps its own view, gossips what it knows, and no two views quite agree. There's no global queue, no fairness guarantee, and no meaningful notion of "arrival order." From this fog, block proposers choose which transactions to include and in what order. It's worth rereading that sentence, because the word doing the work is *choose*. Whoever proposes the current block holds a small, perfectly legal, essentially unregulated power: the ordering pen. Under post-EIP-1559 fee rules, users pay a **base fee** (burned, adjusts with congestion) plus a **priority fee** (tip to the proposer) as a bid for inclusion. Follow that one fact and a whole ecosystem unfolds from it: - Priority fees (bidding for inclusion) - Front-running (bidding for position) - Sandwich attacks - Censorship risk - [[MEV]] ## MEV Maximal extractable value is, roughly, what the ordering pen is worth. **Front-running** is seeing a pending trade and placing your own ahead of it. The canonical **sandwich** attack: 1. A user submits a swap: buy token X. 2. A searcher spots it in the public mempool. 3. The searcher buys X first. 4. The user's trade pushes the price up. 5. The searcher sells into the higher price. A sandwich. The user paid a tax for being visible. And notice that nothing exotic was required — just two ordinary properties combining: pending transactions are public, and execution is deterministic. Anyone can simulate the future and bid to rearrange it. If you're coming from databases, here's the framing that transfers cleanly: MEV is what happens when transaction ordering — normally a scheduler's internal detail that nobody profits from — becomes a market. Put the scheduler's choices up for auction and an industry appears. It industrialized into a supply chain: - **Searchers** — find profitable ordering opportunities in the mempool. - **Builders** — assemble blocks that capture those opportunities. - **Proposers** — sell blockspace to the highest-bidding builder. **Proposer-builder separation (PBS)** is the protocol acknowledging this market: the proposer outsources block construction to specialist builders rather than building blocks itself, trying to contain centralizing pressure. Responses in the wild — private mempools, encrypted mempools, batch auctions, fair-ordering protocols — are covered in [[MEV]]. The pattern to notice: none of them eliminate MEV. They move who captures it, and how visibly. ## The full lifecycle Now the complete journey, from click to certainty: ```text User action -> app constructs transaction -> wallet signs -> transaction broadcast -> mempool/RPC -> block inclusion -> confirmations/finality -> indexer observes -> app updates UI ``` Here's an exercise worth doing slowly: walk each arrow and ask what fails there. - Construction: wrong chain, wrong nonce, bad gas estimate. - Signing: the user approves something they didn't understand ([[07 Wallets and Account Abstraction]]). - Broadcast: the RPC drops it — silently ([[Trust Assumptions]]). - Mempool: stuck below the fee floor; front-run; replaced. - Inclusion: reverted on execution — included *and* failed, fee paid. - Confirmations: a [[Reorgs|reorg]] removes what was already seen ([[Finality]]). - Indexing: the app's view lags behind or diverges ([[08 Nodes, RPCs, and Indexers]]). Once you've done that walk, you'll notice something products rarely acknowledge: "pending" isn't one state. It's closer to seven, each with its own failure mode and its own honest answer to a user asking "where is my money?" Products built by people who know this can tell users the truth at each stage. Most can't, because nobody on the team ever walked the arrows. ## Learning outcomes Questions worth trying on: - Could you narrate a transaction's full journey, naming what can fail at every hop? - Could you explain a sandwich attack to a product manager in one minute — including what "just use a private mempool" trades away? - Deterministic execution is usually a virtue. Could you explain why it also makes front-running *easier*? (There's a nice irony in there worth articulating.) - A user reports "my transaction disappeared." Could you list, in order, the places you'd look? - And the thread to pull forward: this whole journey began with a signature. Who actually holds that key, where does it live, and what happens when it's lost? ## Checkpoint 1. Why is there no such thing as "the" mempool, and what does that imply about anyone claiming a transaction was "seen first"? *(If unsure, revisit "The mempool".)* 2. Included-but-reverted versus never-included: how does each look to a user, and to an indexer? *(If unsure, revisit "The full lifecycle".)* 3. Searcher, builder, proposer — who sells what to whom? *(Hint: searchers find MEV, builders package blocks, proposers sell blockspace to builders. If unsure, see "MEV" and [[MEV]].)* **Exercise.** On a testnet: submit a transaction with a deliberately low fee and watch it languish. **Replace** it (same nonce, higher fee — a valid transaction with the same nonce supersedes the pending one). Then submit one that will revert on execution. Follow all three through a block explorer, noting every state each one passes through. An hour of this teaches the lifecycle better than any diagram. ## Resources - **Ethereum.org docs: Transactions, Gas** — the mechanics of fees, nonces, and replacement. - **Flashbots documentation and writings** — the definitive material on MEV's ecosystem and PBS; their "MEV supply chain" framing is the one to internalize. - **DeFi MOOC, MEV lecture** — a structured academic treatment. --- Next: every transaction begins with a signature. Where do keys actually live, and who is allowed to hold them? → [[07 Wallets and Account Abstraction]]