The House Edge

Appearance

Chapter 5 Spec — The Validator (and the Builder) ​

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

⚠️ Strawman, same pattern as the Ch 1, 2, 3 SPECs. Nick wrote the Ch 4 SPEC; this one was drafted by the agent off the OUTLINE.md description and the prior strawman pattern. Fields most worth Nick's editorial attention: Worked example candidates, the Meet the Validator and Meet the Builder sidebars, Tone notes (this chapter is the first one that names specific firms whose role is to extract on behalf of the chain), and Open questions for Phase 1 research (these become the literal research targets).

Learning objective ​

By the end of this chapter, the reader can:

  1. Define what a validator does on a proof-of-stake chain and distinguish it from the proposer, builder, and relay roles where they exist as separate actors.
  2. Trace where a validator's revenue comes from in 2026 — base issuance, priority fees, MEV-Boost payments on Ethereum, Jito tips and BAM revenue on Solana, HLP share on Hyperliquid — and articulate why none of those revenue streams existed in the form they do today five years ago.
  3. Explain why most Ethereum blocks in 2026 are not actually constructed by the validator that proposes them, and what that delegation has cost the chain's censorship-resistance properties.
  4. Identify which of the three named architectures (Ethereum PBS, Solana auction stack, Hyperliquid native consensus) puts the validator closest to the structural definition of "neutral plumbing" and which puts it furthest.

Why this chapter ​

Chapter 5 is the first deep dive into the actor that captures, in 2026, the largest share of every on-chain trading dollar that isn't kept by the trader. Chapters 4 and 3 named validators in cameo as the recipients of priority fees, Jito tips, and BAM revenue; Chapter 2 cameoed them as the operators of Solana's leader pipeline; Chapter 1 mentioned the validator as the actor who decides "which transactions go into the next block and in what order." None of those references developed the role. Chapter 5 does.

The chapter has a specific argument to make. The validator's job was originally framed as neutral block production — a job no one had to think about except in the abstract, the way no one thinks about the postal sorting clerk. By 2026, the validator role on every major chain has become a commercial position whose moat is access to specialised infrastructure (builders, RPCs, private mempools, Jito client extensions), not raw uptime. The chapter develops that shift with named actors, sourced numbers, and a worked example.

This is Part II of the book — The Actors — and Chapter 5 is the second actor chapter (after Ch 4's Searcher). It is the chapter that earns the right to make the structural argument the book's later chapters depend on: that on-chain trading market structure is determined less by the protocols' formal rules than by the small number of firms whose business it is to produce blocks.

Key questions answered ​

  • What does a validator actually do, in 2026, on Ethereum, Solana, and Hyperliquid — and what is structurally different on each chain?
  • Why don't validators actually build their own blocks anymore on Ethereum, and what filled that gap?
  • Who pays a validator on each chain, and how much of that revenue is MEV-derived versus base issuance?
  • What is the structural difference between a neutral validator (early Ethereum, Solana 2020-2022) and a commercial validator (Ethereum 2022-onward, Solana 2023-onward)?
  • How does Hyperliquid's architecture avoid the proposer-builder separation entirely, and what does that cost it in flexibility?

Characters introduced ​

Two full "Meet the actor" sidebars (the chapter is the only one in the book to introduce two simultaneously, because the validator and builder roles separated explicitly on Ethereum):

  • The Validator — the actor who stakes the chain's native token to be allowed to propose blocks. On Ethereum, the validator is also the proposer but rarely the block constructor. On Solana, the validator is the slot leader. On Hyperliquid, the validator is part of a small permissioned set running HyperBFT consensus.

  • The Builder (Ethereum-specific; cameoed on Solana as "block engine operator") — the firm whose software constructs the actual block content and bids for the validator's inclusion right via a relay. Named builders in 2026: Titan (~50% of Ethereum blocks), BuilderNet (~25%), Quasar (~16%), Beaverbuild (~2%).

Plus several returning named institutions from prior chapters:

  • Jito Labs (full treatment was Ch 3; Ch 5 returns to Jito as the Solana equivalent of a builder)
  • Helius (the largest single Solana validator by stake; 15M+ SOL)
  • The Solana Foundation (the regulator-equivalent for the chain's stake)
  • Flashbots / BuilderNet (the post-Flashbots Ethereum building infrastructure)
  • Hyperliquid validators (small permissioned set)

Plus several named individual experts/researchers as one-off citations:

  • Justin Drake (Ethereum Foundation; on ePBS and the validator/proposer separation)
  • Hasu (Flashbots / Special Mechanisms Group; quoted in Ch 3 on relay neutrality)
  • Tim Garcia (Solana Foundation; already named in Ch 3)
  • toly / Anatoly Yakovenko (Solana Labs; on the leader schedule design)

Worked example candidates ​

The agent should consider all three.

  1. A single Ethereum block, proposed by an institutional validator (e.g. Kiln, Lido operator, Coinbase Cloud), built by Titan, with a Flashbots-Protect-bundled transaction inside it. The chapter walks the dollar: searcher pays builder $X via the bundle's tip transaction; builder pays validator $Y to win the proposer's signature; validator pays the staker (the person whose ETH funded the validator) $Z after the staking pool's take. The reader sees that the validator is one node in a four-actor money flow, and the protocol's view of "validator" hides three of the four. Pros: concrete, dollar-anchored, develops the PBS architecture in the worked example itself, lets the chapter name a builder (Titan) and a validator operator (named) explicitly. Cons: Ethereum-only; needs a Solana paragraph cameo and a Hyperliquid cameo.

  2. A Solana slot won by a Jito-derivative validator, with a Jito tip routed through the BAM TEE enclave. The chapter walks: Alice's transaction enters via Jupiter Beam; Jupiter Beam delivers to Jito Block Engine; the slot leader includes Alice's transaction; the Jito tip Alice's bundle paid splits to validators, stakers, and the Jito DAO. Pros: continuity with Chs 3 and 4; carries Alice forward; develops the BAM revenue economics that Ch 3 cameoed. Cons: Solana-only.

  3. Side-by-side: a $X transaction's lifecycle on Ethereum (Titan builds, validator proposes) and on Solana (Jito builds, slot leader proposes). Pros: maximum architectural coverage. Cons: complex to thread; the Hyperliquid case still has to be a cameo.

Agent's recommendation (Nick edits): Option 1 (Ethereum block built by Titan). It's the chapter's most novel content — the book has cameoed PBS in Ch 3 but hasn't developed the actual mechanics. Solana and Hyperliquid cases get paragraph cameos in the mechanics subsection and the chain-comparison box.

Glossary terms this chapter introduces ​

Defined in full (first appearance):

  • Proposer (Ethereum-specific) — 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 that some other actor (the builder) has constructed.
  • PBS / Proposer-Builder Separation — the architectural pattern in which block proposing and block construction are performed by different actors, connected by a relay. MEV-Boost is the dominant implementation in 2026.
  • ePBS (enshrined PBS) — the proposed Ethereum upgrade to bring PBS into the protocol layer rather than the out-of-protocol MEV-Boost relay layer. Targeted for Glamsterdam (H1 2026) as headliner.
  • Slot leader (Solana) — the validator scheduled to produce the current Solana slot. Solana publishes the leader schedule per epoch, so leaders are known ~2 days in advance.
  • Staking / Stake — the act of locking a chain's native token to be eligible to validate. Includes risks like slashing and opportunity cost.
  • Slashing — the protocol-defined penalty applied to a validator's stake for misbehavior (double-signing, missed attestations, etc.).
  • Validator client — the software a validator runs. Specific implementations matter: on Ethereum, Lighthouse vs Prysm vs Teku; on Solana, Agave vs Jito-Solana vs Frankendancer vs Rakurai vs Firedancer. The choice of client increasingly determines a validator's MEV capture.
  • Validator — already named throughout; this chapter is its full glossary appearance.

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

  • Block builder (full treatment was Ch 3; refresh here)
  • MEV-Boost (already in glossary)
  • Relay (already in glossary)
  • Jito-Solana, Frankendancer, Rakurai, Firedancer (specific client names; one inline mention each with attribution to which firm builds them)
  • HLP (full treatment in Ch 9; cameo here in the Hyperliquid paragraph)
  • Issuance / staking yield (defined inline; not a full glossary entry)

Diagrams needed ​

2–3 diagrams.

  1. D1 — The proposer-builder-relay flow on Ethereum (Mermaid sequence diagram). Searcher submits bundle → builder constructs block → relay forwards to proposer → proposer signs → block published. Each step annotated with the dollar/ETH flow. The diagram should make the four-actor structure of a single Ethereum block visible.

  2. D2 — Where the validator's dollar comes from (markdown table). Rows: Ethereum, Solana, Hyperliquid. Columns: base issuance, priority fees, MEV-derived revenue, total. Cells with 2026 numbers (Figment's Q1 2026 report gives Solana figures; Ethereum data from Beaconcha.in or relayscan; Hyperliquid validators are paid via HLP). The reader sees that on Solana, MEV-derived revenue is now a minority share (≈0.36% of total per Figment Q1 2026); on Ethereum, MEV-Boost payments are typically 50%+ of validator revenue in a typical month.

  3. (Optional) D3 — Validator client adoption by chain (bar/stack). Solana already covered in Ch 3 (Agave 86%, with subvariants); Ethereum has its own diversity question (Lighthouse, Prysm, Teku, Lodestar, Nimbus shares). If the chapter develops the client-diversity-as-security-issue thread, this diagram lands. If not, skip.

Backward:

  • Chapter 1 (drafted): defined intent / settlement / finality. Ch 5 develops what the validator does at each phase.
  • Chapter 2 (drafted): cameoed validators as actors who participate in the AMM/CLOB ecosystem.
  • Chapter 3 (drafted): cameoed the surfaces validators operate on (Solana TPU, Ethereum mempool, the post-Jito-shutdown private mempool surfaces). Ch 5 develops what the validator does with what it sees.
  • Chapter 4 (drafted): cameoed validators as recipients of priority fees and Jito tips. Ch 5 develops the full revenue picture and the role's commercial identity.

Forward:

  • Chapter 6 (Infrastructure Layer, not yet drafted): the firms that build builders, run relays, operate RPC infrastructure. Ch 5 names them in cameo; Ch 6 develops the business.
  • Chapter 7 (Exclusive Order Flow, not yet drafted): the question of what happens when a single firm has both the validator and the searcher relationship. Ch 5 sets up the question; Ch 7 answers it.
  • Chapter 9 (Hyperliquid): the Hyperliquid validator set and HLP economics. Ch 5 cameos; Ch 9 develops.
  • Chapter 10 (Ethereum and L2s): the L2 sequencer-as-validator question; PBS on rollups.
  • Chapter 11 (Who's at a Disadvantage): validators without builder relationships as one of the chronic losers.

Nick's content directive (2026-05-14, post-strawman) ​

Nick added the following direction after reviewing the strawman: Jupiter Beam — though prominent in Ch 3 — is a less-known surface to most readers and should not drive the Solana side of the validator chapter. Instead, the chapter should develop the Solana validator client and scheduler ecosystem in depth. Specifically:

  • The full client stack: Agave (the reference client maintained by Anza), Jito-Solana (the dominant Jito-derivative), Frankendancer (Jump Crypto's hybrid that uses Firedancer's networking stack with Agave's execution/consensus), Firedancer (Jump Crypto's full C/C++ rewrite), and Rakurai (a priority-fee-optimized Solana client used by Figment from March 2026 onward).
  • Scheduler modes — Harmonic ships as multiple builder-selection modes (Balanced, Performance, possibly a Revenue-only mode). Each mode has measurably different priority-fee-capture profiles (Syndica's March 2026 data shows Frankendancer Harmonic Performance at +101% vs median, Harmonic Balanced at +39%, Agave Harmonic at +36%).
  • Firedancer-specific modes — Firedancer / Frankendancer's scheduling configuration may include revenue-optimized, balanced, and performance modes; the chapter should explain what each mode optimizes for and why a validator operator might choose one over another.
  • Voting strategies — Solana validators attest to slot leaders via vote transactions; the timing and selection of which forks to vote for is itself a strategic decision that affects rewards. The chapter should explain the basic voting model and the modern strategic choices validators make (e.g., when to vote, how aggressively, on contested forks).

This directive elevates the Solana validator subsection from cameo-weight to a substantial chunk of the mechanics section. It is the kind of content that distinguishes the book from generic crypto explainers — the named clients, the named scheduler modes, the measurable revenue differences. Treat it as load-bearing.

Beam should be referred back to in passing (the chapter already cites it via Ch 3) but not re-developed.

Tone notes specific to this chapter ​

  • The chapter is structurally adversarial, like Ch 3. Validators are described as the actor whose role was supposed to be neutral plumbing and is not. The Bible's clinical-not-indignant rule still binds — the chapter should describe the shift without taking a side on whether the shift was good — but the structural argument is sharp.
  • Two sidebars (Meet the Validator, Meet the Builder) are the chapter's stylistic anchor. The book has used the sidebar pattern in Chs 2 (Market Maker) and 4 (Searcher). Doing two in one chapter is deliberate: the validator and builder are two faces of what used to be a single role on Ethereum. The sidebars should be drafted in parallel formats (same six fields) so the reader can compare them side-by-side.
  • The TradFi parallel is harder than usual. A validator is closest to a primary dealer or a specialist on a market floor — but the closest equivalent depends on which aspect of the role you're describing. The chapter should lean into the NASDAQ specialist circa 1995 analogy for the validator's discretion-over-ordering function; the PFOF wholesaler analogy for the builder's role in capturing retail flow; the exchange's matching engine analogy for what's automated away. This is one of the chapters where the Bible's "TradFi parallels are your best friend" rule lands hardest.
  • Don't name Figment as the worked-example validator. Figment Q1 2026 research is fair to cite in footnotes (the book is a Figment marketing asset and the research is genuinely useful), but the worked example's validator should be a different named institution — Kiln, Lido (as protocol), Coinbase Cloud, or a generic "a major institutional staking-as-a-service provider." This is one of the chapter's load-bearing editorial constraints; the book's commercial framing is preserved by Figment's restraint about naming itself outside the epilogue.
  • Hyperliquid's validator set is a sensitive topic. The chain runs ~16 validators in a permissioned set, which is a smaller number than most blue-chip L1s but is also the structural reason the chain works. Be precise; don't pejorate; flag the trade-off clinically. Chapter 9 develops the architecture.
  • Be careful about the "MEV-derived revenue as % of validator income" framing on Solana. Figment's Q1 2026 number is ~0.36% — but that's post-April-8-patch and post-collapse in priority fees. The peak was substantially higher. The chapter should state both the peak (cite Helius Vpe data) and the current state (Figment).

Open questions for the agent's Phase 1 research ​

Number these in the research note. The Solana-side questions are weighted more heavily per Nick's content directive above.

Ethereum side:

  • Ethereum validator economics in 2026. Base issuance per validator, typical priority fees, MEV-Boost payment share. Beaconcha.in or rated.network are the likely sources. Need a "typical day" number for a vanilla Ethereum validator.
  • Titan's business model and ownership. Titan builds ~50% of Ethereum blocks in 2026; who runs Titan, who funds it, what's its margin? Coin Metrics and Galaxy Research have written on this; need primary if available.
  • BuilderNet's structure. Multi-operator builder protocol; Flashbots migrated their builder into it in December 2024. How many operators, how are they chosen, what's the revenue model?
  • ePBS roadmap and current state. Glamsterdam (H1 2026 targeted) is supposed to ship ePBS. What's the actual mainnet status as of mid-May 2026?
  • Validator client diversity on Ethereum. Lighthouse, Prysm, Teku, Lodestar, Nimbus shares as of mid-2026.

Solana side — heavy focus per Nick's directive:

  • The full Solana validator client landscape in 2026 — Agave (Anza), Jito-Solana, Frankendancer (Jump Crypto), Firedancer (Jump Crypto's full rewrite), Rakurai. For each: who builds it, what it does differently, current stake-weighted share, the technical and economic argument for choosing it.
  • Harmonic's scheduler modes specifically. Syndica's March 2026 data named three configurations (Balanced, Performance, plain Agave Harmonic) with measurably different priority-fee captures. What does each mode actually do? Does Harmonic publish documentation on these modes? Are there other modes (Revenue-only, etc.) not in the published telemetry?
  • Firedancer / Frankendancer scheduling configurations. Are there user-selectable modes — revenue, balanced, performance — that a validator operator chooses when deploying? Where are these documented?
  • Rakurai specifically. What is it, who built it, what does it do that increased Figment's SRR by 32 bps when they migrated on 2 March 2026? Any technical writeup?
  • Voting strategies on Solana. Validators must attest to slot leaders' blocks via vote transactions. What is the strategic dimension here — when to vote, which fork to vote on, how aggressively to participate? Helius, Anza, or Solana Compass should have writeups.
  • The Jito BAM / Block Engine revenue split for validators. Ch 3 cited the 6% Jito Labs / DAO split; what's the validator share of BAM-mediated MEV revenue?
  • Solana validator economics in 2026. Already have Figment Q1 2026 (MEV ~0.36% of staking rewards). Need broader context — total validator revenue across the network, share of stake on each client variant (covered in Ch 3 research; refresh), and historical comparison (2024 vs 2026).

Hyperliquid side:

  • Hyperliquid validator set. How many validators, how chosen (permissioned or some criteria), what they earn, how HLP affects their economics. Hyperliquid docs are the primary; CoinShares 2026 piece (cited in Ch 2) is the secondary.

Cross-chain:

  • A named non-Figment institutional Solana or Ethereum validator worth featuring in the worked example. Coinbase Cloud, Kiln, Lido (operator set), Allnodes, Chorus One.
  • Slashing rates and incidents. How often does slashing actually happen in 2026? Is it a real risk or a tail one?

Out of scope for this chapter ​

  • Specific MEV mechanics (Chapter 4, already drafted)
  • Liquidity-venue architecture (Chapter 2, already drafted)
  • Mempool / visibility surfaces (Chapter 3, already drafted)
  • Infrastructure-provider business models (Chapter 6 — Flashbots' revenue model, Jito's full business, Helius's RPC pricing, etc.)
  • Exclusive flow arrangements between validators and specific searchers (Chapter 7)
  • Restaking, EigenLayer, AVS economics (Chapter 12 forward-looking content)
  • Slashing-recovery insurance, liquid staking tokens as a derivatives layer (not a book topic)
  • Specific token launchpads, memecoin dynamics, retail behavior (not a book topic)

Keep this chapter focused on what a validator does, what a builder does, who pays them, and why the role's identity has shifted. Everything else is a cameo or a forward link.