MEV: How do Validators and RPCs Earn From It? (Part 3)
"MEV, that ability for people to reorder transactions to extract value, something that happens on top of Ethereum and Solana, that's just not suitable for financial markets."
-Don Wilson, founder of DRW Trading, via @blockworksDAS
https://x.com/blockworksDAS/status/2037173314322309358?s=20
He's not wrong about the problem. But MEV didn't start with crypto, traditional finance has been running the same extraction for decades, just under a different name: payment for order flow.
MEV is a deeply misunderstood term. Not all MEV is bad, arbitrage that aligns prices across venues and liquidations that keep lending protocols solvent are MEV too.
The more honest question isn't whether MEV exists. It's who controls it, and at whose expense. The problem is the extractive kind: sandwiches, front-running, censorship, where one party profits by making another party's trade worse.
This piece goes to the top of the MEV supply chain: validators and RPC providers. Validators control what goes into every block. RPC nodes are the first entity to see every user transaction.
In Part 1 of this series, we covered the fundamentals: what MEV is, why it exists, and the actors in the supply chain.
In Part 2, we went deep into searchers: how they find opportunities and why speed is the baseline for competing on Solana.
This article is structured in four sections:
How validators extract value
What the live data shows
How RPC nodes enable MEV
The infrastructure arms race. The full stack that determines who wins.
Thanks to @Circular_fi for their real-time validator data and
for their MEV research.
The Leader's Monopoly
On Solana, the validator assigned to a slot has complete control over the block it produces. It decides which transactions get in, what order they execute in, and whether to insert its own trades. During their leader slots, a validator can:
Include or exclude any transaction. The leader picks which transactions make it into the block and can silently drop anything. There is no onchain proof of intentional exclusion. The dropped transaction expires after about 150 blocks and the user retries, never knowing it was censored.
Control exact ordering. The leader sets the sequence of every transaction down to individual instructions. This is what makes sandwich attacks possible. When you control ordering, placing your buy before the victim and your sell after is trivial.
Insert their own transactions. The leader can inject arbitrage trades, sandwich legs, or liquidation calls anywhere in the block.
See transaction contents before finalization.Through QUIC (a transport protocol that Solana uses to send transactions directly to the current block leader) and the TPU (Transaction Processing Unit - receives, validates, and schedules incoming transactions before they are written to the block), the leader reads swap parameters, slippage tolerances, token amounts, and destination pools before anything is confirmed.
This monopoly rotates every 4 slots (roughly 1.6 seconds). The schedule is public, computed per epoch (about 2 days), with slots assigned proportional to stake weight. 3 properties make this especially exploitable:
Predictable schedule. Searchers know exactly which validator produces the next block and pre-position accordingly.
Four consecutive slots per leader. Long enough for cross-slot attacks where the front-run and back-run land in different slots, evading single-slot detectors.
More stake means more slots. MEV profits reinvested into stake generate more leader slots, creating a compounding flywheel.
2. How validators see transactions early
On Solana, validators get this visibility through 3 channels.
1. Direct QUIC Visibility:
Transactions flow through Gulf Stream (Solana's mempool-less transaction forwarding protocol that routes transactions directly to the anticipated next leader) directly to the upcoming leader via QUIC. The leader reads everything: token, token amount being swapped, slippage tolerance, destination pool, maximum acceptable price. A malicious leader calculates the optimal sandwich, constructs both legs, and inserts them into the block with guaranteed positioning.
2. The Jito Relayer's 200ms Window (Historical)
When Jito's infrastructure was first deployed, its relayer created an asymmetric information advantage:
User transaction arrives at the relayer
Relayer immediately forwards it to the Jito Block Engine (zero delay)
Relayer delays 200ms before forwarding to the actual validator
That 200ms gap was the extraction window. Searchers connected to the Block Engine could see pending transactions, construct sandwich bundles, bid through the auction, and get them included before the original transaction even reached the validator through the standard path.
The public mempool was shut down in March 2024. But the jito-relayer codebase still contains the forwarding switch and the 200ms delay setting. Whether individual validators keep it enabled is unknown because the Block Engine remains closed-source.
3. Private Mempools
After the public mempool shutdown, sandwich operations moved to private, invitation-only systems. Validators share their incoming transaction stream with select searchers or their own bots through off-chain arrangements that are invisible to the public and accountable to no one.
3. Extraction Techniques
1. Direct Sandwich by the Leader
The most common technique. The leader sees a user's swap arriving through QUIC, reads its parameters, and inserts two transactions around it:
[Leader's buy] → [Victim's swap] → [Leader's sell]
The leader's buy pushes the price up. The victim executes at this inflated price. The leader's sell captures the difference. Zero execution risk because the leader controls ordering.
's analysis of 8.5 billion trades (January 2024 to April 2025) found sandwich bots extracted between $370M and $500M from users, paying only 15 to 20% of profits as tips.
2. Cross-Slot Sandwich Attacks
When a validator holds consecutive leader slots (which happens every time since each leader gets 4 in a row), the attack spreads across slot boundaries:
Slot 1: Front-run buy inserted
Slot 2: Victim's transaction executes at the moved price
Slot 3: Back-run sell inserted
Traditional sandwich detectors look for all 3 legs within the same slot. When the legs are in different slots, they look like unrelated transactions.
3. Evasive Sandwich Attacks
documented how validators adapted their strategies specifically to dodge detection algorithms.
Instead of the clean pattern of one front-run, one victim, one back-run, evasive attackers useconfusion:
Split the front-run into multiple smaller buys from different wallets
Transfer tokens to a separate address between the front-run and victim's trade
Execute the back-run sell from this second address
Some split the back-run into multiple sells as well
The goal is to break the pattern that detection algorithms look for. When the buying wallet and selling wallet are different, and buys are fragmented across multiple transactions, simple pattern matching fails.
4. Validator-Run Arbitrage Bots
Some validators skip external searchers and run their own MEV bots directly on the node.
Paladin is the most developed example. It integrates with the Jito client and activates only during the validator's leader slots. Three components:
Atomic Arb Bot: Finds and executes arbitrage across Solana DEXes, targeting price discrepancies between pools rather than individual user trades
CeFi/DeFi Arb: Captures spreads between centralized exchanges and onchain DEXes through a permissionless bulletin board
PALAggregator: Provides optimal trade routing during the leader slot, shares surplus value with transaction originators
This is considered benign MEV. It does not reorder or front-run user transactions. It inserts the validator's own trades between existing ones to capture price inefficiencies. Using Paladin increases validator income by roughly 12.5%.
Chorus One pioneered a similar approach with their open-source Solana-MEV client. Their modified validator scans every batch of transactions for arbitrage opportunities and appends its own trades without reordering anything.
What the Live Validator Data Shows
The Circular validator leaderboard provides a real-time view of how different validators handle MEV revenue.
The 7-day window from March 2026 covers 766 active validators, $3.77M in total revenue, and $38.2B in total stake. Five distinct archetypes are visible.
Infrastructure Leaders (Figment, Helius, Jupiter)
Earn through throughput, not extraction. Helius and Jupiter run 0% commission on everything, passing all revenue to stakers. MEV Rev ratios are moderate at 17 to 22%. Their business model is attracting stake through infrastructure quality.
Split-Commission Capturers (Kiln, Everstake, Galaxy)
Kiln charges 5% regular commission but 100% MEV commission. Stakers see "5%" and think it is competitive. Kiln kept $41.4K in Jito tips over 7 days. Everstake runs 7% regular, 100% MEV. Galaxy takes 25% of MEV. Publicly posted, but most retail stakers do not understand the distinction.
Anonymous 100% Operators
The most concerning cluster. 6 anonymous validators in the top25 run 100% commission on both regular and MEV revenue. No public identity, website or DoubleZero.
Combined stake: roughly $2.18 billion
Combined weekly revenue: approximately $236K (annualizes to $12.3M)
All kept by the operators. Zero shared to stakers.
Cross-referencing with
data, several of these validators appear in the evasive sandwich tables. Btsmi...1DAaH (#16 by revenue) showed a sandwich rate of 0.89% under v1 detection. Under v2, its actual rate was 64.4%. FBKFW...UjeNi (#18) and 5Zqve...Sq9qk (#19) were also flagged.
Exchange Validators (Binance, Kraken, Coinbase, Upbit)
Control orderflow both onchain and offchain. Binance runs 0% commission, likely subsidizing for CEX-DEX arb access. Upbit is the outlier: $429M stake, 100% commission, only $166 in Jito tips over 7 days, yet $149M volume and $8.2K MEV Rev. An entirely proprietary setup outside Jito.
Ecosystem Validators (Forward Industries, Bitwise, Staking Facilities)
These run 0% commission and compete purely on delegation growth. Staking Facilities brands itself "MEV" with a fire emoji and passes all MEV benefits directly to stakers through BlazeStake integration.
How RPC Nodes Enable and Extract MEV
Before a transaction reaches the validator, it passes through another layer: the RPC node. They are the gateway between users and the blockchain. Every wallet, dApp, and bot submits transactions through an RPC endpoint.
How RPC Nodes See Chain State First
The speed at which a bot learns about onchain state changes determines whether it captures an opportunity or misses it. 3 tiers of data ingestion exist, and the gap between them is where MEV lives.
Standard RPC / WebSocket:
This is what most users and basic dApps rely on. The bot polls the RPC node: "what is the current state?" The node responds. The bot polls again. Every cycle adds latency. Even with WebSocket subscriptions (which push updates instead of requiring polls), the data still goes through the full RPC serialization pipeline before reaching the bot. By the time you learn a pool's price moved, someone with faster data has already submitted their arbitrage. For normal applications this is fine. For MEV it is not.
Geyser / gRPC, also known as Yellowstone:
Geyser is a plugin built directly into the Solana validator software. It does not wait for data to go through the RPC layer. Instead, it hooks into the validator's internal memory and fires events the instant an account changes or a transaction confirms. Every time a pool's reserves shift, an oracle pushes a new price, or a collateral ratio drops below liquidation threshold, Geyser emits that event before the data is even available through normal RPC.
But Geyser runs inside the validator, so you need a way to receive those events on your own server. That is what Yellowstone does. Built by Triton One and now open source, Yellowstone takes Geyser's internal events and streams them over gRPC using Protocol Buffers and HTTP/2, both significantly more efficient than JSON over HTTP/1.1 that standard RPC uses.
The practical result: a Geyser-connected bot knows about a state change 50 to 200ms before a bot polling standard RPC. When a large swap hits a Raydium pool and moves the price, the Geyser bot is already computing whether there is a profitable backrun while the WebSocket bot has not even received the update yet.
ShredStream:
ShredStream goes even earlier than Geyser. Solana does not build a complete block and then broadcast it. The leader continuously streams out block data in real-time fragments called shreds as it constructs the block. These shreds propagate through Turbine, Solana's data distribution layer, which uses a stake-weighted tree. Validators with more stake sit higher in the tree and receive shreds first. Everyone else waits downstream.
ShredStream bypasses that tree entirely. Instead of waiting for shreds to trickle down through Turbine based on stake position, it delivers them directly to your server via gRPC regardless of your stake weight. The result is that bots can observe transactions arriving in the current block before the block is fully assembled, before most of the network has even seen the data.
This matters most in tight races. If two searchers spot the same arbitrage, the one who sees the relevant transaction land in the current block first can compute and submit before the other has even received the signal. At 50ms auction ticks, a 20 to 40ms shred delivery advantage is often the entire margin between winning and losing.
The most competitive setups combine all three fast sources, Geyser plus ShredStream plus bloXroute BDN (a global relay mesh offering 30 to 50ms acceleration), and auto-select whichever delivers the fastest data per slot.
2. The SWQoS Two-Tier System
Solana's Stake-Weighted Quality of Service (SWQoS) creates a hierarchy. The leader prioritizes incoming traffic based on the forwarding node's stake weight. During congestion, unstaked traffic gets dropped. Staked traffic flows through. This produces two tiers: transactions through staked RPC nodes get high inclusion probability, transactions through public endpoints become second-class.
RPC providers sell SWQoS as a premium feature. Helius routes through its own validators. Triton One runs a marketplace where validators sell bandwidth. Solana's own documentation makes it explicit: validators can sell capacity to RPC nodes, and an operator running both has end-to-end control over the pipeline.
Infrastructure Race
Everything described above, validators extracting through block control, RPC nodes extracting through gateway position, searchers competing for opportunities, all of it converges on one reality: MEV on Solana is an infrastructure competition. The best strategy is worthless if your setup is 100ms slower than a competitor's.
Here is the full stack that determines who wins.
Layer 1: Hardware
Cloud VMs are not an option. Shared tenants on cloud instances mean your process competes with other customers for CPU cycles, memory bandwidth, and network I/O. That introduces unpredictable latency spikes at exactly the moments when the network is busiest and MEV opportunities are richest.
Bare-metal servers with EPYC processors. Shared tenants introduce unpredictable latency spikes.
512GB+ RAM to keep hot account state in memory
NVMe SSDs for fast state replay
CPU pinning to eliminate context-switching overhead
Custom kernel tuning with disabled hyperthreading and NUMA-aware memory allocation
Layer 2: Geographic Positioning
Solana's leader rotates every 1.6 seconds across globally distributed validators. Your optimal geographic position shifts with every rotation. A 150ms round-trip delay to the current leader means your transaction misses the slot entirely.
Same data center as the validator. Bot, RPC, and validator on the same LAN. Sub-1ms latency between components. Eliminates internet routing entirely.
Dynamic region switching. Nodes across multiple data centers that switch to whichever is closest to the current leader. The leader rotates every 1.6 seconds, so the optimal position shifts constantly.
CEX proximity. Servers near centralized exchange infrastructure to detect off-chain price moves before they hit onchain DEXes.
Multi-region redundancy. Backup nodes across US East, Europe, and Asia for continuous coverage.
Layer 3: Data Ingestion
How fast your bot sees onchain state changes determines everything. The gap between the fastest and slowest data source is 200 to 500ms, an eternity in a system where auctions tick every 50ms.
Jito ShredStream: 200 to 500ms ahead of standard Turbine
Yellowstone gRPC (Geyser): Sub-50ms from validator memory
bloXroute BDN: 30 to 50ms gains through global relay mesh
Standard WebSocket: 100 to 300ms. Not competitive.
Top setups combine all three fast sources and auto-select the fastest per slot.
Layer 4: Transaction Submission
Seeing the opportunity first is only half the problem. Getting your transaction to the leader before anyone else is the other half.
Jito Block Engine: Bundle auction with atomic execution.
bloXroute Trader API: Multi-path submission through Jito + Paladin + bloXroute simultaneously. Leader-aware routing avoids malicious validators.
Direct TPU: Straight to the leader's QUIC port. Requires SWQoS-enabled staked identity.
Paladin P3: VIP FIFO channel with sandwich protection.
Lite-RPC: Lightweight proxy routing directly to the upcoming leader's TPU.
Conclusion
Solana's MEV landscape is not about one actor or one technique. It is a layered system where power concentrates at every point in the transaction pipeline.
Validators have unchecked authority during their leader slots to reorder, insert, censor, and sandwich transactions. Theonchain data confirms this is not theoretical.
Anza released the official Constellation protocol design, the first fully specified implementation roadmap for Multiple Concurrent Proposers (MCP) on Solana.
The long-term solution the ecosystem is building toward is Multiple Concurrent Proposers (MCP), which removes the leader's monopoly power entirely by replacing a single block proposer with multiple simultaneous proposers whose batches are deterministically merged. Under MCP, no single party can reorder, censor, or front-run because ordering becomes a protocol rule, not a leader's decision. Combined with transaction encryption, MCP closes both the structural and informational channels through which MEV flows.
