The House Edge

Appearance

Chapter 5 — Review Notes (Phase 3 self-check) ​

Status: REVIEW NOTES (Phase 3 — written by agent, accompanying DRAFT.md) Date: 2026-05-14 (revised same day with primary-source Harmonic docs and Firedancer revenue deprecation research — see Revision log) Working chapter: 05 — The Validator (and the Builder) Word count: ≈6,300 words including footnotes (≈5,700 words of prose plus 24 footnotes plus inline Mermaid sequence diagram and the expanded client+scheduler matrix table). Above Ch 3's footprint — the Harmonic-strategies and Firedancer-revenue-deprecation content added in rev 1 needed the room.

Revision log ​

2026-05-14 (rev 3) — Nick pointed out two errors in the Agave central-scheduler paragraph that the original draft had carried forward from the April 2024 Anza blog post:

  1. The priority formula was outdated. The original draft cited ((Priority Fee × CU Requested) + base fee) / (1 + CU Requested) as the Agave priority calculation. The actual code in core/src/banking_stage/transaction_scheduler/receive_and_buffer.rs (current Agave master / v3.1) computes priority = (reward × 1,000,000) / (cost + 1) — where reward is the validator-collected fee net of burn (computed via the full cost-model machinery, not just CU requested × priority fee), and cost is the cost-model's total estimate (signature verification, write-lock acquisition, instruction execution, loaded-data costs — not just CU requested). The v1.18 formula was directionally right in 2024 but is no longer what the code reads.

  2. The "+80% higher fee collection" benchmark was misattributed. That figure was from Anza's v1.18 blog comparing the original prio-graph central scheduler against the thread-local multi-iterator it replaced. It is not a benchmark of central-scheduler-greedy (the current default since v2.3 in mid-2025) against its predecessors. The greedy variant was justified primarily on scheduling-latency and throughput grounds, not on a published "+80% fees" figure.

Nick provided a business-audience rewrite that drops both the formula and the misattributed benchmark in favour of a description of the behaviour (highest fee-per-unit-of-blockspace wins) and the position (default scheduler is the floor; Jito-Solana / Rakurai layer on top to capture incremental revenue). I used Nick's text verbatim with minor stitching for flow with the surrounding paragraphs.

Files updated: DRAFT.md (the Agave scheduler paragraph rewritten in business-audience form; the matrix table cell for Agave rewritten to drop the +80% claim; footnote 8 substantially expanded to walk through the v1.18 → v2.0 → v2.2 → v2.3 → v3.0 → v3.1 scheduler-default progression, the corrected priority formula from the current source, and the attribution of the +80% figure to the original prio-graph central scheduler vs. the thread-local multi-iterator); book/glossary/GLOSSARY.md (Central scheduler entry rewritten to drop the formula and add the two-generation history).

Two other framing items Nick flagged but did not ask to revise here, noted for a possible later pass:

  • "Agave Harmonic" lumped in with client forks. Harmonic is structurally closer to an orderflow/builder-aggregation layer than a client fork — it sits at the validator-selection layer (Chapter 3 already developed this) rather than as a wholesale replacement for Agave's banking stage. The chapter's matrix table currently lists "Agave Harmonic" as a row alongside Jito-Solana / JitoBAM / Frankendancer; that framing is slightly loose. The chapter does develop Harmonic's actual mechanism as a marketplace later in the Solana subsection, so the matrix-table simplification isn't fatal, but worth tightening in a future pass.
  • "~86% of Solana stake on Agave-based clients as of March 2026" is cited to Syndica's March 2026 report. The number is sourced; if it has shifted by the time of publication, Solana Beach or Trillium would be the live-validation paths.

2026-05-14 (rev 2) — Nick gave four content directives: (a) reduce Alpenglow's footprint, (b) develop vote early / vote late voting strategies, (c) research and add Rakurai despite the earlier "ignore Rakurai" directive, (d) integrate Chorus One's timing-games research, and (e) cross-compare Ethereum's past versus its present validator economics. Substantial chapter revision:

Alpenglow reduced from ~500 words (two paragraphs with full Votor / Rotor / VAT / threshold-drop coverage) to ~100 words (a single paragraph framing Alpenglow as a forward-looking event with the full architectural treatment deferred to Ch 12). The glossary entry was correspondingly tightened. The chapter's centre of gravity moves from "what's coming" to "what's happening now."

Voting strategies subsection added. The chapter now develops the pre-TVC "vote late" rationale explicitly — validators delayed votes by 68 slots or more to survey forks and avoid lockouts on losing forks; the practice was "empirically observed, not theoretical" per Anza's own SIMD-0033 motivation document. Post-TVC, "vote early" became the rational default; the Harkness Institute's empirical study documents the vote-latency distribution migrating from the 1.1–2.0-slot bucket into the 1.001–1.01-slot bucket within thirty to forty epochs of activation, but with ~500 validators (~14.6% of stake) still running customised voting logic — "repurposed, not abandoned."

Timing-games subsection added (new H4). Crucially, the chapter now distinguishes vote-attestation timing strategies (vote late / vote early) from block-production timing games (artificially delaying PoH ticking). The latter is Chorus One's August 2025 empirical finding — "Timing Games on Solana: Validator Incentives, Network Impacts, and Agave's Hidden Inefficiencies" — which documents ~+3.0% total rewards (27 bps annualised) for validators that combine timing-games with scheduler optimisation. The research clarifies an architectural truth: Agave's scheduler is the bottleneck, and clients that pack blocks well without timing manipulation (Rakurai, Firedancer/Frankendancer) capture similar gains inside the 400-millisecond target.

Rakurai subsection added. The earlier draft followed Nick's "ignore Rakurai mechanics" directive and treated it only as a row in the matrix table. Nick reversed that directive in this turn. The new Rakurai content includes the firm's background (ex-Apple CEO Ali Rizvi; ASIC/SOC engineering team; $3M Anagram-led seed), the adoption trajectory (2% → 6% of stake from January to March 2026), Figment's published migration on 2 March 2026 with concrete numbers (+32 bps SRR; non-vote tx/block +49%; revenue/block 2.3×; MEV capture ~5×), and the crucial architectural positioning: Rakurai explicitly does not run block-timing games. The Figment migration report calls this out directly. Rakurai is now framed as the "legitimate alternative" for institutional operators who want Jito-comparable economics without the SFDP-compliance ambiguity that timing-game-friendly clients carry.

Ethereum historical-evolution paragraph added in the Ethereum subsection. The chapter now opens that subsection's mechanics with a five-year arc compressed into one paragraph: pre-Merge (2015–2022) PoW miners, with Flashbots' mev-geth quantifying $314M MEV in early 2021 and 84% of hashrate on MEV-geth by April 2021 (cumulative MEV Dec 2019 → Sept 2022: ~$675M / ~400K ETH; the proposer and builder were the same actor); Sept 2022 Merge → MEV-Boost launched within weeks → 90% validator adoption within nine months; mid-2023 OFAC blocks fell from 80% to 27% as non-censoring relays took share; 2024–2026 Titan/BuilderNet/Quasar consolidate. The four-year arc from "no separation" to "three-firm oligopoly" is named explicitly as the chapter's structural argument.

Matrix table updated. Rakurai now has a proper row (was previously labeled but undeveloped). The row includes its 6% March 2026 share, the closed-source-fork framing, the "no timing-game delays" positioning, and the Figment-migration headline numbers.

Glossary additions and updates: new entries for Rakurai (substantial — its background + Figment-migration data + "no timing games" framing) and Timing games (Solana block production) (the Chorus One research with the +3.0% reward / 27-bps headline). Alpenglow entry trimmed correspondingly: shorter Short field, refocused Long field, forward-link to Ch 12 made explicit. New footnotes (1a, 1b, 7a, 7b, 14a, 15a) added to the chapter with sources for each new content block.

Files updated: DRAFT.md (Rakurai subsection, voting-strategies subsection, timing-games subsection [new H4], Alpenglow trim, Ethereum historical paragraph, matrix table row, six new footnotes); book/glossary/GLOSSARY.md (new Rakurai entry; new Timing games entry; trimmed Alpenglow entry). Word count up from ~6,300 (rev 1) to approximately 7,500 (rev 2) — over the Bible's 6,000 target, but the content directives needed the room.

2026-05-14 (rev 1) — Nick shared the primary-source Harmonic documentation page (docs.harmonic.gg/concepts/scheduling-strategies) and pointed out that the Firedancer revenue scheduler mode "was totally a thing but got deprecated" — both critical corrections that required substantive chapter rewrites.

Harmonic correction: The original draft described Harmonic's modes as "Performance" and "Balanced" with "Agave Harmonic" as a third configuration, sourced from Syndica's March 2026 telemetry labels. The primary docs reveal the actual published strategy names are:

  • 50ms FBA with Priority Fee Ordering (SFDP-compliant; ~120–130% of median block rewards) — discrete 50ms windows, within-window sequencing by descending priority fees and tips
  • FIFO (SFDP-compliant; ~90–100% of median block rewards) — continuous strict arrival-order sequencing
  • MREV — Maximum Revenue Strategy (not SFDP-compliant; ~130–150% of median block rewards) — proprietary per-transaction selection logic
  • Custom Scheduler — bespoke, configurable

Plus three architectural commitments ("no sandwiching, no censorship, no malicious MEV") that all strategies operate under, including MREV. And — most striking for the chapter's argument — Harmonic's own documentation explicitly says "MREV is not the network-aligned choice" and was built "in response to direct customer requests from operators with explicit revenue-maximization preferences." This is an unusual degree of self-aware marketing language from a validator-infrastructure firm; the chapter now quotes it directly.

The Syndica telemetry labels ("Frankendancer Harmonic Performance", "Balanced", "Agave Harmonic") are now correctly framed as operator-side buckets that pre-date Harmonic's published strategy names: "Performance" corresponds to MREV based on its revenue characteristics, "Balanced" corresponds to FBA + Priority Fee. The +101%/+39%/+36% priority-fee-over-median numbers are still load-bearing but now attributed correctly.

The SFDP compliance constraint was added as a structural force — validators in the Solana Foundation Delegation Program cannot run MREV. This connects to the Chapter 3 June 2024 enforcement: the foundation's stake allocation is now a soft governance lever over which scheduling strategy a validator can choose.

Firedancer revenue mode story added: The chapter previously hedged on whether revenue was current ("appears in older documentation and operator notes; not confirmed in current Firedancer docs"). Research confirmed:

  • revenue mode was widely deployed alongside perf and balanced through early 2026
  • Per Syndica March 2026 data, ~47% of Frankendancer-Jito stake was on revenue (roughly equal to the 47% on balanced)
  • What it did: filled blocks "extremely lazily, saving most work for the end" — maximised the MEV-reordering window at the cost of block fullness ("regularly unfull blocks")
  • Removed in Frankendancer testnet v0.902.40002 on 21 March 2026 — one of eight bullet points in the release notes, no Jump Crypto rationale published
  • Timing: 8 months after BAM's July 2025 launch; 21 months after the June 2024 Solana Foundation enforcement
  • Migration paths: BAM and Harmonic absorbed the use case

The deprecation has become a substantial paragraph in the chapter rather than a footnote hedge, because the timing and the silence around the rationale tell their own structural story: a major Solana validator-client implementer quietly removed a scheduler mode that ~47% of its users were on, with no public explanation, eight months into the BAM era. The chapter does not over-interpret this — Jump Crypto has not stated the reason and the chapter says so — but the fact of the deprecation is now load-bearing.

Files updated: DRAFT.md (full Harmonic-modes rewrite in §5 Solana; new Firedancer revenue-deprecation paragraph; expanded matrix table with deprecated revenue row and explicit SFDP-compliance column; new footnotes 11a, 12, 12a); book/glossary/GLOSSARY.md (Harmonic entry rewritten with actual strategy names; Pack tile entry updated with the revenue deprecation story).

The chapter's structural argument is unchanged but is materially stronger: the validator's scheduling choice is now visibly a values-and-business decision (SFDP compliance vs MREV revenue), and the firms that build validator infrastructure are visibly negotiating with the foundation's enforcement framework rather than ignoring it.

The eight required questions ​

  1. Could a smart business reader with zero crypto background follow this chapter on first read?Mostly yes, but the Solana subsection is the chapter's densest stretch — denser than Ch 3's Solana section. The chapter introduces five validator clients (Agave, Jito-Solana, JitoBAM, Frankendancer, Firedancer), three scheduler modes (perf, balanced, revenue), Harmonic's three observed configurations (Performance, Balanced, Agave Harmonic), the Timely Vote Credits mechanism, and Alpenglow's coming consensus rewrite — all in one ~1,800-word subsection. The client+scheduler matrix table (D2) is meant to consolidate the load and works well, but the reader who slows down anywhere will slow down here. A reader who got through Chs 3 and 4 will recognise enough of the named institutions (Jito Labs, Anza, Helius, Harmonic) to navigate. A fresh reader on Ch 5 alone would find the Solana subsection challenging.

  2. Is every actor named, and is it clear how each one makes money?Yes. Coinbase Cloud (validator: 12.17% of Ethereum stake; revenue = MEV-Boost payments + commissions), Titan (builder: 51.5% of Ethereum blocks; revenue = wedge between block value constructed and bid paid to proposer), Kiln (institutional validator across 50+ networks), Jump Crypto (Frankendancer / Firedancer developer), Anza (Agave maintainer), Jito Labs (Jito-Solana / JitoBAM / Block Engine; revenue = 6% of BAM tips), Helius (research / largest single Solana validator), Chorus One (Solana operator with named skip rate), the Hyperliquid permissionless-top-21 validator set. Named individuals: Kubi Mensah (Titan), Tim Garcia (Solana Foundation, returning from Ch 3), Justin Drake (Ethereum Foundation), Vitalik Buterin, Hasu.

  3. Is there a worked example with specific dollar amounts threaded through the chapter?Yes, with one acknowledgement. The worked example follows a single Ethereum block — searcher → Flashbots Protect → Titan → Ultrasound Relay → Coinbase Cloud → staker — through the four-actor money flow. The chapter walks the dollar at each step using letter placeholders ($X for block value, $Y for the MEV-Boost payment) plus concrete sourced numbers (Titan's 17.75% margin, Coinbase Cloud's 99.98% participation rate, etc.). The acknowledgement: the chapter does not anchor to a specific dollar figure for any single block, because relayscan.io's per-block revenue distribution is wide and varying. The chapter's structural argument doesn't require a specific block's dollars to land; the four-actor flow itself is the load-bearing content.

  4. Does the chapter end with a clear "who wins, who loses" verdict?Yes — sharper than Ch 1 or 2, comparable in tone to Ch 3 and Ch 4. The closing observation about Coinbase Cloud's optional OFAC SDN filtering is the chapter's most pointed structural fact — "roughly 12% of Ethereum's stake is now run by a validator operator that can selectively decline to include sanctioned-address transactions." The chapter forwards the censorship-resistance-versus-extraction-resistance trade-off to Chapter 11 rather than resolving it here.

  5. Are all numbers sourced in footnotes?Yes. 22 footnotes. Every dollar figure, percentage, validator count, stake share, and named incident has a footnote with URL and access date. The two flags where the chapter explicitly hedges: (a) footnote 11 acknowledges that the Firedancer revenue scheduler mode appears in older documentation but is not confirmed in the current source tree; (b) footnote 16's Alpenglow timeline is committed but the mainnet date is "expected" rather than scheduled.

  6. Does the chain comparison box exist and contain real differences?Yes. Three paragraphs in §6, each making structurally different points: Solana (validator = both proposer and constructor; client choice is the moat); Hyperliquid (validator = small permissionless-top-21 set; no PBS surface to separate); Ethereum + L2s (validator = proposer but not constructor; ~91% of blocks built by three firms; L2 sequencers replace the validator role at the rollup level). Plus the slashing-record observation as the operational-excellence anchor — fewer than 500 validators slashed since 2020 against >1.2M active validators, with the September 2025 SSV 39-validator cluster as the cleanest single incident.

  7. Did I avoid every banned move from the Book Bible?Yes, with one flagged near-miss.

    • No hype words. No doom words. No "Web 1.0." No throat-clearing. No tribal chain endorsements. Specific firms named, specific dollar amounts, specific dates.
    • Near-miss: The verdict's framing of the validator role as "bifurcated into a signing function (still mostly neutral) and an ordering function (commercial)" is editorial-by-degrees. It is a synthesis claim, not a direct citation. I think it is defensible — the chapter spent 5,000 words documenting the bifurcation with sourced data — but it pushes the structural-not-adversarial framing.

  8. Would the Goldman MD finish this chapter without checking her phone?I think so, with reservations on the Solana subsection. The Merge → MEV-Boost timeline in the cold open is exactly the kind of historical anchor a TradFi reader will respond to. The Mermaid sequence diagram in §5 Ethereum gives her something to look at when the PBS architecture is being explained. The two sidebars (Meet the Validator + Meet the Builder) are short and useful. The Solana subsection is the chapter's densest stretch; the client+scheduler matrix table helps but the prose still asks her to track five named clients and multiple scheduler modes in sequence. The verdict — including the Coinbase Cloud OFAC closing — is the kind of clean observation she will appreciate. The 5,800-word total is at the top of the range but justified by the directive.

What changed between phases — and what's load-bearing ​

Claims dropped from RESEARCH.md ​

  • Rakurai mechanics. Per Nick's explicit "ignore Rakurai" directive in the proceed message. Rakurai appears once in the client+scheduler matrix table (with its 6%-of-stake share noted) and is referenced once in the prose flow but never developed. No primary research on Rakurai was conducted.
  • Coin Metrics / specific quantitative Ethereum-validator-day revenue numbers in May 2026. Figment's Q3 2025 figures are the most recent published; mevboost.pics and beaconcha.in were referenced in the research but the chapter uses Block Scholes's APY framing rather than a specific May 2026 daily-revenue number. The structural argument doesn't require it.
  • Specific Lido operator-set details. Lido was named as a curated-operator-set protocol in the institutional-validator paragraph but the chapter does not develop CSM v2 or the named-operator roster in detail. That belongs in Chapter 7 (Exclusive Order Flow) or Chapter 11 (chronic losers).

New claims added in the draft (and where they came from) ​

  • The chapter's structural claim that the validator role has "bifurcated into a signing function (still mostly neutral) and an ordering function (commercial)" — synthesis, supported by the cited data but not stated directly in any source. The chapter's central argument.
  • The "a validator running stock Agave with default settings, no Harmonic, no BAM, and no relationship with Ethereum builders is measurably earning less than half of what a sophisticated operator earns" framing — defensible from the Syndica March 2026 data (Harmonic Performance +101% vs median; the Figment migration +18 bps SRR on a single client switch) but composed by the chapter rather than directly cited.
  • The "Coinbase Cloud's OFAC-filtering option as the chapter's closing structural observation." Sourced via Coinbase's published policies (footnote 22). The framing — that 12% of Ethereum stake is run by an operator that can selectively decline sanctioned-address transactions — is the chapter's pointed reading of that policy.
  • The four-actor flow as the worked example's organising structure. The "which of these four actors is doing what the original Ethereum white papers meant when they said 'validator'?" question is the chapter's editorial anchor. The four-actor flow is documented; the question is the chapter's.

Things I'm uncertain about ​

  1. The Firedancer revenue scheduler mode. Footnote 11 hedges this. If the current Firedancer source tree confirms revenue is still an option, the chapter's prose stands; if it has been deprecated or folded into a Jito-specific build, the chapter's prose remains correct because of the hedge. Worth a primary-source verification before publication.
  2. The Alpenglow validator-threshold drop. Helius's modelling (cited footnote 17) is the source for "from ~$800K to ~$75K." This is a model estimate, not a measured outcome. The chapter says "Helius's modelling suggests" rather than asserting the drop. If Alpenglow ships and the actual threshold turns out different, the chapter's framing survives.
  3. Coinbase Cloud as the worked-example anchor vs alternatives. I considered Kiln. Coinbase Cloud's 12.17% network share is larger and more salient; Kiln's multi-chain reach is more diverse. Coinbase Cloud wins on the named-validator-for-Ethereum criterion. Reversible.
  4. The 80% fee-collection figure for Agave's central scheduler. This is Anza's own benchmark from the v1.18 release era; whether it still holds in 2026 with the additional Jito and Harmonic optimisations isn't separately validated. The chapter cites it as a historical performance claim.
  5. The "block-time-adjusted" interpretation of Harmonic mode telemetry. Syndica reports both unadjusted and block-time-adjusted numbers. The chapter uses the unadjusted +101% / +39% / +36% as the headline because they are the operator-facing figure; the block-time-adjusted +28% / +32% / +33% reverses the ordering (Performance becomes lowest, Agave Harmonic becomes highest). The chapter does not develop the block-time-adjustment paradox; it's flagged here as a methodological subtlety that a careful reader might catch.
  6. Two sidebars in one chapter. No prior chapter has done this. The format works because the validator and builder roles split out of a single role on Ethereum; reading the sidebars side-by-side makes that history concrete. But if the chapter feels heavy with two formal sidebars, the Builder sidebar could be folded into the Ethereum subsection prose without significant content loss.

Places where the prose got technical and might lose the reader ​

  • The Solana client + scheduler section. Five named clients (Agave, Jito-Solana, JitoBAM, Frankendancer, Firedancer) plus three scheduler modes (perf, balanced, revenue) plus three Harmonic configurations (Performance, Balanced, Agave Harmonic) is 11 named entities to track. The matrix table (D2) consolidates them but the prose density is real. Worth reading aloud to confirm the transitions land.
  • The Alpenglow paragraph. Two new components (Votor, Rotor) plus the VAT economic mechanism plus the two-path finality timing plus the profitable-validator threshold drop. I broke this into two paragraphs to give the reader a breath; could break further if it feels rushed.
  • The "Frankendancer migration as empirical anchor" paragraph. Eight specific numbers in a single 80-word stretch (Epoch 871, +18 bps, peak +28, 9×, 2.5×, 57%, 20%, 0.6 → 1.2, +18% duration, 41 → 145 failed tx). The Figment migration is the cleanest single empirical case for "client choice is the moat" — but the density is at the limit of what prose can carry. A table version would be cleaner; the chapter's choice was to keep it as prose because the migration is a single moment in time, not a recurring comparison.

Files written/modified in Phase 3 (this chapter) ​

  • book/chapters/05_validator/DRAFT.md — new, ≈5,800 words (22 footnotes; inline Mermaid sequence diagram for Ethereum block flow; client+scheduler matrix table; Meet the Validator + Meet the Builder sidebars as parallel-format ::: info blocks)
  • book/glossary/GLOSSARY.md — appended 18 entries: Agave, Alpenglow, Central scheduler (Solana), ePBS, Firedancer, Frankendancer, Pack tile (Firedancer), PBS / Proposer-Builder Separation, Proposer (Ethereum), Rotor, Slashing, Slot leader (Solana), Staking Reward Rate (SRR), Timely Vote Credits (TVC), Validator, Validator Admission Ticket (VAT), Validator client, Votor. Now 68 total entries.
  • book/OUTLINE.md — Chapter 5 entry updated with subtitle and final section headings.

No back-edits to prior chapters this time. Chapter 3's Hyperliquid corrections and Chapter 4's April-8-patch citation were both resolved in their respective revisions.

Phase 3 is complete. The chapter is now in Nick's review queue.

Per production order, the next chapter to draft is Chapter 6 — The Infrastructure Layer (Jito, bloXroute, Astralane, Eden, Temporal / Nozomi / Harmonic on Solana; Flashbots, Titan, beaverbuild on Ethereum). Chapter 5 names many of these institutions; Chapter 6 develops the business behind them.