The Mempool & How Ordering Is Auctioned

Lesson 1 told you what MEV is: value a block producer can extract by choosing the order transactions land in. This lesson is about the machinery that makes that extraction possible — and turns it into a live, money-burning auction. Two questions answer almost everything: where do pending transactions wait? and who decides their order, and how do they decide?

The answer to the first is the mempool. The answer to the second is whoever bids the most — because, it turns out, the right to order transactions is a product, and there’s an open market for it.

Quick instinct check before we open the hood.

The mempool: a transparent waiting room

Analogy. Picture a restaurant where every order ticket is pinned to a giant glass wall the moment a customer places it — before the kitchen has cooked anything. Any passer-by can read every ticket: who ordered what, and how big a tip they promised. The kitchen will eventually cook some of them, in whatever sequence it likes. The mempool is that glass wall. It’s a public to-do list anyone can read, and the cooking hasn’t started yet.

Definition. The mempool (memory pool) is the set of transactions that have been broadcast to the network but not yet included in a block. When your wallet signs and sends a transaction, it doesn’t go straight to a block — it’s gossiped peer-to-peer from node to node, and each node holds it in a local pool of pending transactions until some block producer picks it up. The “mempool” is loosely the union of all those local pools: every transaction that’s been announced but not yet confirmed.

Three properties make it the engine room of MEV:

• It’s public. A standard transaction in the public mempool is plaintext. Its sender, target contract, calldata (so, what it does — which pool it swaps in, how much, at what slippage), and its fees are all readable by anyone running a node. There is no privacy by default.
• It propagates with latency. Transactions don’t appear everywhere at once; they ripple outward across the peer-to-peer network over tens to hundreds of milliseconds. Being well-connected (seeing transactions a beat earlier than rivals) is itself an edge.
• Its visibility is the raw material for MEV. Because a searcher can see your pending swap before it executes, they can construct a response — a front-run, a back-run, a sandwich — and try to get it ordered favourably around yours. No public mempool, no easy MEV. (Hold that thought; it’s the whole motivation for the private-orderflow story later.)

When it matters

The mempool’s transparency matters most the instant you submit anything exploitable on sight — a large swap with loose slippage, an arbitrage you spotted, a liquidation you want to claim. By broadcasting publicly, you’ve told every searcher exactly what you’re about to do, and handed them the time window to react. That single fact is why “where pending transactions wait” is not a boring plumbing detail — it’s the front door MEV walks through.

How a builder picks and orders: maximize the block’s revenue

Analogy. The kitchen reading that glass wall isn’t cooking tickets in the order they arrived, and not even strictly by tip size. It’s cooking whatever sequence earns the kitchen the most money — and sometimes that means cooking ticket #7 right after ticket #3 because doing so unlocks a fat catering bonus that only pays out in that exact sequence.

Definition. A block builder (the entity that assembles the ordered list of transactions in a block) chooses the contents and order to maximize the block’s total revenue:

total block reward = sum of priority fees (tips) it collects + MEV it captures by ordering

The lazy, naive heuristic is “highest priority fee first.” Grab the transactions offering the biggest tips, slot them in descending order, done. That captures the tips — but it leaves MEV on the table. A profit-maximizing builder instead reorders so that value-extracting bundles (an arbitrage that depends on running right after a big swap, a liquidation that must go first) land in the exact slots where they pay out. This is the bridge straight from Lesson 1: reordering the same set of transactions changes who gets paid, and the builder pockets the difference.

Worked example. Five pending transactions, each offering a tip, in gwei. Three are plain user transactions; two are searcher bundles that pay an extra bribe — but only if the builder places them in their profitable slot:

Tip-only ordering (highest fee first): the builder sorts by tip — Liquidation (9), Arb (5), Bob (4), NFT (3), Alice (2) — and collects just the tips:

$9 + 5 + 4 + 3 + 2 = 23 \text{ gwei}$

The two bundles’ extra value never pays out, because neither sits in its required slot (the arb bundle needs to be right after Alice; here it’s two rows above her).

Builder-optimal reordering: the builder slots each extractor into its profitable position — liquidation first, the arb bundle immediately after Alice — so both extra payouts fire. Now revenue is the tips plus the captured value:

$\underbrace{23}_{\text{tips}} + \underbrace{28 + 14}_{\text{captured MEV}} = 65 \text{ gwei}$

Same five transactions, same tips, nearly triple the revenue — purely from the order. Flip between the orderings below and watch the headline number jump:

When it matters

This matters every time an opportunity’s value depends on adjacency — front-runs, back-runs, sandwiches, liquidations that must beat rivals to the collateral. For an ordering-independent transaction (a plain transfer), tip-first and builder-optimal coincide and the distinction is academic. The moment a bundle’s payout is positional, the builder’s reordering power becomes real money, and a builder that only sorts by tip is leaving revenue uncollected.

Gas and fees in the MEV context: the tip is your lever

Analogy. Splitting your bill at that restaurant: part of what you pay is a mandatory service charge the restaurant must destroy (it doesn’t keep it — think of it as legally burned), and part is a tip you hand directly to the chef. Only the tip influences whether the chef bumps your ticket up the queue. Raising the burned service charge does nothing for your position; raising the tip is how you buy your way forward.

Definition (EIP-1559 recap, framed for MEV). Every Ethereum transaction’s fee splits into two parts:

• Base fee — a per-gas price the protocol sets algorithmically based on how full recent blocks are. It is burned (removed from circulation), so the proposer gets none of it. Because the proposer earns nothing from it, the base fee is not a lever for ordering — every transaction in a given block pays the same base fee per gas.
• Priority fee (the tip) — a per-gas price you add on top, which goes to the proposer. This is the part the block producer actually pockets, so this is the lever you pull to buy better placement. Higher tip, better expected position.

Total fee for a transaction is:

$\text{total fee} = (\text{base fee} + \text{priority fee}) \times \text{gas used}$

Worked example. A swap uses 150,000 gas. The current base fee is 20 gwei per gas, and you set a priority fee of 3 gwei per gas. Then:

• Burned (to no one): $20 \times 150{,}000 = 3{,}000{,}000$ gwei $= 0.003$ ETH.
• Tip (to the proposer): $3 \times 150{,}000 = 450{,}000$ gwei $= 0.00045$ ETH.
• Total you pay: $(20 + 3) \times 150{,}000 = 3{,}450{,}000$ gwei $= 0.00345$ ETH.

Of everything you paid, only the 0.00045 ETH tip influences ordering — that’s the part the proposer keeps and the part that makes it worth their while to place you ahead of someone tipping less. If you wanted to outbid a rival for the same slot, you’d raise the priority fee, not the base fee (which you can’t control anyway).

The slider below makes the lever tactile: a block has limited room, the producer grabs the highest-tip transactions first, and your transaction only confirms if your tip beats enough rivals to fit. Drag your fee up and watch yourself jump the queue.

When it matters

The tip-as-lever framing matters whenever blocks are congested — when there are more transactions wanting in than fit. In a quiet block with empty space, a near-zero tip confirms fine; ordering is barely contested. But the instant demand for blockspace exceeds supply — and especially when a specific, time-sensitive opportunity is up for grabs — the tip becomes a bid in a real auction, and that’s where the next idea kicks in.

Priority gas auctions: bidding the profit away

Analogy. Two scrap dealers spot the same $100 antique at a yard sale, both desperate to buy it before the other. They bid each other up — $40, $60, $80, $95 — until whoever wins pays $95 for a $100 item, netting a measly $5, while the seller pockets nearly the whole $100. They competed the profit away. Replace “scrap dealers” with “MEV searcher bots,” “the antique” with “an on-chain arbitrage,” and “the bid” with “the priority fee,” and you have a priority gas auction.

Definition. A priority gas auction (PGA) is what happens when multiple bots compete for the same MEV opportunity by repeatedly bidding up their priority fees, racing to be the one the builder places in the profitable slot. Because only the highest bidder captures the opportunity, each bot keeps raising its tip — an open, escalating auction — until the tip approaches the opportunity’s value itself.

Cause → effect. The more obvious and contested an opportunity is, the more bots pile in, and the more the profit gets competed away to the proposer in fees:

• One bot, no competition → it captures nearly the whole opportunity, paying only a tiny tip.
• Many bots, fierce competition → the winning tip is bid up toward the opportunity’s full value, and the proposer (who pockets the tips) captures most of it. The searcher’s net edge collapses toward zero.

Worked example. Suppose a freshly visible arbitrage is worth 0.5 ETH to whoever lands it. With a single searcher and no rival, that bot might tip 0.01 ETH and net $0.5 - 0.01 = 0.49$ ETH. Now make it a crowded PGA: three bots bid each other up — 0.2, then 0.35, then 0.47 ETH — and the winner tips 0.47 ETH to secure the slot. Its net edge is now $0.5 - 0.47 = 0.03$ ETH, while the proposer collects 0.47 ETH in priority fees — roughly 94% of the opportunity, handed over purely because the auction was competitive. The opportunity’s value didn’t change; competition just redistributed almost all of it from searcher to validator.

PGAs have an ugly side effect beyond thin searcher margins. Because bots spam the public mempool with rapidly escalating, often-failing bids, they congest the chain — pushing up the base fee and clogging blockspace for ordinary users, who get caught in the crossfire of a fight they’re not even part of. This pain — public, wasteful, and chain-clogging — is exactly what motivated private orderflow: routing transactions and bids around the public mempool to a builder directly, so the auction happens off-chain and quietly. That’s the heart of the next-but-one lesson on proposer-builder separation (PBS); for now, just file the tease: PGAs were the loud, public auction, and the ecosystem moved to make it private.

Order flow is the product

Step back and name what’s actually being bought and sold. The proposer doesn’t really sell blockspace alone — plenty of chains have spare space. What’s scarce and valuable is the right to decide the order, because that right is what unlocks MEV. When a searcher bids a priority fee, or routes a bundle to a builder, they are paying for ordering — for their transaction to land in a specific position relative to others.

That reframing is the thesis of this whole topic: order flow is the product. The mempool is where order flow becomes visible; the priority fee is how the right to order gets priced; the PGA is the auction’s loud public form. Every later lesson — front-running, PBS, fair ordering, encrypted mempools — is a different answer to the same question: who should get to decide the order, and how should that right be sold or constrained?

So far the auction has been public and honest about what it sells — tips bid in the open mempool for better placement. But we haven’t yet looked at the most pointed thing a builder can do with a freshly visible transaction. The next lesson, front-running and back-running, zooms in on the two primitive moves of MEV: jumping ahead of your transaction to profit from the price you’re about to move, and slotting in right behind it to clean up the aftermath — the two halves that, sandwiched together, make the attack you’ll learn to recognize on sight.