Two Solana validators can post nearly identical Staking Reward Rates (SRRs) and still be running fundamentally different businesses underneath. The mix of inflation, MEV, and priority fees driving those rewards varies more than the headline number may suggest — as does the durability of those reward sources.
This guide will help you understand how to assess your Solana validator infrastructure partner and illuminate why your choice matters more now than at any point in Solana’s history.
The value of the services and rewards a Solana validator provides
Any Solana validator’s rewards come from three sources:
Inflation rewards
Solana protocol-level issuance. Distributed to validators and delegators for participating in consensus. Inflation rewards are the largest and most predictable source of staking rewards.
- Inflation rewards began at 8%, with a disinflation rate of -15%/p.a. The terminal inflation rate will be 1.5%
- The current inflation rate at epoch 966 is ~3.87%
- The current effective inflation rewards rate is ~5.66%, since only ~68.3% of SOL is staked and rewards are concentrated among stakers
- Inflation rewards are shared with delegators automatically, net of the validator’s on-chain commission rate.
MEV or Maximal Extractable Value
Value captured by the current Solana Leader (i.e. block proposer) through ordering transactions efficiently. On Solana, most institutional validators access this through Jito or Harmonic’s block-auction system. These block-auction mechanisms redistribute MEV payments (tips) from searchers whose job is to find and capture profit opportunities created by the order in which on-chain transactions execute. Validators and delegators earn these MEV “tip” rewards within the next two epochs.
Priority fees
Fees Solana users, programs and dApps attach to their transactions. Priority fees incentivize the current Leader to more quickly include their transactions.
A Solana validator’s job is to stake the chain’s native token, run validator software, participate in block production and capture as much of each type of reward as possible, without compromising the network’s consensus or execution. Two operators running the same Solana validator client software can produce different rewards based on scheduler and networking choices. Two operators running different schedulers on the same client software can produce different rewards. One of the schedulers may build blocks more efficiently to capture MEV, priority fees, or both. Critically, some validator operators choose to boost short-term rewards by extracting value in ways the protocol rules are about to render obsolete.
To understand which validator is doing what, you need to look at three things: the validator client software they run, the block-building strategy or scheduler, and the networking layer they connect through.
Three infrastructure layers, three decisions
A Solana validator is the product of three stacked decisions. Each is a meaningful evaluation point for any business seeking to delegate SOL.
Layer 1: The validator software
Every Solana validator runs a base client, the underlying software that runs the node. The base client participates in consensus, executes transactions, and produces blocks as leader. As part of a base client, a validator operator may choose a scheduler mode — how transactions within blocks are sequentially executed, and in what order.
Today these two pieces are a single, combined software client. Anza Labs (Agave client) is building modular scheduler bindings into Agave that will let validators swap the scheduler independently of the base client; that work is in progress. Until then, when an operator picks “their software,” they’re picking a combined client + scheduler distribution.
The base clients
There are three base clients in production today.
Agave
Anza Labs’ Solana validator client, forked from the original Solana Labs codebase in March 2024. Written in Rust. Battle-tested, widely deployed, and the fallback for almost every validator on the network. If a newer client breaks, operators fall back to Agave for its reliability and quick failover process.
Firedancer
Firedancer is Jump Crypto’s ground-up rewrite of the Solana client in C, sharing no code with Agave. Firedancer 1.0 went live on mainnet in May 2026 at Solana Accelerate in Miami, following roughly 100 days of production use on a small set of validators that began after the December 2025 Breakpoint announcement. Adoption is still limited but expanding with 2.6% of staked SOL. Firedancer exists to address two structural weaknesses of a single-codebase network: resilience and performance. On resilience, an independent C implementation means a bug in Agave can no longer take the entire network offline. On performance, Firedancer’s networking stack and parallelized transaction processing stand out during test runs and indicate Solana’s bottleneck is shifting away from ingress bandwidth.
Frankendancer
A hybrid client that combines Firedancer’s networking and block production with Agave’s consensus. It adds a custom Jito Labs module for MEV execution. It launched on mainnet in September 2024 and now accounts for roughly 11.3% of staked SOL.
The scheduler distributions
On top of the base client, operators select a scheduler mode. The most commonly used scheduler modes are:
Vanilla schedulers
The defaults shipped with Agave. No module for MEV execution or optimization. Agave’s built-in scheduler is called central-scheduler-greedy. 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, this means transactions paying higher priority fees relative to their size win the auction for blockspace. This default behavior is what every standard Agave-based validator does out of the box; specialized forks mentioned below layer additional logic on top, for example, auctioning blockspace to searchers or accepting bundled transaction flows — which is how validators on those clients capture MEV revenue beyond inflation rewards and priority fees.
Jito
The standard MEV stack on Solana and the most widely deployed validator configuration. Jito’s Block Engine runs an off-chain auction where searchers bid via tipped transaction bundles for inclusion in upcoming blocks; bundles execute atomically and tips are distributed on-chain to validators and stakers. On April 29, 2026, Jito shut down its globally hosted Relayer fleet. Validators now connect directly to the Block Engine, removing the front-of-TPU delay the Relayer had imposed on non-bundle transaction flow. Looking forward, Jito’s Block Assembly Marketplace (BAM) replaces the Block Engine with TEE-based BAM Nodes, with around 28% of Solana stake on JitoBAM as of March 2026.
Rakurai
A fork of jito-solana that loads a proprietary scheduler library at runtime. Operators authenticate with Rakurai to download the scheduler binary. If the binary is disabled or unavailable, the validator falls back to standard Jito-Agave behavior. Because the scheduler is closed-source, the assurance model shifts from “verify the code” to “trust the vendor”, a familiar pattern in institutional infrastructure but worth noting for operators relying on fully open-source Solana clients. Rakurai’s public positioning is that its scheduler stays inside the protocol’s 400-millisecond block-time target and does not rely on timing-game manipulation, though as adoption grows, the view on whether the broader behavior profile remains network-aligned is still developing. Figment is actively working with the Solana Foundation and Rakurai to ensure the stack is operated in a way that meets both performance expectations and the foundation’s network-alignment standards.
Frankendancer’s built-in scheduler
Ships with selectable modes: Performance, Balanced, and (historically) Revenue. Performance and Balanced are the currently documented options and target different points on the throughput-vs-priority-fee curve. Revenue mode, which prioritized late-slot transaction reordering to maximize MEV capture at the cost of block fullness and inclusion latency, was removed from the Frankendancer client in a March 2026 release.
Harmonic
An external block-building marketplace that aggregates orderflow from competing sources and lets validators select among multiple scheduling strategies, including custom ones. All Harmonic strategies operate under three architectural commitments: no sandwiching, no censorship, no malicious MEV. The off-the-shelf options are:
- 50ms FBA with Priority Fee Ordering. A frequent-batch-auction design that collects transactions in discrete 50-millisecond windows and sequences them by descending priority fees and tips at window close.
- FIFO (First In First Out). Continuous strict arrival-order sequencing; fees and tips are earned but do not buy ordering priority.
- MREV (Maximum Revenue Strategy) — streaming, proprietary per-transaction selection logic optimized for revenue capture. Harmonic’s own documentation describes this strategy as built “in response to direct customer requests from operators with explicit revenue-maximization preferences” rather than as the network-aligned default.
What delegators should ask
Which client and scheduler does the validator run, and how are rewards generated by the client and scheduler? The answer should reflect a deliberate tradeoff between battle-tested reliability, performance optimization, and operational risk.
Layer 2: The block-building strategy
The same client and scheduler can be configured to produce very different blocks. This is where the integrity question lives — and where most of the durability question lives too.
The Solana protocol targets a 400ms block time. Within that window, a validator selects transactions, orders them, and produces a block. The block-building strategy is the choice of how aggressively to extract value within that window, and whether to extend the window beyond what the protocol intends.
There are currently four block building strategies:
- Vanilla (FIFO or priority-fee ordering) — transactions are included in their natural order, optimized within the 400ms target.
- Streaming scheduling (Frequent Batch Auctions or FBA) — consistent, even packing of transactions throughout the slot. The ordering of the same transactions to maximize value capture, without delaying transaction inclusion or extending overall block time.
- Extractive scheduler modes. These intentionally hold blocks open longer to land more transactions per block. The validator earns more; users get slower confirmation times and degraded application performance. Empirically, validators running these modes have produced median block times of 470–570ms during peak observed periods, well above the network’s 400ms target.
- Slot lagging / timing games. It’s a practice that produces the same effect by simply running blocks beyond the 400ms low without invoking a specific extractive mode.
The latter two strategies generate some degree of scrutiny. The Solana Foundation Delegation Program prohibits intentional TPU delays beyond 50ms and requires fair transaction handling. Jito’s JIP-23 created stake-pool penalties for validators who consistently delay blocks. And the Alpenglow consensus upgrade, scheduled for late 2026, structurally eliminates the reward edge from timing-based extraction.
What delegators should ask
What’s the validator’s median block time, and are they running any extractive scheduler modes? Median block time is the simplest single signal.
Layer 3: Networking and data latency
Blockchains and validators operate on the public internet. Validators communicate constantly across the network. They propagate new blocks, broadcast votes, share transaction data and share the state of the network. The networking layer determines how fast, how reliably and how predictably that happens, measured in latency. This produces a marginal but durable rewards uplift that’s independent of the software stack. The public internet is the default networking stack. It works, but it wasn’t purpose-built for the latency-sensitive task blockchains handle.
DoubleZero
DoubleZero is a private, fiber-optic cable networking solution. It is purpose-built for high throughput, globally-distributed networks including but not limited to blockchains. (See our article: DoubleZero is Chain-Agnostic by Design for more detailed information).
It is an ideal networking stack for Solana validators due to lower latency, and low jitter (latency variance). On Solana, ~53.15% of validators are connected to DoubleZero. Including Figment, DoubleZero accounts for staked SOL across 448 validators as of early 2026. Connected validators see better block propagation, fewer missed votes, and a measurable uplift in vote credits.See the following DoubleZero metrics dashboards for more information:
- DoubleZero performance map
- DoubleZero telemetry metrics
- DoubleZero validator metrics
- DoubleZero validator vote metrics
bloXroute
bloXroute operates their own, globally distributed Blockchain Distribution Network (BDN). It speeds up shred propagation between validators (improving consensus participation) and also delivers shred data to traders for low-latency consumption by colocating with validators. These two use cases run on BDN.
What delegators should ask
Is the validator on optimized, purpose-built networks for blockchains like DoubleZero and bloXroute, or just the public internet? These infrastructure stack decisions contribute to performance differences that get attributed to software, but are due to the underlying networking layer, one layer below.
How to evaluate a validator
The questions worth asking are, in order:
- What client and scheduler does the validator run, and is the scheduler open-source?
- What’s their block-building strategy? Specifically, are they running any extractive modes, and what’s their median block time? Are they stretching their leader slots past 400ms?
- What networking layer are they on?
- If Alpenglow shipped tomorrow, which of their reward sources would still be there next quarter?
That last question is the one most institutional buyers haven’t asked yet. It’s also the one with the clearest answer. Layer 1 and Layer 3 choices are durable through Alpenglow. Layer 2 is where the borrowed basis points live. A validator whose top-of-leaderboard ranking comes from extractive Layer 2 strategies is borrowing basis points against a near-term deadline. A validator whose ranking comes from Layer 1 and Layer 3 choices keeps theirs.
Why this matters now
Solana is in the middle of its largest infrastructure transition since launch — with the Alpenglow consensus rework. Blocks go from 12-second finalization to 150ms finalization. New base clients, new schedulers, new networking layers, and new consensus protocols are in-progress. Validator performance and rewards are not a steady-state product right now. The basis points putting a validator at the top of the leaderboard today may come from very different sources — some durable, some not.
Alpenglow, expected to activate on mainnet in late 2026, following Agave 4.1 in Q3 and audits through Q4, eliminates the reward edge from timing-based extraction. Slot lagging and intentional block delays will stop generating additional rewards once it lands as blocks produced past 150ms will simply be skipped, losing any associated MEV and priority fee rewards for that leader. If you are a SOL delegator to these types of validators, your rewards aren’t long-lived.
As of May 14, 2026, Figment’s primary validator runs Agave with the Rakurai scheduler, alongside Jito for MEV, DoubleZero for networking, and bloXroute as our current shred-forwarding partner. We are constantly optimizing our current validator tech stack, while evaluating new clients and schedulers that deliver the best performance without excessive extractive methods.
