The House Edge

Appearance

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 bids that other firms — specialised builders — constructed and outbid each other to deliver.[1] 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.

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?

The setup ​

A validator, in the simplest terms, is an operator who stakes a chain's native token in exchange for the right to participate in block production and earn a share of the network's revenue. On Ethereum, the stake is at least 32 ETH per validator; on Solana, a validator runs a node that accumulates delegated stake from any holder willing to delegate; on Hyperliquid, the top 21 stakers by total delegated balance form the active set.

In each of these chains' founding documents, the validator was framed as a participant whose discretion was bounded by the protocol. The protocol said which transactions were valid; the protocol said when a block was due; the validator's job was to follow the rules and take their share. The framing — useful in the years when the protocols were being built and the stakes were small — has not survived contact with markets in which a single block can be worth tens of thousands of dollars.

The role has now bifurcated in different ways on each chain. On Ethereum, the proposer-builder separation that began as an out-of-protocol optimisation is now the dominant pattern: the validator proposes the block, but a specialised firm called a builder constructs it. On Solana, the validator is still the slot leader and still constructs the block, but the software the validator runs — the validator client and its scheduler configuration — has become the largest single determinant of revenue. On Hyperliquid, the validator set is small and permissionless-but-elected; the matching engine sits inside consensus, so there is no block-builder role to separate.

Two characters carry the chapter. Coinbase Cloud, which runs roughly 12.17% of all staked ETH — 4.5 million ETH across data centres in Germany, Hong Kong, Ireland, Japan, and Singapore — is the chapter's Ethereum validator anchor.[2] Titan, the firm that constructs approximately 51.5% of Ethereum blocks, is the builder.[3] A single block in May 2026, signed by Coinbase Cloud and constructed by Titan, will get the chapter from the four-actor dollar flow it sets up here to the structural argument it lands by the verdict.

The worked example ​

It is a Tuesday afternoon in May 2026. A searcher has identified an arbitrage opportunity: the price of ETH/USDC on Uniswap V3 has briefly diverged from the price on a centralised exchange by about 8 basis points. The searcher constructs a bundle — a buy on Uniswap, a sell on the CEX-hedged side — and submits it through Flashbots Protect. The bundle does not enter the public mempool. It is forwarded directly to Titan as a private transaction.

Titan, running specialised low-latency hardware in a data centre co-located with the major Ethereum relays, receives the bundle along with several hundred thousand other transactions and bundles in the same slot window. Titan's software constructs a candidate block — the most valuable arrangement of available transactions it can find, including the searcher's bundle if the bundle is profitable enough to include. The candidate block has a total value: the sum of priority fees the included transactions pay, plus any MEV the bundle captures. Call that block value $X.

Titan then bids on the right to have this block proposed. The bid goes through a relay — in this case Ultrasound Money, the largest Ethereum relay by share. The relay forwards the bid to Coinbase Cloud, which has been scheduled by the protocol to propose this slot's block. Coinbase Cloud sees several bids from competing builders — Titan, BuilderNet, Quasar — and selects the highest. It signs the corresponding block header. The block is published, validated, and finalised.

The dollar flow runs in a specific order. Titan paid Coinbase Cloud some fraction of $X to win Coinbase Cloud's signature — call it $Y, the MEV-Boost payment. Titan keeps $X minus $Y minus the searcher's share. The searcher's profit on the bundle is paid out of the arbitrage spread net of the priority fees and Titan's take. Coinbase Cloud then distributes $Y after taking its commission (typical institutional commission is 5–8%) to the staking customers whose ETH was delegated to that validator slot.

The chapter's question, asked once and asked again at the verdict: which of these four actors — the searcher, the builder, the validator, the staker — is doing what the original Ethereum white papers meant when they said "validator"?

The mechanics, in detail ​

Ethereum: the proposer who doesn't build the block ​

Before September 2022, Ethereum validators were miners. They received transactions from the public mempool, picked the highest-priority-fee subset that fit in a block, hashed their way to a proof-of-work, and earned the block reward plus the included transactions' fees. The block construction logic was simple, deterministic, and ran inside the same software the validator used to validate.

Three months after the Merge, on 7 November 2022, Flashbots launched MEV-Boost as an out-of-protocol optimisation: validators could outsource block construction to a builder, who would run specialised software to extract more value from the available transactions than the validator's vanilla client could. The validator would receive a payment in exchange for signing the builder's block. Within nine months more than 90% of Ethereum validators had adopted MEV-Boost. The architectural pattern — proposer-builder separation, or PBS — was settled.[1:1]

The shift compresses a five-year arc the chapter is worth pausing to name in full. Pre-Merge — from Ethereum's mainnet launch in 2015 through September 2022 — the block-producer was a proof-of-work miner, the role was monolithic, and the concept of a "builder" did not exist as a separate actor. Miners earned the block reward plus the included transactions' fees and selected which transactions to include from the public mempool. The MEV opportunity was discovered (Dan Robinson and Georgios Konstantopoulos's Ethereum is a Dark Forest in August 2020 was the public framing) and Flashbots' mev-geth client launched November 2020 as the formal infrastructure for extracting it; Flashbots' own Q1 2021 reporting put Ethereum MEV at $314 million extracted between January 2020 and early 2021, with a single bundle paying a 101 ETH tip to one mining pool. By April 2021, more than 84% of Ethereum hashrate was running MEV-geth. Cumulative MEV from December 2019 through the Merge in September 2022: approximately $675 million across 400,000 ETH.[4] On the day of the Merge — block 15,537,393, 15 September 2022 — the proposer and the builder were still the same actor, as they had been for all seven years prior. By 7 November 2022 they were not. By the middle of 2023, the OFAC-Tornado-Cash debate had drawn the first regulatory line across the validator-builder-relay stack — at peak in November 2022, approximately 80% of Ethereum blocks were OFAC-compliant; by mid-2023 that share had fallen to roughly 27% as non-censoring relays like Ultra Sound Money and Agnostic took share. Validators no longer just signed; they chose which relays to trust.[5] By 2024, builder concentration had begun to take its present shape. The four-year arc from "no separation" to "three-firm oligopoly" is, in the historical span of financial-market structure, very fast.

By 2026 the builder market on Ethereum has consolidated sharply. The relayscan.io live snapshot for the 24 hours ending 14 May 2026 shows Titan at 51.53% of all Ethereum blocks, BuilderNet at 24.07%, and Quasar at 15.34% — the top three builders accounting for roughly 91% of mainnet blocks.[3:1] Beaverbuild, once one of the largest standalone builders, has migrated its operation into BuilderNet — the multi-operator builder protocol Flashbots itself joined in December 2024 when Flashbots stopped operating a centralised builder.[6]

Meet the Builder

Job: Construct blocks from the available pool of transactions, searcher bundles, and private order flow; bid for the proposer's signature via a relay.

How they earn: The wedge between the value of the block they construct (priority fees plus MEV captured) and the bid they pay the proposer. Titan's published profit margins under exclusive flow arrangements — such as its agreement with the Banana Gun trading bot — have reached approximately 17.75%, materially higher than Beaverbuild's pre-migration margin of approximately 9%.[7]

How they spend: Low-latency hardware co-located with the major relays; in-house transaction simulators that price every candidate block in milliseconds; engineering teams writing bundle-merging and conflict-resolution logic; private order-flow relationships with searchers, RPC providers, and aggregator solvers.

The moat: Access to private order flow. Chapter 3's structural argument lands here. The builder that sees the most pending transactions earliest constructs the most valuable block, and value cascades up.

TradFi analogue: A payment-for-order-flow wholesaler — Citadel Securities, Virtu Financial — except that on-chain the wholesale auction happens at the block-construction layer rather than at the broker-routing layer, and the searchers being internalised against are anonymous on-chain bots rather than retail brokers' customers.

The protocol-level fix for the builder concentration is enshrined PBS (ePBS), proposed in EIP-7732 and selected as the headliner for Ethereum's Glamsterdam upgrade, originally targeted at the first half of 2026. As of the Ethereum Foundation's April 2026 Checkpoint #9 update, Glamsterdam has not shipped: "Glamsterdam in Q2 seems to me to be unlikely." Implementation has proved trickier than anticipated, with partial blocks and two-party consensus coordination as documented bottlenecks. No firm replacement target has been published.[8] The structural argument is straightforward: when PBS lives inside the protocol, the proposer's choice of builder becomes a protocol-defined market rather than an out-of-protocol auction; the structural concentration around Titan / BuilderNet / Quasar would be replaced by a wider competitive surface that anyone running a builder could enter. Whether ePBS will deliver that competition or simply re-encode the existing oligopoly is the question that has kept the upgrade from shipping.

Solana: the client stack is the moat ​

On Ethereum, the validator outsources block construction. On Solana, the validator is the block constructor — but the construction logic is determined by the software the validator chooses to run. The Solana validator's largest single revenue lever in 2026 is not its hardware, its geography, or even its stake; it is the choice of validator client and scheduler mode.

Solana's stake-weighted validator-client distribution in March 2026 was: Agave Jito 32%, Agave JitoBAM 28%, Agave Harmonic 17%, Agave Rakurai 6%, Frankendancer (Jump Crypto's hybrid) 12%, Firedancer (Jump's full C/C++ rewrite) 2%. Roughly 86% of stake runs Agave-based clients (including the Rakurai fork); the remaining 14% runs Jump Crypto's stack.[9]

The reference Solana client is Agave, maintained by Anza (the team that spun out of Solana Labs to focus on the validator client). Agave ships with a built-in scheduler called central-scheduler-greedy — the component that decides which transactions a validator includes in a block, and in what order, when it is the validator's turn to lead. The scheduler ranks transactions primarily by what the validator earns from each one relative to how much of the block's capacity that transaction consumes; in practice, transactions paying higher priority fees relative to their on-chain footprint win the auction for blockspace. This default behaviour is what every standard Agave-based validator does out of the box. Specialised forks — Jito-Solana, Rakurai, and the variants further developed in this chapter — layer additional logic on top: auctioning blockspace to searchers, accepting bundled transaction flows, packing the block more aggressively, optimising the cost-model handling of individual transaction types. That incremental logic is how validators on those clients capture revenue beyond the baseline; the default scheduler is the floor.[10] When the book uses the phrase "the default Solana client," this is what it means.

The Agave codebase is forked in several directions. Jito-Solana is the Jito Labs fork that integrates the Jito Block Engine — the bundle auction surface Chapter 4 named — into the validator client itself, allowing the validator to receive prioritised bundles from searchers directly. JitoBAM, the BAM-enabled variant, takes this one step further: the validator's transaction-sequencing function is delegated to BAM Nodes running inside AMD SEV-SNP TEE enclaves, while the validator handles only execution. The 28% of stake on JitoBAM in March 2026 is the cleanest measurement of how much of the network has adopted BAM at the client level.[11]

The Jump Crypto entries are structurally different. Frankendancer is a hybrid client: it replaces Agave's networking layer (where the bottleneck for Solana validator performance increasingly lives) with Firedancer's lower-level C/C++ networking stack while keeping Agave's consensus and execution layers. Firedancer, the firm's full C/C++ rewrite of the entire validator stack, is what Frankendancer is meant to lead into. As of October 2025, approximately 20.94% of Solana stake was running Frankendancer; by March 2026 that share had stabilised around 12% as some operators migrated onward to JitoBAM and Harmonic rather than persist on the Jump stack.[12] Pure Firedancer remained at approximately 2% of mainnet stake — adoption has been slower than expected, with most operators preferring the Frankendancer hybrid for production use.[9:1]

The structural argument the chapter has been building lives in the scheduler modes the Firedancer/Frankendancer client publishes. The pack tile — the component that decides transaction ordering within a slot — supports two named modes:

  • perf mode: "fill the block as fast as possible using the highest-paying transactions available." Produces "consistently 100% full blocks." Optimised for maximum throughput and priority-fee capture per slot.
  • balanced mode (the default): "optimizes for revenue from priority fees, but can result in blocks that are not always 100% full, and can be poor at capturing MEV if using an external block builder." The documentation explicitly recommends reverting to balanced under network congestion.[13]

Until very recently, a third mode — revenue — was widely deployed alongside perf and balanced. The revenue scheduler filled blocks "extremely lazily, saving most work for the end," which had two effects: it maximised the window for high-fee transaction reordering, yielding higher MEV revenue; and it produced "regularly unfull blocks," which is bad for network throughput. Syndica's March 2026 data shows that approximately 47% of Frankendancer-Jito stake was running revenue mode at that point — roughly equal to the 47% running balanced. On 21 March 2026, Frankendancer testnet release v0.902.40002 included "Remove revenue scheduler" as one of eight bullet points in the release notes, with no accompanying rationale. The current Firedancer documentation lists only perf and balanced. Jump Crypto has not publicly explained the removal; the timing — eight months after BAM's July 2025 launch and twenty-one months after the Solana Foundation's June 2024 enforcement against private mempools — places the deprecation inside the broader 2024–2026 sequence of architectural responses to value extraction, but does not directly attribute the change to any single event. Validators who relied on revenue mode have either adapted their codebase, migrated off it or chose alternative schedulers.[14]

Rakurai is a separate fork of Agave, maintained by a small team whose engineering background is in ASIC and system-on-chip design rather than crypto-native infrastructure. The firm raised a $3 million seed in 2025 led by Anagram Ventures (with participation from Slow Ventures, Robot Ventures, Crypto.com, P2P.org, GlobalStake, and Cyber Fund), and CEO Ali Rizvi is ex-Apple. The fork is closed-source, which has slowed its adoption: as of January 2026 Rakurai ran approximately 2% of network stake, rising to approximately 6% by March 2026 as named institutional operators migrated.[15]

Rakurai's performance numbers are the chapter's cleanest second empirical anchor (after the Figment Frankendancer migration). Figment migrated its main validator to Rakurai on 2 March 2026 and reported the following within two epochs: Staking Reward Rate rose from 6.85% to 7.17% (a 32-basis-point increase); non-vote transactions per block rose 49%; compute units per block rose 48%; total revenue per block rose 2.3× to 0.083 SOL; validator rewards rose 54%; priority fees rose 60%; MEV capture rose approximately five-fold.[16] Syndica's data shows Rakurai-running validators capturing 22–25% more total rewards than the typical Solana validator, with tip capture up 158% at the median and 55% at the 95th percentile.

The architectural argument Rakurai makes — and the reason it matters for the next subsection — is that the firm explicitly does not run block-production timing games. Figment's published migration analysis is explicit: Rakurai "do[es] not resort to block timing game manipulation with intentional delays past the target block time of 400ms." Block production stays inside the protocol's 400-millisecond target. The performance gains come from scheduler optimisation alone — better packing, better priority-fee ordering, better handling of compute-unit budgets. Rakurai is positioned as the legitimate alternative for institutional operators who want Jito-comparable economics without the operational ambiguity that comes with timing-game-friendly clients.

At the validator-selection layer, Harmonic — the open block-building marketplace Chapter 3 introduced — ships three off-the-shelf scheduling strategies plus a custom-build engagement, with significantly more architectural transparency than Firedancer's pack tile:

  • 50ms FBA with Priority Fee Ordering (SFDP-compliant). Discrete 50-millisecond batches; transactions collected in each window are sequenced by descending priority fees and tips at window close. Captures approximately 120–130% of median block rewards. The Frequent Batch Auction design — drawn from market-microstructure research — neutralises sub-millisecond latency races: two transactions arriving 1ms apart inside the same 50ms window are treated as if they arrived simultaneously.
  • FIFO (SFDP-compliant). Continuous strict arrival-order sequencing with no fee or tip influence on the order. Captures approximately 90–100% of median block rewards — fees and tips are still earned but do not buy priority.
  • MREV (Maximum Revenue Strategy — not SFDP-compliant). Streaming, proprietary per-transaction selection logic. Captures approximately 130–150% of median block rewards, the highest of the off-the-shelf strategies. Harmonic's own documentation is explicit that MREV "is not the network-aligned choice" and was "built in response to direct customer requests from operators with explicit revenue-maximization preferences" — a striking degree of self-awareness in marketing copy for a validator-infrastructure product.
  • Custom Scheduler: bespoke strategies built and operated by the Harmonic team for customers with specific requirements (batch cadence, ordering rule, bundle handling, revenue routing all configurable). [17]

Every Harmonic scheduling strategy operates under three architectural commitments framed in the documentation as "non-negotiable constraints": no sandwiching, no censorship, no malicious MEV. These apply to all three off-the-shelf strategies including MREV, which "optimizes for revenue within the same red lines as every other Harmonic strategy." The structural significance: a validator can choose MREV for higher revenue without architecturally enabling the sandwich-attack surface that the Jito mempool shutdown was trying to compress.

Syndica's March 2026 telemetry tracks Harmonic-running validators under operator-side labels that pre-date the published strategy names: Frankendancer Harmonic Performance (which corresponds to MREV based on its revenue characteristics) earns approximately +101% priority fees per block versus the network median; Frankendancer Harmonic Balanced (FBA + Priority Fee) earns approximately +39%; Agave Harmonic (also FBA + Priority Fee, on the Agave client) earns approximately +36%. The Performance configuration's lift is real but comes with a block-time cost: median block duration around 618 milliseconds versus the network typical of approximately 400ms. The latency-versus-revenue trade-off is observable in the data.[18]

The SFDP compliance constraint is itself a structural force. Validators participating in the Solana Foundation Delegation Program — the foundation's stake-allocation program the Chapter 3 enforcement action attached to — cannot run MREV. They can run FBA + Priority Fee, FIFO, or a Custom Scheduler designed to maintain SFDP compliance. The compliance constraint operates as a soft network-governance lever: validators who want the foundation's delegation must choose the SFDP-compliant strategy set, even when MREV would earn measurably more. The framing in Harmonic's own documentation — that MREV is "not the network-aligned choice" — is the firm acknowledging this constraint upstream.

A consolidated view of the Solana validator client + scheduler landscape in March 2026, with the deprecated Firedancer revenue mode noted for historical completeness:

Client + schedulerBuilt byStake share (Mar 2026)Default schedulerKey revenue characteristic
Agave (default)AnzaBaselinecentral-scheduler-greedyRanks transactions by validator-earned reward per unit of blockspace consumed; the floor that all other clients build on[10:1]
Agave JitoJito Labs (Agave fork)32%central-scheduler-greedy + Jito Block Engine integrationBundle auction surface; Jito tips capture
Agave JitoBAMJito Labs28%BAM Nodes (TEE-encrypted sequencing) + Agave executionConfidential block construction via AMD SEV-SNP enclaves
Agave HarmonicAnza fork + Harmonic FBA+Priority Fee17%Validator-side block selection from multiple builders+36% priority fees vs network median; SFDP-compliant
Agave RakuraiRakurai (Agave fork)6% (Mar 2026, up from 2% Jan 2026)Closed-source priority-fee + scheduler optimisation; no timing-game delaysFigment migration (2 Mar 2026): +32 bps SRR; +60% priority fees; ~5× MEV capture; tip capture +158% at median
Frankendancer + Jito balancedJump Crypto (hybrid)~47% of FD-Jitopack tile balanced + Jito integrationDefault mode; revenue-optimised within block-fullness constraints
Frankendancer + Jito revenue (deprecated 21 Mar 2026)Jump Crypto~47% of FD-Jito pre-deprecationpack tile revenue + Jito integrationLazy-fill scheduler; higher MEV revenue, regularly unfull blocks; removed in v0.902.40002
Frankendancer + Harmonic FBA+Priority FeeJump + Harmonic(subset of FD stack)Harmonic FBA+Priority Fee strategy+39% priority fees vs median; SFDP-compliant; ~120–130% of median block rewards
Frankendancer + Harmonic MREVJump + Harmonic(subset of FD stack)Harmonic MREV strategy+101% priority fees vs median; ~618ms block latency; ~130–150% of median block rewards; not SFDP-compliant
FiredancerJump Crypto (full rewrite)2%pack tile (perf or balanced)Production adoption slow; full performance gains not yet measurable at network scale

The empirical case for "client choice is the moat" lands most cleanly in published operator data. Figment, the institutional staking-as-a-service provider, migrated its main Solana validator to Frankendancer at epoch 871 on 30 October 2025. The firm's own published post-migration analysis reports the gross Staking Reward Rate rising by 18 basis points (peak +28), MEV and Jito tips rising 9×, priority fees rising 2.5×, total compute-units per block up 20%, and revenue per compute unit doubling from 0.600 to 1.200. The trade-offs are real — median block duration rose 18% (from 355.7ms to 398.4ms), failed transactions per block rose from 41 to 145 — but the net is unambiguous: a single client switch, with no change to hardware, stake, or operator practice, produced a meaningfully higher revenue regime.[19]

Meet the Validator

Job: Stake the chain's native token, run validator software, participate in block production for issuance and fees.

How they earn: Base issuance (chain-defined inflation share); priority fees from the transactions they include in blocks they propose; MEV-derived revenue — MEV-Boost payments on Ethereum, Jito tips and BAM tips on Solana; commissions from delegated stake if running staking-as-a-service.

How they spend: Hardware (high-spec servers in multiple geographies); bandwidth (the modern Solana bottleneck); engineering time on client choice, scheduler configuration, and voting strategy; opportunity cost of locked stake; slashing-loss tail risk.

The moat: Increasingly, not raw uptime. The moat is the choice of validator client and scheduler mode (Jito-derivative versus Frankendancer versus Firedancer on Solana; Lighthouse versus Prysm versus Teku on Ethereum); the relationships with block-construction firms (Titan, BuilderNet, Quasar on Ethereum; Jito, Temporal on Solana); and the geographic placement of infrastructure relative to relays and slot leaders.

TradFi analogue: A specialist on the floor of the New York Stock Exchange circa 1995 — the actor with privileged information access who handled order matching for one or more tickers, earning a share of the spread, with operational discipline as the visible criterion but information relationships as the actual moat.

A third revenue lever, separable from client choice and scheduler mode, is voting strategy. Solana validators attest to slot leaders' blocks via vote transactions, and the timing of those votes is now itself a strategic variable.

For most of Solana's history, the strategy that paid was "vote late." Before Timely Vote Credits (SIMD-0033, approved by validator vote in mid-2024 and activated on mainnet at epoch 703 in November 2024), validators earned a full vote credit for any correct vote received within approximately 2.5 minutes of the voted block. Some operators exploited this: a validator could "lag their consensus votes" by 68 slots or more — surveying multiple competing forks and waiting until the supermajority confirmed one — and still earn full credits while avoiding the lockout penalty that comes with voting on a losing fork. The Anza documentation describing TVC's motivation states this directly: pre-TVC validators could "delay their voting for many slots to survey forks and wait to make votes that are less likely to be expired without incurring any penalty," and the behaviour was "empirically observed, not theoretical."[20]

Post-TVC, the strategy inverted. The maximum 16 credits per vote now require landing inside a two-slot window — roughly 800 milliseconds of wall-clock latency. Each additional slot of vote latency costs one credit, down to a floor of 1 credit at 18 or more slots. Voting early is now the rational default: a validator who voted late under the old regime would, under TVC, leave most of its vote credits on the table. The Harkness Institute's empirical study of post-TVC behaviour found that within thirty to forty epochs of activation, the stake-weighted distribution of vote latencies migrated from the 1.1–2.0-slot bucket into the 1.001–1.01-slot bucket; among ten identified validators that had been running vote-delay code, "abnormal delays decreased by roughly 60–70%" — but the modifications themselves were "repurposed, not abandoned," with approximately 500 validators (about 14.6% of stake) continuing to run customised voting logic.[21] Chorus One — one of the larger named institutional operators — reports a Solana skip rate of approximately 2.03%, against a network average of 5.19% and a superminority-validator average of 5.68%.[22] The gap is the post-TVC moat operationalised: faster hardware, better geographic placement, and tighter client configuration push the vote latency below the 2-slot threshold consistently. Operators who cannot meet that latency target leak credits.

Timing games — block production, not voting ​

A separate strategic dimension, identified by Chorus One's August 2025 empirical research, lives at the block-production layer rather than the vote-attestation layer. The research — titled, with notable directness, "Timing Games on Solana: Validator Incentives, Network Impacts, and Agave's Hidden Inefficiencies" — documents that some Solana validators artificially delay Proof-of-History ticking to extend the duration of their slot beyond Solana's nominal 400-millisecond target. The mechanism is not stealing transactions from the next slot's leader; it is giving the validator's own scheduler more wall-clock time to pack the current slot with high-priority-fee transactions and Jito bundles before the block closes.[23]

The economic payoff is measurable but small: combined timing-games-plus-scheduler-optimisation produced approximately +3.0% in total rewards (about 27 basis points annualised); timing games alone produced approximately +1.19% (about 8 basis points); scheduler optimisation alone produced approximately +1.4% (about 12 basis points). The network-level cost is a reduction in effective inflation — extended slots translate to slower epochs, which translates to roughly 80% of nominal inflation at 500-millisecond slot times. Chorus One's recommendation, that the reward mechanism be redesigned (through pooling or redistribution) to neutralise the timing-game incentive, has not been adopted. The research did clarify one architectural truth the chapter has been building toward: Agave's scheduler is the actual bottleneck. Clients that pack blocks well without timing manipulation — Rakurai and Firedancer/Frankendancer — capture similar gains while staying inside the 400-millisecond target. Rakurai's positioning as the "no timing games" alternative reads, in this context, as a direct response to the Chorus One findings.

Looming over the present configuration is Alpenglow (SIMD-0326), the consensus-layer rewrite Solana approved in August 2025 and activated on testnet on 11 May 2026, with mainnet expected in late Q3 or early Q4 2026. Alpenglow's load-bearing effects on the validator role — removing vote transactions from blockspace (currently approximately 70% of all Solana transactions at peak), introducing a Validator Admission Ticket as the first explicit per-epoch fixed validator cost, and modelled to drop the profitable-validator stake threshold roughly tenfold — restructure the economics this chapter has been describing. The full architectural treatment, including the timing of the change and what it implies for the next equilibrium, is Chapter 12.[24]

Hyperliquid: the permissioned set that sidesteps PBS entirely ​

Hyperliquid's validator architecture is structurally different from Ethereum's or Solana's in a single load-bearing way: the matching engine runs inside consensus. There is no separate transaction-sequencing layer, no block-construction outsourcing, no relay infrastructure. Validators participate in HyperBFT consensus, the matching engine matches orders as it runs, and the chain's perpetuals exchange — the venue's actual product — settles inside the same loop.

The chain operates a delegated proof-of-stake design with a permissionless-top-21 active validator set. Self-delegation requirement is 10,000 HYPE locked for one year. The validator reward rate scales inversely with the square root of total HYPE staked; at approximately 400 million HYPE staked, the implied APR is roughly 2.37%. Validator commissions cannot be raised by more than 1% without a timelock.[25]

HLP — the Hyperliquid protocol-owned liquidity vault Chapter 2 introduced — is structurally separate from the validator stack. HLP earns 3% of the venue's trading fees, with the remaining 97% routing to HYPE buybacks; validators earn issuance and commissions on delegated stake but no direct HLP allocation. The architectural separation is deliberate: HLP is a liquidity vault that depositors fund, not a validator reward stream.[26] Recent institutional validator launches — Hyperliquid Strategies and Unit Labs announced a new validator on 7 May 2026, going live four days later — reflect rising institutional interest in the permissionless set.[27]

The architectural trade-off is the chapter's neutral framing for the Hyperliquid case. The chain's design eliminates the proposer-builder separation surface entirely, which means the validator role is closer to "neutral plumbing" than on Ethereum or Solana — the validator simply runs the consensus, with no discretion over which transactions enter the block or which builders to favour. But the elimination comes at the cost of flexibility. Hyperliquid works extremely well for what it was designed to do: a perpetuals exchange with deep order books and tight spreads. It does not generalise to a smart-contract platform with diverse application demand the way Ethereum or Solana do. Full architectural treatment in Chapter 9.

How this plays out on each chain ​

On Solana, the validator is both the block constructor and the actor with the largest single revenue lever — the client + scheduler choice. The stake-weighted distribution across Agave (32% Jito + 28% JitoBAM + 17% Harmonic + 6% Rakurai = 83% of all Solana stake on Agave-based clients), Frankendancer (12%), and Firedancer (2%) summarises the competitive equilibrium as of March 2026. The moat is the relationship with Jito Labs, Anza, and Jump Crypto whose software determines what the validator's hardware actually does. Alpenglow will rewrite this equilibrium over the next twelve months.

On Hyperliquid, the validator is a member of a permissioned-top-21 set running HyperBFT consensus. The role is closer to "neutral plumbing" than on either of the larger chains, but the trade-off is reduced flexibility: Hyperliquid's validators run an exchange, not a general-purpose programmability platform.

On Ethereum and its L2s, the validator is the proposer but not the block constructor. Approximately 91% of mainnet blocks are constructed by three firms — Titan, BuilderNet, Quasar. The validator's competitive position on L1 is determined by its relay relationships and its choice of client (Lighthouse, Prysm, Teku, Lodestar, Nimbus). On L2s, the sequencer role substitutes for the validator role and is operated by a single firm per chain (Coinbase for Base, Offchain Labs for Arbitrum, the Optimism Foundation's chosen sequencer for OP Mainnet), which Chapter 3 developed.

The Ethereum slashing record over five years — fewer than 500 validators slashed from the Beacon Chain's December 2020 launch through September 2025, against an active validator count over 1.2 million in 2025 — illustrates that operational excellence remains a real but tail-risk dimension of the role. The single largest 2025 cluster was a 39-validator simultaneous slashing on 10 September 2025, traced to SSV Network distributed-validator-technology operator misconfiguration during routine maintenance.[28] Slashing on Ethereum is rare; when it happens, the cause is almost always operator error rather than malicious behaviour. Solana has no stake-slashing equivalent for vote-skipping — penalties are realised as reduced vote credits and reduced inflation-share rewards, with Alpenglow's VAT as the first explicit per-epoch fixed cost.

Who wins, who loses, why ​

Winners. Block-construction firms — Titan with ~51.5% of Ethereum blocks; Jito Labs across the Solana stack; BAM Node operators with the TEE-encrypted layer between BAM-enabled validators and incoming bundles. Validator-client developers whose software captures the right scheduler mode — Jump Crypto with Frankendancer; Anza with Agave's central scheduler; the Harmonic team with the validator-side preferences layer. Institutional validators with scale and infrastructure: Coinbase Cloud at 12.17% of the Ethereum network and zero slashing events since inception; Kiln across 50+ networks with $14 billion in assets under stake. The Hyperliquid permissionless-top-21 set as a stable oligopoly receiving predictable 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 — the Figment migration data shows the gap is real and substantial. Ethereum validators without private-order-flow access through specific builders, because the value of any individual block is increasingly a function of which builder constructs it rather than which validator signs it. And the public-goods narrative of "anyone can run a validator and contribute to the network's neutrality" has been substantially compressed: anyone can run a validator, but earning a competitive return increasingly requires the engineering sophistication, infrastructure relationships, and client knowledge that a marginal operator cannot match.

Is this bad? The clinical answer is that the validator role has bifurcated into two functions that the protocols originally treated as one. The signing function — observing the protocol's rules, signing valid blocks, voting on attestations — is still mostly neutral. The ordering function — deciding which transactions are included, in which order, with which builder's input — has become commercial. The structural argument the chapter has spent five thousand words making is that the bifurcation is genuine and observable in operator-level revenue data: 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. The protocols did not change their formal rules; the operators around them did. The Solana Foundation's June 2024 removal of 32 validators (Chapter 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.

The chapter closes on a quieter observation. Coinbase Cloud's published operating principles include optional OFAC SDN-list filtering as a service to enterprise clients. Roughly 12% of Ethereum's stake is now run by a validator operator that can selectively decline to include sanctioned-address transactions. Whether that is good — for the network's stability, for the operator's regulatory position, for the chain's censorship-resistance properties — depends on which kind of risk the reader weighs more heavily. Chapter 11 returns to that ledger with the full count of who pays for what.[29]

What changes when… ​

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 that opened this chapter — searcher to builder to relay to proposer to staker — collapses to one actor? That is Chapter 7's question.

Footnotes and sources ​

  1. The Merge activated on 15 September 2022 (Ethereum Foundation, The Merge, https://ethereum.org/en/roadmap/merge/). MEV-Boost launched on 7 November 2022 (Flashbots writings; the 90% adoption milestone within nine months is documented across multiple measurement dashboards including mevboost.pics). Accessed 2026-05-14. ↩︎ ↩︎

  2. Coinbase's Q1 2026 validator report, summarised at gncrypto.news, Coinbase Validators 99.98% Uptime, 4.5M ETH Staked, https://www.gncrypto.news/news/coinbase-validators-99-98-uptime-stake-4-5m-eth-q1-2026/. 4.5 million ETH staked = 12.17% of the Ethereum network; 99.98% participation versus 99.77% network average; zero slashing events since inception; self-imposed 30% network-share cap; validators distributed across Germany, Hong Kong, Ireland, Japan, Singapore on AWS and GCP. Accessed 2026-05-14. ↩︎

  3. relayscan.io, MEV-Boost Relay and Builder Statistics (24-hour snapshot ending 14 May 2026), https://www.relayscan.io/. Builder shares: Titan 51.53% (3,410 blocks, 57.46 ETH profit), BuilderNet 24.07% (1,593 blocks, 18.74 ETH), Quasar 15.34% (1,015 blocks), Beaverbuild 1.83%. Top three ≈ 91% of Ethereum mainnet blocks. Relay shares: Ultrasound 35.71%, Titan Relay 26.09%, BloXroute Max-Profit 13.38%, BloXroute Regulated 12.30%, Aestus 7.32%, Flashbots Relay 2.09%. Live data; will drift. Accessed 2026-05-14. ↩︎ ↩︎

  4. Pre-Merge MEV figures from Flashbots Research, Quantifying MEV — MEV-Explore v0, https://writings.flashbots.net/quantifying-mev, and Flashbots Transparency Report — March 2021, https://medium.com/flashbots/flashbots-transparency-report-march-2021-d3930b4b98a9. $314M MEV between January 2020 and early 2021 (~540,000 ETH lower bound); cumulative MEV from December 2019 through the Merge in September 2022 approximately $675M / ~400,000 ETH (Flashbots Collective forum post on pre-Merge data, https://collective.flashbots.net/t/pre-merge-data-for-analysis/1450). Dan Robinson and Georgios Konstantopoulos, Ethereum is a Dark Forest, August 2020 (Medium), is the canonical pre-Flashbots framing of MEV-as-predation. April 2021 84% hashrate adoption of mev-geth is from Flashbots' April 2021 monthly transparency report. Accessed 2026-05-14. ↩︎

  5. OFAC-compliance share figures from CoinDesk's October 2022 coverage of the post-Merge MEV-Boost debate, What's Going On With Ethereum's MEV-Boost?, https://www.coindesk.com/tech/2022/10/05/whats-going-on-with-ethereums-mev-boost, and The Block's 2023 reporting, Ethereum's OFAC-Compliant Blocks Fall to 27%, Marking a Drop in Protocol-Level Censorship, https://www.theblock.co/post/230179/ethereums-ofac-compliant-blocks-fall-to-27-marking-a-drop-in-protocol-level-censorship. The non-censoring relays that took share by 2023 — Ultra Sound Money, Agnostic — are documented in those same sources. Accessed 2026-05-14. ↩︎

  6. Flashbots, Introducing BuilderNet, 18 November 2024, https://buildernet.org/blog/introducing-buildernet; Flashbots, Migrating to BuilderNet, 9 December 2024, https://writings.flashbots.net/migrating-to-buildernet. Founding operators: Flashbots, Beaverbuild, Nethermind. Multi-operator design with each instance in a TEE. Onboarding currently permissioned. Accessed 2026-05-14. ↩︎

  7. Observers, How Two Block Builders Monopolized Ethereum Block Production, 2025, https://www.observers.com/how-two-block-builders-monopolized-ethereum-block-production/. Titan's 17.75% profit margin under exclusive arrangements (e.g., Banana Gun) versus Beaverbuild's pre-BuilderNet ~9%. Kubi Mensah is the publicly named Titan lead; full corporate structure not publicly disclosed. Accessed 2026-05-14. ↩︎

  8. EIP-7732 (Enshrined Proposer-Builder Separation), https://eips.ethereum.org/EIPS/eip-7732; Ethereum Foundation, Checkpoint #9: April 2026, 10 April 2026, https://blog.ethereum.org/2026/04/10/checkpoint-9. Glamsterdam's H1 2026 target has slipped; the EF's own framing as of April 2026 is that "Glamsterdam in Q2 seems unlikely." Accessed 2026-05-14. ↩︎

  9. Syndica, Deep Dive: Solana Onchain Activity (covering March 2026, published 27 April 2026), https://blog.syndica.io/deep-dive-solana-onchain-activity/. Stake shares: Agave Jito 32%, Agave JitoBAM 28%, Agave Harmonic 17%, Agave Rakurai 6%, Frankendancer 12%, Firedancer 2%; 86% of stake on Agave-based clients. Accessed 2026-05-14. ↩︎ ↩︎

  10. The Solana scheduler architecture has moved through two generations of defaults since Anza's original April 2024 post (Introducing the Central Scheduler — An Optional Feature of Agave v1.18, https://www.anza.xyz/blog/introducing-the-central-scheduler-an-optional-feature-of-agave-v1-18). The progression: v1.18 introduced the original central scheduler as opt-in, using a prio-graph dependency model over the top ~256 priority transactions to avoid lock conflicts. v2.0 (mid-2024) made the prio-graph central scheduler the default. v2.2 introduced central-scheduler-greedy as opt-in — a simplified variant that skips the dependency graph in favour of a single-pass selection routine (Helius — Agave v2.1 Update). v2.3 (mid-2025) promoted greedy to default. v3.0 added the TransactionView struct for cheaper parsing. v3.1 fixed banking-worker / Proof-of-History synchronisation bugs that had previously meant banking workers spent ~61% of leader-mode time waiting rather than scheduling; post-3.1 banking workers spend approximately 91% of leader-mode time processing transactions (Helius — Agave v3.1). v3.1 also exposed --enable-scheduler-bindings, an IPC server at <ledger-path>/scheduler_bindings.ipc that lets external schedulers (Rakurai, Frankendancer's pack tile, etc.) plug in without forking the banking stage. The current Agave priority calculation, per the source at core/src/banking_stage/transaction_scheduler/receive_and_buffer.rs, is 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 including signature verification, write-lock acquisition, instruction execution, and loaded-data costs. The +80% fee-collection figure that has circulated in commentary since 2024 was Anza's benchmark of the original prio-graph central scheduler against the thread-local multi-iterator it replaced — not a benchmark of central-scheduler-greedy against its predecessors. Accessed 2026-05-14. ↩︎ ↩︎

  11. Helius Research, Block Assembly Marketplace (BAM), https://www.helius.dev/blog/block-assembly-marketplace-bam. BAM Nodes run inside AMD SEV-SNP TEE enclaves; sequencing is delegated to BAM Nodes while execution remains with the validator. Same source referenced in Chapter 3 for BAM mechanics. Accessed 2026-05-14. ↩︎

  12. BlockEden, Firedancer at 21% Stake on Solana Mainnet — A Technical Deep Dive, https://blockeden.xyz/forum/t/firedancer-at-21-stake-on-solana-mainnet-a-technical-deep-dive-into-the-architecture-that-could-reshape-validator-infrastructure/619. As of 7 October 2025, approximately 20.94% of stake and 207 of 992 validators ran Frankendancer; the March 2026 Syndica figure of 12% reflects subsequent migration to JitoBAM and Harmonic rather than away from the Jump stack entirely. Accessed 2026-05-14. ↩︎

  13. Firedancer Documentation, Configuring, https://docs.firedancer.io/guide/configuring.html. The current docs page describes two pack tile scheduler modes: perf ("fill the block as fast as possible using the highest-paying transactions available… consistently 100% full blocks") and balanced (default, "optimizes for revenue from priority fees… can be poor at capturing MEV if using an external block builder"; "revert to balanced under network congestion"). Accessed 2026-05-14. ↩︎

  14. The revenue scheduler mode was removed in Frankendancer testnet release v0.902.40002 on 21 March 2026 — one of eight bullet points in the release notes, with no accompanying rationale from Jump Crypto. (Firedancer v0.902.40002 release notes; GitHub tag.) The pre-deprecation behaviour is documented in mirrors of the older tile-config docs: revenue "fills blocks extremely lazily, saving most work for the end," producing "high MEV revenue but regularly unfull blocks," and using 10–20 bank tiles versus balanced's narrower fleet (Mintlify mirror of Firedancer tile config). The pre-deprecation Frankendancer-Jito stake-share split between balanced and revenue of approximately 47/47 is from Syndica's March 2026 deep dive (Syndica). Migration paths — BAM and Harmonic — are documented in Helius's BAM writeup and in the Harmonic Scheduling Strategies docs respectively. Accessed 2026-05-14. ↩︎

  15. Rakurai background and funding: PRNewswire, Rakurai Raises $3M Seed Round, https://www.prnewswire.com/news-releases/rakurai-raises-3m-seed-round-to-accelerate-development-of-high-throughput-solana-nodes-302395935.html; Rakurai homepage, https://rakurai.io/. $3M seed led by Anagram Ventures with participation from Slow Ventures, Robot Ventures, Crypto.com, P2P.org, GlobalStake, and Cyber Fund. CEO Ali Rizvi has an Apple background; team built on ASIC and system-on-chip experience. Rakurai is a closed-source fork of Agave. January 2026 stake share approximately 2% (Syndica, Deep Dive: Solana Onchain Activity — January 2026, https://blog.syndica.io/deep-dive-solana-onchain-activity-january-2026/); March 2026 stake share approximately 6% per footnote 7's source. Tip capture +158% at median and +55% at the 95th percentile per the same Syndica deep dive. Accessed 2026-05-14. ↩︎

  16. Figment, Figment Upgrades Solana Infrastructure with Rakurai Client, 10 March 2026, https://www.figment.io/insights/figment-upgrades-solana-infrastructure-with-rakurai-client/; Figment's Q1 2026 Solana Validator Report, https://www.figment.io/insights/figments-q1-2026-solana-validator-report/. Migration date: 2 March 2026. Within two epochs: SRR 6.85% → 7.17% (+32 bps); non-vote transactions per block +49%; compute units per block +48%; revenue per block 2.3× to 0.083 SOL; validator rewards +54%; priority fees +60%; MEV capture approximately 5×. The "no timing games" framing — that Rakurai "do[es] not resort to block timing game manipulation with intentional delays past the target block time of 400ms" — is Figment's direct quote from the migration report. Accessed 2026-05-14. ↩︎

  17. Harmonic Documentation, Scheduling Strategies, https://docs.harmonic.gg/concepts/scheduling-strategies. The three off-the-shelf strategies are: 50ms FBA with Priority Fee Ordering (SFDP-compliant; discrete 50-millisecond batches sequenced by descending priority fees and tips; ~120–130% of median block rewards); FIFO (SFDP-compliant; continuous strict arrival-order sequencing; ~90–100% of median block rewards); MREV (Maximum Revenue Strategy; not SFDP-compliant; proprietary per-transaction selection logic; ~130–150% of median block rewards). Plus a Custom Scheduler option built and operated by the Harmonic team. All strategies operate under three architectural commitments: no sandwiching, no censorship, no malicious MEV. The "MREV is not the network-aligned choice" framing is Harmonic's own. Accessed 2026-05-14. ↩︎

  18. Syndica, Deep Dive: Solana Onchain Activity, March 2026, op. cit. Per-block priority-fee captures versus the network median: Frankendancer Harmonic Performance +101%, Frankendancer Harmonic Balanced +39%, Agave Harmonic +36%. Block-time-adjusted: Agave Harmonic +33%, Frankendancer Harmonic Balanced +32%, Frankendancer Harmonic Performance +28%. Performance-mode blocks measured at ~618ms median versus the network typical of ~400ms. The Syndica labels — "Performance" and "Balanced" — are operator-side telemetry buckets that pre-date the strategy names Harmonic publishes in its current documentation; based on the revenue characteristics, "Performance" corresponds to MREV and "Balanced" corresponds to FBA + Priority Fee. Accessed 2026-05-14. ↩︎

  19. Figment, Migration to Firedancer — Unlocking Next-Generation Solana Validator Performance, https://www.figment.io/insights/figments-migration-to-firedancer-unlocking-next-generation-solana-validator-performance/. Migration at epoch 871 on 30 October 2025. Gross SRR up 18 basis points (peak 28); MEV / Jito tips up 9×; priority fees up 2.5×; non-vote transactions per block up 57%; total CU per block up 20%; revenue per CU doubled from 0.600 to 1.200; median block duration up 18% (355.7ms → 398.4ms); failed transactions per block from 41 to 145. Accessed 2026-05-14. ↩︎

  20. SIMD-0033, Timely Vote Credits, https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0033-timely-vote-credits.md; Anza, Feature Gate Spotlight: Timely Vote Credits, https://www.anza.xyz/blog/feature-gate-spotlight-timely-vote-credits; Anza, Timely Vote Credits documentation, https://docs.anza.xyz/proposals/timely-vote-credits. Approved via governance ending epoch 600 (approximately 9 April 2024); activated on mainnet at epoch 703 in November 2024. Maximum 16 vote credits per vote confirmed within 2 slots; one fewer credit per additional slot of latency; floor of 1 credit at ≥18 slots. The pre-TVC behaviour — validators delaying votes "for many slots to survey forks and wait to make votes that are less likely to be expired without incurring any penalty" — is documented in SIMD-0033 itself, which describes it as "empirically observed, not theoretical." Accessed 2026-05-14. ↩︎

  21. Harkness Institute (TURBIN3), Voting Modifications and Validator Voting Behavior Study v1.0, https://medium.com/@hrknsinst/voting-modifications-and-validator-voting-behavior-study-v-1-0-14098cd01d0c, 2025. The post-TVC vote-latency distribution shift from the 1.1–2.0-slot bucket to the 1.001–1.01-slot bucket occurred within thirty to forty epochs of TVC activation. Among ten identified validators that had been running vote-delay code, abnormal delays decreased by roughly 60–70%, but the modifications were "repurposed, not abandoned." Approximately 500 validators (~14.6% of stake) continue to run customised voting logic. Accessed 2026-05-14. ↩︎

  22. Chorus One, Metrics that Matter, https://chorus.one/articles/metrics-that-matter. Chorus One Solana skip rate 2.03% versus network average 5.19% versus superminority-validator average 5.68%. Accessed 2026-05-14. ↩︎

  23. Chorus One, Timing Games on Solana: Validator Incentives, Network Impacts, and Agave's Hidden Inefficiencies, 13 August 2025, https://chorus.one/reports-research/timing-games-on-solana-validator-incentives-network-impacts-and-agaves-hidden-inefficiencies. The research identifies block-production timing games — artificial delay of Proof-of-History ticking to extend a slot's wall-clock duration beyond the 400-millisecond target — as a separate strategic dimension from vote-attestation timing. Combined timing-games-plus-scheduler-optimisation produced approximately +3.0% in total rewards (about 27 basis points annualised); timing games alone produced approximately +1.19% (about 8 basis points); scheduler optimisation alone produced approximately +1.4% (about 12 basis points). Extended slots reduce effective inflation to approximately 80% of nominal at 500-millisecond slot times. The recommendation — pool or redistribute rewards to neutralise the incentive — has not been adopted. Chorus One and Helius are identified as top latency-optimised validators in the report. Accessed 2026-05-14. ↩︎

  24. SIMD-0326, Alpenglow proposal, https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0326-alpenglow.md; Helius Research, Alpenglow: Solana's Great Consensus Rewrite, https://www.helius.dev/blog/alpenglow; CoinDesk, The Biggest Consensus Overhaul in Solana History Is Officially Live for Testing, 11 May 2026, https://www.coindesk.com/tech/2026/05/11/the-biggest-consensus-overhaul-in-solana-history-is-officially-live-for-testing. Approved 30 August 2025 with 98.27% stake-weighted vote. Replaces TowerBFT + Proof-of-History with Votor (BLS-aggregated off-chain votes) and Rotor (block propagation). Two-path finality: ≥80% round 1 → ~100ms; ≥60% round 2 → ~150ms. Testnet activation 11 May 2026; mainnet expected late Q3 / early Q4 2026. Accessed 2026-05-14. ↩︎

  25. Hyperliquid Documentation, Staking, https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore/staking. Delegated proof-of-stake; active validator set is the top 21 by stake; self-delegation requirement is 10,000 HYPE locked for one year; reward rate inversely proportional to √(total HYPE staked), implying approximately 2.37% APR at ~400M HYPE staked; validator commissions cannot rise more than 1% without timelock. Accessed 2026-05-14. ↩︎

  26. DeFiLlama, Hyperliquid HLP, https://defillama.com/protocol/hyperliquid-hlp. HLP earns 3% of trading fees on the venue; 97% routes to HYPE buybacks; historical return profile approximately 1.75%/month (~20% annualised). Structurally separate from the validator reward stream. Accessed 2026-05-14. ↩︎

  27. PRNewswire, Hyperliquid Strategies and Unit Labs Announce Validator on Hyperliquid, 7 May 2026, https://www.prnewswire.com/news-releases/hyperliquid-strategies-and-unit-labs-announce-validator-on-hyperliquid-302765934.html. Validator launch on 11 May 2026, four days after the announcement. Accessed 2026-05-14. ↩︎

  28. CoinDesk, Ethereum Rare Mass Slashing Event Linked to Operator Issues, 10 September 2025, https://www.coindesk.com/tech/2025/09/10/ethereum-rare-mass-slashing-event-linked-to-operator-issues; SSV Network, Slashing Post-Mortem September 2025, https://ssv.network/blog/slashing-post-mortem-september-2025. 39 validators slashed simultaneously on 10 September 2025, traced to SSV Network distributed-validator-technology operator misconfiguration during routine maintenance. Fewer than 500 validators slashed total from Beacon Chain launch in December 2020 through September 2025, against an active validator count over 1.2 million in 2025. Accessed 2026-05-14. ↩︎

  29. Coinbase Q1 2026 validator report, op. cit. footnote 2. Coinbase Cloud offers optional OFAC SDN-list filtering as a service to enterprise clients. The chapter does not assert that Coinbase's filtering policy affects any specific block; the chapter notes the structural fact and forwards the censorship-resistance-versus-extraction-resistance trade-off to Chapter 11. Accessed 2026-05-14. ↩︎