The House Edge

Appearance

Chapter 3 Spec — The Mempool and What Replaces It ​

Status: STRAWMAN (drafted by agent, 2026-05-14 — Nick edits before Phase 1) Production order: Fourth chapter to draft, after Ch 4, Ch 2, Ch 1

⚠️ Strawman, like Chs 1 and 2. Nick wrote the Ch 4 SPEC; this one was drafted by the agent off OUTLINE.md and the Ch 1/Ch 2/Ch 4 patterns, then handed back for editing. The fields most worth Nick's attention are Worked example candidates, Tone notes (this chapter is the hinge — adversarial content lands here), and Open questions for Phase 1 research.

Learning objective ​

By the end of this chapter, the reader can:

  1. Define the public mempool and explain why its existence is the precondition for sandwich attacks, frontrunning, and most other extractive techniques the book has already named.
  2. Describe the three main architectural responses to mempool exposure: Ethereum's private order flow services (Flashbots Protect, MEV-Share, MEV-Blocker, EigenLayer-style hooks); Solana's engineered substitute (Gulf Stream plus Jito's bundle auction); Hyperliquid's no-mempool design.
  3. Identify which trade-offs each response makes: privacy vs. latency, MEV-resistance vs. censorship-resistance, individual fix vs. systemic fix.
  4. Articulate why the chapter calls itself "the hinge" — that the reader can now trace the dollar from intent to extraction without further context.

Why this chapter ​

Chapter 3 is the hinge of the book.

Chapters 1, 2, and 4 have already done their jobs. Ch 1 installed the vocabulary (intent / settlement / finality). Ch 2 showed where liquidity lives and who provides it. Ch 4 named the searcher and showed how MEV gets extracted. Each of these chapters referred to "the public mempool" or "transaction visibility" with a one- or two-sentence inline cameo, deferring the real treatment to here.

Ch 3 lands the treatment. After this chapter, the reader knows exactly what surface the searcher reads from, exactly what the architectural responses are, and exactly what each response trades away. The actor chapters that follow (Ch 5 on validators and builders, Ch 6 on infrastructure, Ch 7 on exclusive flow) can then build on the visibility primitive without further explanation.

The chapter is adversarial in framing — explicitly so. The OUTLINE.md calls this the chapter "once the reader understands transaction visibility, the adversarial content lands." The Bible's voice rules still bind: clinical, named actors, show the dollar. But the chapter's job is to make the reader feel the predator's view of the mempool as concretely as it can.

Key questions answered ​

  • What does a public mempool actually look like to someone reading it — what fields, what timing, what information leaks?
  • Why is mempool visibility the substrate for extraction, and how much of the searcher business documented in Ch 4 depends on it?
  • What are the three main responses — private routing on Ethereum, engineered substitution on Solana, architectural elimination on Hyperliquid — and what does each one cost the user who chooses it?
  • Who pays for private routing today, and who wins from it: the user, the searcher who buys exclusive flow, the validator who gets paid for ordering it?
  • What would change if the public mempool were eliminated entirely on Ethereum — and why has that not happened?

Characters introduced ​

  • The mempool watcher (concept, not full sidebar — full actor treatment was the searcher in Ch 4). A short reference back to Vpe and the searcher firms named there.
  • Flashbots (named institution; full infrastructure treatment is Ch 6 — here, just the protocol mechanism). The chapter's primary named actor on the Ethereum private-routing side.
  • MEV-Blocker and MEV-Share (named protocols; cameos with mechanics).
  • Jupiter MEV-Protect (cameo, already in Ch 2 — referenced here for the Solana case).
  • Jito's block engine (cameo, full infrastructure treatment Ch 6 — here, just the bundle-auction mechanism).
  • The chapter does not need a "Meet the actor" sidebar. The reader has met the relevant actors (the searcher in Ch 4, the market maker in Ch 2, the trader Alice across multiple chapters). Ch 3's structural job is to develop the substrate, not introduce new actors.

Worked example candidates ​

The agent should consider all three and pick one to anchor:

  1. Alice's $10,000 USDC→SOL swap, submitted through (a) a stock Solana RPC and (b) Jupiter's MEV-Protect routing. The chapter walks both paths through the visibility layer: in (a) her transaction is observable to anyone running a Solana RPC during the brief window before the slot leader includes it; in (b) it is delivered directly to Jito as a bundle and skips the public path entirely. The reader sees what visibility costs Alice and what private routing saves her. Pros: continuity with Ch 1 (same Alice, same trade); shows the architectural-response payoff vividly; clean dollar comparison. Cons: Solana-centric; would need a paragraph cameo on the Ethereum case.

  2. An Ethereum trader submitting through Flashbots Protect vs public mempool. Concrete walk-through of the RPC override (the user changes their wallet's RPC URL to Flashbots Protect; the wallet now sends transactions through the private path), what gets bundled with what, and what the trader pays differently. Pros: lets the chapter develop Flashbots' mechanism in detail (a 2026 reader probably encountered "Flashbots" without understanding what it is); the named institution gets full treatment. Cons: requires the reader to follow Ethereum-specific routing decisions before the Solana case lands.

  3. A side-by-side: the same $10K swap submitted to (a) Solana via Jupiter MEV-Protect; (b) Ethereum via Flashbots Protect; (c) Hyperliquid (where the question doesn't apply). The chapter shows all three responses to mempool exposure in one frame. Pros: comprehensive — the reader sees all three architectural responses in the worked example itself. Cons: more complex to thread; risks making the chapter feel like a survey.

Agent's recommendation (Nick edits): Option 1, with Option 2 as a one-paragraph cameo in the Ethereum mechanics subsection, and Option 3's Hyperliquid case folded into the chain-comparison box at §6. Continuity with Ch 1 carries the chapter — the reader knows Alice; the new beat is what the visibility layer does to her trade.

Glossary terms this chapter introduces ​

Defined in full:

  • Public order flow — transactions broadcast through the public path (Ethereum's public mempool, Solana's public RPC), visible to anyone observing the network.
  • Private order flow — transactions delivered directly to a block builder or sequencer, bypassing the public path; the trader has chosen visibility-against-extraction as a trade-off.
  • Flashbots Protect — the canonical Ethereum private-routing service; the user changes their RPC endpoint, transactions are bundled with refunds back from any MEV captured.
  • MEV-Share — the Flashbots successor mechanism that lets users selectively share parts of their transaction with searchers in exchange for a refund of the extracted value.
  • MEV-Blocker — an alternative Ethereum private-routing service (operated by CoW DAO and Beaverbuild) with a different revenue-share model.
  • Bundle (full treatment) — already appeared in cameo in Chs 2 and 4 as "an all-or-none group of transactions"; the full mechanics live here (atomic execution, payment to validator via tip transaction, the relay's role).
  • Relay — on Ethereum, the entity that receives bundles from builders and submits them to validators (Flashbots Relay, Ultrasound Money, BloXroute, Aestus, etc.).
  • Inclusion list / FOCIL — the proposed Ethereum mechanism by which validators can force a builder to include specific transactions, addressing censorship-resistance concerns when private routing dominates.

Cameo only (one inline sentence; full treatment elsewhere):

  • Block builder (full treatment Ch 5)
  • Jito (full treatment Ch 6)
  • TPU, Gulf Stream (Solana-specific; already cameoed in Ch 1)
  • HyperBFT (Hyperliquid-specific; already cameoed in Chs 2 and 1)

Diagrams needed ​

2–3 diagrams.

  1. D1 — Two paths for Alice's transaction (Mermaid flowchart). A side-by-side flow diagram. Left side: Alice → public Solana RPC → Gulf Stream gossip → slot leader; with annotations showing the visibility window. Right side: Alice → Jupiter MEV-Protect → direct bundle to Jito → slot leader; with annotations showing no public exposure. The diagram lets the reader see what private routing buys.

  2. D2 — Private vs public order flow share by chain (markdown table). A table summarising what's known about how much trader flow goes through private vs public routing in 2026. Columns: chain, public-flow share, private-flow share, dominant private routes. Rows: Ethereum L1, Base, Arbitrum, Solana, Hyperliquid. Many cells will say "not publicly measured" — that itself is a chapter point.

  3. (Optional) D3 — The bundle auction (Mermaid sequence diagram). Time-ordered: searcher constructs bundle → submits to relay/Jito → relay forwards to builder or directly to validator → block produced with bundle included in the order specified. Useful if the chapter wants to develop bundle mechanics in detail. Could be saved for Ch 6 if the chapter runs long.

Backward:

  • Chapter 1 (What Is a Trade, drafted): defined intent and the cameo on the mempool. Ch 3 references Ch 1's definition and develops it. The reader does not need to re-read Ch 1 to follow this chapter, but the chapter assumes the three-phase vocabulary.
  • Chapter 2 (Where Liquidity Lives, drafted): introduced the prop-AMM displacement and the solver markets, both of which depend on visibility into incoming flow. Ch 3 explains the mechanism that makes prop-AMMs more accurate than passive pools.
  • Chapter 4 (The Searcher, drafted): the actor most exposed by mempool visibility. Ch 3 returns to Vpe, the named program from Ch 4, and shows the visibility surface they were reading.

Forward:

  • Chapter 5 (Validator and Builder, not yet drafted): the actors who decide what goes in a block and who get paid by the private-routing services. Ch 3 names them in cameo; Ch 5 develops them.
  • Chapter 6 (Infrastructure Layer, not yet drafted): Flashbots, Jito, MEV-Boost — the firms that operate private routing. Ch 3 names the institutions; Ch 6 develops the business.
  • Chapter 7 (Exclusive Order Flow, not yet drafted): the next step beyond private routing — when a single firm has a monopoly on a slice of flow. Ch 3 sets up the question; Ch 7 answers it.
  • Chapter 11 (Who's at a Disadvantage): the chronic losers in the visibility-asymmetry game.

Tone notes specific to this chapter ​

  • The chapter is adversarial. The OUTLINE explicitly calls this the chapter where the adversarial content lands. The Bible's voice rules still bind — clinical, named actors, show the dollar, no hype — but the chapter should feel like the reader's understanding of the mechanics has been upgraded. After Ch 3, the reader can read any future "MEV extracted X million dollars" headline and know which surface was being read.
  • Build on Ch 4's named actors. Vpe (the Solana sandwich program) and the searcher firms returning from Ch 4 §5d should be referenced explicitly. The reader has met them.
  • The "Meet the Searcher" sidebar from Ch 4 does not need to be repeated. The reader already has the actor; the chapter develops the surface the actor reads from.
  • The TradFi parallel is harder here. Equity markets do not have a public mempool; pre-trade information is asymmetric only between the exchange and the participant (which is what payment-for-order-flow exploits). The closest parallel is the pre-2007 Reg NMS world of dark pools — the chapter can reach for it but should not over-extend. The Bible says TradFi parallels are encouraged when they fit; do not force one if the on-chain mechanic has no clean analogue.
  • Censorship resistance is a load-bearing concept in this chapter. Private routing trades one risk (extraction) for another (censorship): once a single relay or builder dominates flow, they can refuse to include specific transactions. The chapter should land this trade-off without taking a position on which risk is worse.
  • Diagrams replace prose, they don't supplement it. The two-path flowchart should carry the visibility-asymmetry mechanic; the surrounding text says what the diagram means.

Open questions for the agent's Phase 1 research ​

Number these in the research note.

  • Ethereum private order flow share, Q1/Q2 2026. What % of Ethereum L1 retail flow now goes through Flashbots Protect, MEV-Blocker, MEV-Share, or builder-direct private channels vs the public mempool? Flashbots, BlockNative, Etherscan, and Galaxy Research are the likely sources.
  • MEV-Share adoption and mechanics in 2026. MEV-Share launched in mid-2023 with the promise of letting users selectively share parts of transactions for refunds. What's the current state — is it the dominant private-routing path, a niche, or has the model shifted?
  • MEV-Blocker share vs Flashbots Protect. CoW DAO and Beaverbuild operate MEV-Blocker; what's its current share of Ethereum private flow vs Flashbots Protect?
  • FOCIL / inclusion lists status in 2026. Ethereum's proposed mechanism for forcing builders to include specific transactions, addressing censorship-resistance. What's the EIP status, the testnet status, and any 2026 development news?
  • Jupiter MEV-Protect adoption. Now that it's default routing for many wallets and Solana shipped a protocol-level patch in April 2026, what fraction of Solana retail flow actually flows through MEV-Protect vs the public RPC paths? Helius is the likely source.
  • Jito Block Assembly Marketplace (BAM) post-April-8. Ch 4 cited BAM as the substrate for the April 8 2026 Solana sandwich patch. What does it do mechanically that the chapter needs to explain? Jito has likely documented it; Helius has likely covered it.
  • Builder concentration on Ethereum in 2026. Ch 4 cited Titan at ~52% of Ethereum blocks Q1 2026. The chapter needs to develop what a builder does at the visibility layer — does the builder see the public mempool, or only private flow, or both?
  • Cost of private routing. What does Alice actually pay to use Flashbots Protect or MEV-Blocker? Is the service free at the wallet level and monetised via builder rebates, or is there a direct cost?
  • The "censorship-resistance vs MEV-resistance" trade-off in published research. Is there a 2026 paper or commentary that quantifies this — Paradigm, Flashbots, Justin Drake, Hasu?

Out of scope for this chapter ​

  • Specific MEV mechanics (Chapter 4, already drafted)
  • Liquidity-venue architecture (Chapter 2, already drafted)
  • Validator / builder economics (Chapter 5)
  • Infrastructure-provider business models (Chapter 6 — Flashbots' revenue model, Jito's revenue split, etc.)
  • Exclusive flow arrangements (Chapter 7)
  • Wallet privacy / mixers / Tornado Cash–style services (not a book topic)
  • Cross-chain mempool issues (Chapter 10)

Keep this chapter focused on what the visibility surface looks like, what trades happen at it, and what the architectural responses cost. Everything else is cameo or forward link.