The House Edge

Appearance

Chapter 6 Spec — The Infrastructure Layer ​

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

⚠️ Strawman pattern. Nick wrote the Ch 4 SPEC; this one was drafted by the agent off the OUTLINE.md description and the prior chapter rhythm. Fields most worth Nick's editorial attention: Structural organisation (the chapter has many firms to cover — by function or by chain?), Worked example candidates, Tone notes, and Open questions for Phase 1 research.

Learning objective ​

By the end of this chapter, the reader can:

  1. Name the firms that operate the major layers of on-chain trading infrastructure — RPC providers, block builders, relays, block engines, OFA operators, validator-as-a-service operators, decentralised-sequencing services — and explain what each one sells and to whom.
  2. Articulate why these firms' existence is "the most under-appreciated fact about on-chain trading," in the OUTLINE's framing — the structural argument that the surface the trader sees (Coinbase, Jupiter, Hyperliquid's interface) is a thin client on top of a B2B infrastructure stack that the trader never interacts with directly.
  3. Identify the revenue models that have emerged at each layer — take rates, rebates, subscription tiers, validator profit-sharing — and explain why each is structurally sustainable.
  4. Recognise the concentration patterns at each layer: which functions are operated by a single firm with >50% share, which by a 2–3-firm oligopoly, which remain genuinely competitive.

Why this chapter ​

Chapter 6 is the third of the four actor chapters. The book has now met every direct counterparty the trader has — the market maker (Ch 2), the searcher (Ch 4), the validator and builder (Ch 5) — but the firms that make those direct counterparties' businesses possible are still mostly off-stage. Chapter 6 brings them on.

The structural argument the chapter exists to land: on-chain trading market structure is determined less by the protocols' formal rules than by a small set of infrastructure firms whose business it is to route, sequence, build, and refund the trading flow that crosses the protocols. The OUTLINE called this "the most under-appreciated fact about on-chain trading." The chapter's job is to make it appreciated.

The chapter is the second-to-last actor chapter; Chapter 7 (Exclusive Order Flow) is the pay-off, where the actors' relationships are followed to their structural conclusion. Chapter 6 lays the institutional groundwork.

Key questions answered ​

  • Who are the firms that operate each layer of the on-chain trading infrastructure stack, and what does each one actually do?
  • What does each firm sell, who buys it, and what is the take rate?
  • Which layers are operated by a single firm with overwhelming share, and which are genuine competitive markets?
  • How big is this market in aggregate — what fraction of every on-chain trading dollar passes through these firms?
  • Why have these firms emerged on top of "permissionless" chains that, in theory, no one needed to operate?

Characters introduced ​

One full "Meet the Infrastructure Provider" sidebar. The named institutions the chapter develops:

Solana side:

  • Jito Labs (already extensively cameoed in Chs 3, 4, 5; full business treatment here — Block Engine, BAM, validator-client share, revenue model)
  • Helius (Ch 3 cameo as RPC pipeline behind major wallets; full treatment here — RPC tiers, LaserStream, Sender, validator stake, MEV-rebate marketing to wallets)
  • Triton One (introduced; BAM Node operator; cited in Helius's BAM coverage)
  • Temporal (Ch 2 cameo as HumidiFi's reported operator; full firm treatment here)
  • Anza (Ch 5 as Agave maintainer; brief firm treatment here)
  • Jump Crypto (Ch 5 as Frankendancer/Firedancer maintainer; brief firm treatment)
  • Rakurai (Ch 5; brief firm treatment)
  • Harmonic (Ch 3, 5; brief firm treatment)
  • Kolibrio (Ch 3 cameo; brief firm treatment as OFA operator)
  • Astralane — flagged in OUTLINE; need research
  • Nozomi — flagged in OUTLINE; need research
  • Eden — flagged in OUTLINE (note: there was an "Eden Network" on Ethereum that pivoted; need to verify it's Solana-relevant in 2026)

Ethereum side:

  • Flashbots (Ch 3, 5; full business treatment here — Flashbots Protect, MEV-Share, BuilderNet stake, the SBC and SMG)
  • Titan (Ch 3, 5; full firm treatment — Kubi Mensah's leadership, business model, the Banana Gun exclusive arrangement, profit margin)
  • BuilderNet (Ch 3, 5; full firm treatment — multi-operator structure, founding operators, governance)
  • Beaverbuild (Ch 3, 5; brief firm treatment — migration into BuilderNet)
  • Quasar (Ch 3, 5; brief firm treatment)
  • bloXroute (Ch 3, 5 as relay name; full firm treatment — they're more than relays; have private mempool products and broader infrastructure)
  • Aestus (Ch 3, 5 as relay name; brief firm treatment)
  • Ultrasound Money (Ch 3, 5 as relay; brief firm treatment)
  • MEV-Blocker (Ch 3 cameo; brief firm treatment as the Special Mechanisms Group at Consensys)

Cross-chain:

  • Wintermute (Ch 2, 5 as MM; brief firm treatment as an MM that also runs infrastructure)
  • Flow Traders / Flowdesk (Ch 5 cameo; brief firm treatment)

Worked example candidates ​

The chapter has more firms than a single worked example can carry cleanly. Three options:

  1. Follow a single trade's path through the infrastructure stack. Alice or Carlos (from prior chapters) submits a swap; the chapter traces every infrastructure firm that touches the trade — RPC provider, OFA operator (Kolibrio or MEV-Share), block builder, relay, validator client maintainer, the firm operating the wallet's backend. Each firm gets a one-paragraph treatment as the trade passes through. Pros: structural continuity with prior chapters; lets the chapter introduce each firm in context. Cons: forces the chapter to be linear when the infrastructure layer is more naturally a parallel market with multiple firms competing at each layer.

  2. Profile one firm in depth — Helius — and show its full product stack. Helius is the cleanest single example because it operates at multiple layers: RPC for major wallets, validator client (the network's largest single validator by stake), MEV-rebate marketing to wallet customers, paid tiers ($499–$999/mo), BAM Node operator, Solana ecosystem research publisher. Pros: gives the reader a complete picture of one firm's business; the other firms get summarised against the Helius template. Cons: Helius is Solana-specific and Ethereum side needs its own anchor.

  3. A pair of named-firm profiles — Helius (Solana) and Flashbots (Ethereum) — with the other firms summarised against them. Pros: covers both chains; gives the reader two complete pictures; allows the chapter to develop the comparative argument (Solana's infrastructure is more concentrated; Ethereum's is more fragmented in some functions). Cons: still incomplete; some firms not directly profiled.

Agent's recommendation (Nick edits): Option 3 — paired Helius/Flashbots profiles as the anchor, with the other firms summarised against them. Both firms have published enough about themselves that the chapter has primary-source material; both firms sit at multiple layers of their respective stacks; the pair allows the chapter's comparative argument to land.

Structural organisation — by function or by chain? ​

The chapter has to decide: cover infrastructure by chain (Solana firms, Ethereum firms) or by function (RPC, builder, relay, etc.). The trade-off:

  • By chain: simpler narrative; lets the chapter reuse the Solana/Hyperliquid/Ethereum frame from prior chapters; loses some structural argument because the same function on different chains can be operated by very different firm structures.
  • By function: cleaner structural argument; harder to read because the reader has to track the same firms in multiple subsections.

Agent's recommendation: by function. The chapter's structural argument is about the layers of the infrastructure stack and the firms that occupy each one. Organising by chain would re-fragment what the chapter is trying to consolidate.

The H4 subsections under "The mechanics, in detail":

  1. The RPC providers — Helius (Solana), Triton, QuickNode, Alchemy, Infura; the relationship between RPC and visibility (Ch 3); the wallet-backend pipeline
  2. The block builders and bundle markets — Titan, BuilderNet, Quasar, Beaverbuild on Ethereum; Jito Block Engine, BAM, Temporal, Paladin on Solana
  3. The relays and routing infrastructure — Ultrasound Money, Titan Relay, bloXroute, Aestus, Flashbots Relay on Ethereum; the relay role and Hasu's "neutral relay" framing
  4. The Order Flow Auction operators and refund services — Flashbots Protect, MEV-Blocker, MEV-Share, Kolibrio, CoW Solvers; the wallet-rebate model

That's 4 subsections, at the chapter spec template's hard limit. Validator-as-a-service operators (Coinbase Cloud, Kiln, Lido operators, etc.) were developed in Ch 5; the chapter references them but doesn't re-introduce them.

Glossary terms this chapter introduces ​

The chapter is mostly developing firms that are already in the glossary at the institutional level. New glossary entries:

Defined in full:

  • RPC provider — a firm that operates the API gateway between user-facing applications (wallets, aggregators, bots) and the chain itself; in 2026, the largest RPC providers also operate validator stake, MEV-rebate flows, and (in some cases) private-mempool surfaces.
  • Order Flow Auction (OFA) — a market in which a routing entity (Kolibrio, Flashbots-via-MEV-Share, CoW solver auction) sells the right to fill a transaction to whichever searcher or solver bids the most, with a share of the bid refunded to the original submitter.
  • LaserStream / Sender (Helius-specific) — Helius's paid-tier transaction-visibility and submission products; functionally analogous to the Jito mempool of 2022–2024 but at the RPC layer rather than the validator layer.
  • Refund (MEV refund) — a payment from a successful searcher/solver back to the original transaction submitter, typically routed through a private-routing service.

Brief mentions (one inline sentence, may or may not get full glossary entries):

  • Wintermute, Flow Traders, Selini, Auros (already named; cross-chain MM/solver firms)
  • BloXroute as a firm (vs the relay name)
  • Astralane, Nozomi, Eden (need research first)

Diagrams needed ​

Two diagrams.

  1. D1 — The infrastructure stack (Mermaid flowchart). Vertical layers: User wallet → RPC provider → OFA layer → Builder/Block engine → Relay → Validator/Slot leader → Chain. Each layer labelled with the named firms that operate it on Solana and on Ethereum. The diagram is the chapter's "this is the stack" anchor.

  2. D2 — Firm-by-layer table (markdown). Rows: each named firm. Columns: chain(s), primary layer(s) of operation, what they sell, who buys, take rate / revenue model, notable competitor or close substitute. The table consolidates the chapter's content for a reader who wants the named-entity map without re-reading.

Backward:

  • Chapter 3 (drafted): introduced many of these firms in the context of the mempool's replacement. Ch 6 develops them as institutions.
  • Chapter 4 (drafted): the searcher pays the infrastructure firms; this chapter is who they pay.
  • Chapter 5 (drafted): the validator + builder roles. This chapter is the broader institutional ecosystem the validator operates inside.

Forward:

  • Chapter 7 (Exclusive Order Flow): the structural pay-off chapter. When one firm operates multiple layers of this stack, they have a moat over flow. Ch 7 is about that.
  • Chapter 11 (Who's at a Disadvantage): the structural-concentration arguments the chapter makes here come back as part of the chronic-loser thesis.
  • Chapter 12 (Where This Is Going): protocol-level alternatives to the current institutional landscape (ePBS, Constellation, decentralised sequencers).

Tone notes specific to this chapter ​

  • The chapter is adversarial in framing, in the Ch 3 / Ch 5 register. The B2B infrastructure layer is the structural reality of on-chain trading; the chapter exists to make it visible.
  • Specific firms, specific dollar amounts. Every named firm gets sourced numbers — take rates, revenue, stake share, customer count. The Bible's "name the loser, show the dollar" rule lands hard here.
  • The "you've never heard of them" framing is the chapter's lead. The cold open and the verdict should both lean on the structural-invisibility argument: these firms are large, profitable, and route most of the flow; the average trader has never heard of any of them.
  • No tribal chain endorsements. The chapter has both Solana and Ethereum firms; the structural argument applies to both with different shapes.
  • The "Meet the Infrastructure Provider" sidebar is a template that's then instantiated against specific firms in the prose. Same format as Meet the Validator / Meet the Builder / Meet the Market Maker / Meet the Searcher.

Open questions for the agent's Phase 1 research ​

Number these in the research note.

Solana side:

  • Helius's full product stack and revenue. Their pricing tiers, customer count for each, what fraction comes from RPC fees vs MEV rebates vs validator commissions. Helius is the chapter's anchor on the Solana side.
  • Temporal as a firm. They reportedly operate HumidiFi (Ch 2). What else? Are they a public-facing company with leadership team, funding, named products?
  • Triton One. BAM Node operator; what else do they sell?
  • Astralane. Named in the OUTLINE; need to research what they actually are.
  • Nozomi. Named in the OUTLINE; need to research.
  • Eden. Was an Ethereum-side network; is it still active and Solana-relevant in 2026?
  • Jito Labs as a firm. Revenue model in 2026 — Block Engine fees, BAM revenue share, JTO token holdings. What did Jito Labs the company earn in 2025–2026?
  • Anza as a firm. Spun out of Solana Labs; what's their structure, funding, and business model?
  • Jump Crypto's Solana investments and infrastructure footprint. Jump operates Firedancer / Frankendancer; what's the firm's broader Solana-infrastructure investment thesis?

Ethereum side:

  • Flashbots's full product stack and revenue in 2026. Special Mechanisms Group at Consensys (post-acquisition?); Flashbots Protect customer numbers; revenue from MEV-Boost contributions; SUAVE roadmap.
  • Titan's business model. Already cited 17.75% margin under Banana Gun arrangement; what else is known? Public statements from Kubi Mensah on Titan's strategy?
  • BuilderNet's operator economics. How do the founding operators (Flashbots, Beaverbuild, Nethermind) split revenue? What's the take rate?
  • bloXroute as a firm. They operate relays (BloXroute Max-Profit, BloXroute Regulated) but also sell other products — what's their full business?
  • Aestus. Smaller relay; who runs it?
  • Beaverbuild post-BuilderNet. Now that their flow is in BuilderNet, what's the standalone Beaverbuild business?
  • Quasar. 15% of Ethereum blocks; who runs it, what's known about the firm?
  • Eden Network. Need to verify current 2026 status.

Cross-chain:

  • The aggregate infrastructure-layer take rate. What fraction of every on-chain trading dollar ends up at one of these firms? Is there a published measurement, or does the chapter need to estimate from the named firm-level numbers?

Out of scope for this chapter ​

  • Specific MEV mechanics (Chapter 4)
  • Liquidity-venue architecture (Chapter 2)
  • Validator-level client / scheduler / voting strategies (Chapter 5)
  • Exclusive order flow arrangements (Chapter 7)
  • Layer-2 sequencer firms (Chapter 10 will cover Coinbase as sequencer operator for Base, Offchain Labs for Arbitrum, etc.; Ch 6 mentions in passing only)
  • Wallet apps as firms (Phantom, Backpack — they appear here only as customers of RPC providers)
  • Stablecoin issuers (Circle, Tether — not within the chapter's "trading infrastructure" scope)
  • Custody firms (Anchorage, Fireblocks, BitGo — they touch staking-as-a-service but aren't the chapter's subject)

Keep this chapter focused on the transaction-routing-and-block-construction infrastructure layer specifically. Everything else is a cameo or a forward link.