The House Edge

Appearance

Chapter 5 — Outline (Phase 2) ​

Status: OUTLINE (Phase 2 — written by agent, awaiting Nick's review) Date: 2026-05-14 Working chapter: 05 — The Validator (and the Builder) Carries forward from: RESEARCH.md

Working assumptions (carried from Phase 1) ​

Defaults from RESEARCH.md §6, treated as binding for Phase 3 unless Nick overrides.

  1. Word budget: ~5,500 words including footnotes — comparable to Ch 3. The content directive needs the room.
  2. Worked example: Candidate A — Coinbase Cloud as the proposer; Titan as the builder; a single block's economics walked end-to-end. Preserves the Figment-named-only-in-epilogue rule.
  3. Figment migration data: cited in a sourced footnote within the Solana subsection, not as the worked-example anchor.
  4. revenue Firedancer scheduler mode: noted with hedge ("appears in older documentation and operator notes; not confirmed in current Firedancer docs which list only perf and balanced").
  5. Alpenglow: substantial coverage (~300 words) inside the Solana subsection. Forward-link to Ch 12 for the full architectural treatment.
  6. Two sidebars: Meet the Validator + Meet the Builder, parallel-format. Both kept.
  7. OFAC framing: one sentence in the Coinbase Cloud worked example, with forward-link to Ch 11.
  8. Slashing: inline paragraph (~80 words) on the September 2025 SSV cluster, in the "operational excellence is still a moat" framing.

Title and subtitle ​

Chapter 5 — The Validator (and the Builder)The role that was supposed to be neutral plumbing — and the firms that took the rest of the job.

Cold open ​

On 15 September 2022, Ethereum stopped paying miners and started paying validators. The Merge — the protocol's transition from proof-of-work to proof-of-stake — was years in the making. The validators who took over the network had been framed for most of those years as neutral plumbing: software running in datacentres, taking a fixed share of issuance, staying out of the way. Within three months, on 7 November 2022, Flashbots launched MEV-Boost. Within nine months, more than 90% of Ethereum validators were running it. Validators were no longer simply producing blocks; they were proposing the bids that other firms — specialised builders — constructed and outbid each other to deliver. This chapter is about what happened to the validator role on three chains after MEV became measurable enough that the role itself could no longer be neutral, and about the firms that took the rest of the job when the validator's job got smaller.

(Why this open: a specific dated event the reader can verify; the Merge / MEV-Boost timeline lays the chapter's structural argument out cleanly in three sentences; the closing sentence sets up the chapter in the Ch 1 / Ch 2 / Ch 3 / Ch 4 pattern.)

What this chapter answers ​

  • What does a validator actually do, in 2026, on Ethereum, Solana, and Hyperliquid — and what is structurally different on each chain?
  • Why don't Ethereum validators actually build the blocks they propose, and what filled that gap?
  • On Solana, why has the choice of validator client and scheduler mode become the largest single revenue lever a validator has?
  • What is the structural difference between a neutral validator and a commercial one — and which architecture (Ethereum PBS, Solana auction stack, Hyperliquid native consensus) puts the role closest to "neutral plumbing" and which furthest?

Section list ​

  1. Cold open — the Merge → MEV-Boost timeline.

  2. What this chapter answers — the four questions above.

  3. The setup (≈400 words). What a validator is, in plain terms, on a proof-of-stake chain. The validator's old job (sign blocks, follow the leader schedule, take issuance) versus what the job has become. Plant for the chapter's argument: the role bifurcated into proposer / builder on Ethereum; into proposer / client-author / scheduler / preference-setter on Solana; and into a small permissioned set on Hyperliquid.

  4. The worked example (≈400 words). A single Ethereum block in May 2026: Coinbase Cloud (12.17% of network stake) is scheduled to propose; a searcher submits a bundle through Flashbots Protect; Titan (51.5% of blocks) constructs a candidate block including the bundle; Titan bids the block to Coinbase Cloud via the Ultrasound relay; Coinbase Cloud signs; the block is finalised; Coinbase distributes rewards to its staking customers after taking commission. The chapter walks the four-actor dollar flow and asks: which of these four actors is the validator?

  5. The mechanics, in detail (≈3,400 words; three H4 subsections):

    • Ethereum: the proposer who doesn't build the block (≈1,000 words). The Merge → MEV-Boost timeline (Sep 2022 → Nov 2022 → 90%+ adoption within 9 months). The PBS architecture: proposer, builder, relay, searcher. Why proposers outsource block construction: builders run specialised hardware, hold private order-flow relationships, and merge bundles more efficiently than a vanilla Ethereum node can. The 2026 builder concentration (Titan 51.5%, BuilderNet 24%, Quasar 15.3% — top three ~91% of blocks). Titan's profit margins under exclusive flow arrangements (up to 17.75%). BuilderNet as the multi-operator response (TEE-based, shared order flow, open-source refund rule). ePBS as the protocol-level fix that has slipped past Glamsterdam's H1 2026 target. Meet the Builder sidebar lands here.

    • Solana: the client stack is the moat (≈1,800 words). The Solana validator's role differs from Ethereum's in a load-bearing way: the validator is the block constructor, but the construction logic is determined by the client software the validator chooses to run. Six named clients now divide the network: Agave (the Anza reference, with its central-scheduler-greedy default), Jito-Solana (Jito's fork with Block Engine integration), JitoBAM (BAM-enabled, ~28% of stake), Frankendancer (Jump Crypto's hybrid, 12%), Firedancer (Jump's full C/C++ rewrite, 2% mainnet adoption). Each client has measurably different revenue profiles. Frankendancer's scheduler ships two named modes — perf (full blocks, maximum priority-fee capture) and balanced (default, optimised for revenue but not block-fullness, recommended under congestion); a third revenue mode appears in older docs and may be folded into Jito-integrated builds. Harmonic as the validator-side aggregation layer (full mechanical treatment was Ch 3) where validators express configurable preferences and pick the most valuable candidate block per slot from multiple builders; Syndica's March 2026 telemetry shows three Harmonic configurations — Performance (+101% priority fees vs median), Balanced (+39%), Agave Harmonic (+36%) — that operators self-select. The Figment migration to Frankendancer at epoch 871 (30 Oct 2025) is the chapter's cleanest single empirical anchor for "client choice = revenue moat": +18 bps SRR, 9× MEV/Jito tips, 2.5× priority fees on a single client switch [^cited]. Voting strategy as a separate revenue lever: Timely Vote Credits (SIMD-0033, activated Nov 2024) made low-latency vote landing a competitive moat; Chorus One's 2.03% skip rate versus the network's 5.19% is the moat operationalised. Alpenglow (SIMD-0326, 98.27% approval, testnet 11 May 2026) is the consensus-level rewrite that will further restructure validator economics — removing vote transactions from blockspace (~70% of tx at peak), introducing the Validator Admission Ticket (~0.8 SOL/day burned), and dropping the profitable-validator threshold from ~$800K to ~$75K. Meet the Validator sidebar lands here.

    • Hyperliquid: the permissioned set that sidesteps PBS entirely (≈600 words). Delegated PoS on HyperCore; top 21 validators by stake form the active set; self-delegation requirement of 10,000 HYPE locked for one year. The chain's matching engine sits inside consensus, so there is no block-builder role to separate. Validators earn issuance + commissions; HLP is structurally separate (earns 3% of trading fees, 97% routed to HYPE buybacks). Recent institutional validator launches (Hyperliquid Strategies + Unit Labs, May 2026) reflect rising institutional interest. The architectural trade-off: Hyperliquid's design eliminates the PBS surface but at the cost of much less flexibility — the chain works for what it was designed to do (a perpetuals exchange) and would not generalise to a more open programmability target. Full architectural treatment in Chapter 9.

  6. How this plays out on each chain (≈400 words). Three paragraphs — Solana, Hyperliquid, Ethereum + L2s — summarising what the validator's actual decision space is on each. The chain-comparison table consolidates the cross-chain view: who builds the block, who signs it, who pays whom, what the validator's competitive moat is.

  7. Who wins, who loses, why (≈400 words). Adversarial verdict in Ch 3 / Ch 4 register.

    • Winners: Block-construction firms (Titan ~51% of Ethereum blocks; Jito Labs across the Solana stack; BAM Node operators); validator-client developers whose software captures the right scheduler mode (Jump Crypto with Frankendancer; Anza with Agave-Harmonic); institutional validators with scale and infrastructure (Coinbase Cloud at 12.17% of Ethereum; Kiln across 50 networks); the Hyperliquid validator set as a permissioned oligopoly receiving stable issuance.
    • Losers: small validators on Solana whose client choice and scheduler configuration leave them earning closer to the median than the +101%-priority-fee top performers; Ethereum validators without private-order-flow access through specific builders; the public-goods narrative of "anyone can run a validator and contribute to the network's neutrality."
    • Is this bad?: clinical. The validator role has bifurcated into a signing function (still mostly neutral) and an ordering function (commercial). The structural argument the chapter has spent ~5,000 words making is that the bifurcation is genuine: a validator running stock Agave with default settings, no Harmonic, no BAM, and no relationship with builders is — measurably — earning less than half of what a sophisticated operator earns. The 32-validator Foundation enforcement from Ch 3 was the protocol governance equivalent of saying "this surface is unacceptable"; the BAM / Beam / Harmonic stack is the engineering equivalent of saying "this surface will exist anyway, so let's build it properly." Both can be true.

  8. What changes when… (one paragraph). The transition. What changes when a single firm operates the validator, runs its own RPC, runs its own searcher operation, and submits its own builds to its own validator? When the four-actor flow the chapter's worked example walked through collapses to one actor? That is Chapter 7's question.

  9. Footnotes and sources — numbered with URLs and access dates. Approximately 25 footnotes.

The worked example and where it threads through ​

A single Ethereum block in May 2026: searcher submits bundle → Titan constructs the block → Ultrasound relay forwards → Coinbase Cloud signs → block finalised → Coinbase distributes rewards.

SectionBeat
§3 (Setup)Plant: "we'll follow a single Ethereum block through four actors."
§4 (Worked example)The full walk: $X searcher payment, $Y builder margin, $Z validator MEV-Boost payment, $W staker reward after Coinbase commission. Specific numbers anchored to relayscan.io May 2026 data.
§5 EthereumThe PBS architecture generalised — Coinbase Cloud's choice of builder, the relay's role, ePBS as the protocol-level fix that hasn't shipped.
§5 SolanaNo Coinbase Cloud here — the Solana subsection runs on its own narrative (the client stack as moat).
§5 HyperliquidNo Coinbase Cloud — the Hyperliquid paragraph is about validator set composition.
§6 (Chain comparison)The validator's seat in each architecture, summarised.
§7 (Verdict)Coinbase Cloud as a named winner of the institutional-scale game; smaller validators without builder access as the named losers.

Diagrams needed ​

Two diagrams plus one optional.

  1. D1 — The Ethereum block flow (Mermaid sequence diagram). Time-ordered: searcher → Flashbots Protect → bundle to Titan → Titan constructs block → Ultrasound Relay forwards → Coinbase Cloud signs → block included → rewards distributed. Each arrow labelled with the dollar/ETH flow. Lands near the top of §5 Ethereum.

  2. D2 — Solana validator client + scheduler matrix (markdown table). Rows: each client (Agave default, Jito-Solana, JitoBAM, Frankendancer Jito, Frankendancer Harmonic Balanced, Frankendancer Harmonic Performance, Agave Harmonic, Firedancer). Columns: who builds it, current stake share (Mar 2026), default scheduler / mode, key revenue characteristic, headline metric vs network median. The table is the chapter's single most compressed unit of information.

  3. (Optional) D3 — Where the validator's dollar comes from (stacked bar by chain). Three bars: Ethereum, Solana, Hyperliquid. Each bar segmented by revenue source: base issuance, priority fees, MEV-derived. Could be Mermaid xychart-beta or static SVG. Useful if the prose runs short; potentially redundant if §6 covers it.

Glossary terms this chapter introduces ​

To be appended to GLOSSARY.md in Phase 3.

Defined in full (first appearance):

  • Proposer (Ethereum) — the validator scheduled to propose the next block in a given slot; on Ethereum since the Merge, the proposer's job is to sign a block constructed by another actor (the builder).
  • PBS / Proposer-Builder Separation — the architectural pattern in which block proposing and block construction are performed by different actors, connected by a relay.
  • ePBS (enshrined PBS) — the proposed Ethereum upgrade (EIP-7732) to bring PBS into the protocol layer rather than the out-of-protocol MEV-Boost relay layer.
  • Slot leader (Solana) — the validator scheduled to produce the current Solana slot; known ~2 days in advance per the published leader schedule.
  • Validator client — the software a validator runs; on Solana, the choice between Agave, Jito-Solana, JitoBAM, Frankendancer, Firedancer measurably affects revenue.
  • Frankendancer — Jump Crypto's hybrid Solana validator client; replaces Agave's networking layer with Firedancer's lower-level C/C++ stack while keeping Agave's consensus and execution.
  • Firedancer — Jump Crypto's full C/C++ Solana client rewrite; mainnet adoption ~2% of stake in March 2026.
  • Agave — the reference Solana client maintained by Anza; ships the default central-scheduler-greedy scheduler.
  • Central scheduler (Solana) — Agave's default block-production scheduler; uses 4 worker + 1 scheduling + 2 vote threads; priority by ((Priority Fee × CU Requested) + base fee) / (1 + CU Requested).
  • Pack tile (Firedancer) — the Firedancer/Frankendancer component that decides transaction ordering within a slot; supports user-selectable scheduler modes (perf, balanced, historically revenue).
  • Timely Vote Credits (TVC) — Solana mechanism (SIMD-0033, activated Nov 2024) that awards up to 16 vote credits for votes confirmed within 2 slots, with diminishing credits for later votes.
  • Alpenglow — Solana's planned consensus rewrite (SIMD-0326); replaces TowerBFT + PoH with Votor + Rotor; testnet 11 May 2026; mainnet late Q3/Q4 2026.
  • Votor — Alpenglow's vote-aggregation component; moves vote transactions off-chain using BLS-aggregated signatures.
  • Rotor — Alpenglow's block-propagation component; replaces the existing Turbine + gossip propagation.
  • Validator Admission Ticket (VAT) — Alpenglow's per-epoch fixed validator cost (~1.6 SOL burned/epoch); the first explicit fixed cost on Solana.
  • Slashing — the protocol-defined penalty applied to a validator's stake for misbehaviour (double-signing, missed attestations); on Ethereum, results in stake destruction; on Solana, manifests as reduced vote credits and reduced inflation-share rewards.
  • Staking Reward Rate (SRR) — the realised annualised yield on staked balance for a given validator; a function of issuance, fee capture, MEV, and operational discipline.

Cameo only (one inline sentence; full treatment elsewhere or already in glossary):

  • MEV-Boost (already in glossary)
  • Block builder (already in glossary)
  • Relay (already in glossary)
  • BAM (already in glossary)
  • Harmonic (already in glossary)
  • HLP (already in glossary)
  • Searcher (already in glossary)

Backward:

  • Chapter 1 (drafted): defined intent / settlement / finality and named the validator as the actor who orders transactions in a block. Ch 5 develops the validator's role at each phase.
  • Chapter 2 (drafted): cameoed Hyperliquid validators in the chain-comparison.
  • Chapter 3 (drafted): developed the surfaces validators operate on (mempools, BAM TEEs, MEV-Boost relays). Ch 5 develops the validator's decision space on top of those surfaces.
  • Chapter 4 (drafted): introduced validators as the recipients of priority fees and Jito tips. Ch 5 develops the full revenue picture.

Forward:

  • Chapter 6 (Infrastructure Layer, not yet drafted): the firms behind the validator stack — Jump Crypto, Anza, Jito Labs, Flashbots, BuilderNet. Ch 5 names; Ch 6 develops the business.
  • Chapter 7 (Exclusive Order Flow): the next step — what happens when a single firm operates the validator, runs its own RPC, and submits its own builds. Ch 5's verdict tees this up.
  • Chapter 9 (Hyperliquid): the Hyperliquid validator set, HLP, and the chain's architectural choices in full.
  • Chapter 11 (Who's at a Disadvantage): small validators without builder relationships as one of the chronic-loser archetypes.
  • Chapter 12 (Where This Is Going): Alpenglow, ePBS, and the protocol-level changes still being built.

Phase 2 is complete. Per the user's compressed-review pattern, Phase 3 begins immediately.