Solana: Built on Innovation, Slowed by Incentives

Key Takeaways

• Solana is not simply trying to build a faster blockchain, but to become on-chain infrastructure capable of replacing real-world capital markets. In doing so, it places relatively higher priority on execution speed, latency, and reliability over ideological goals like decentralization. Infrastructure upgrades such as Firedancer, Alpenglow, and DoubleZero are all designed around this direction.

• While Solana has already achieved high throughput and low latency, the primary bottleneck is no longer performance. Instead, it lies in the MEV-driven structure that determines transaction ordering and inclusion. In particular, the Jito-centric block production model optimizes MEV extraction while introducing latency, execution uncertainty, and infrastructure dependency. This is not merely a performance issue, but a problem of market microstructure.

• Solana’s long-term roadmap goes beyond performance improvements and focuses on redefining transaction ordering and execution itself. Architectures such as BAM, ACE, MCL, and APE aim to redesign how transactions are ordered and executed across different layers. Rather than eliminating MEV, these approaches seek to distribute its influence and make the market structure more fair and predictable. Ultimately, the key challenge for Solana is aligning infrastructure direction with economic incentives.

Introduction

To begin, it is important to recognize that Ethereum and Solana, two leading smart contract platforms, are no longer pursuing the same direction.

Ethereum is built around ideological principles such as trustlessness, censorship resistance, and the cypherpunk ethos. It aims to provide a neutral infrastructure that anyone can access without interference from states or corporations. In this framework, such principles are often prioritized over performance or usability.

Solana, however, has explicitly chosen a different path. Last year, Anza, one of Solana’s core development teams, published a vision statement titled “The Internet Capital Markets Roadmap,” co-authored by Anatoly Yakovenko, Lucas Bruder of Jito Labs, and Kyle Samani of Multicoin Capital. The following lines clearly illustrate Solana’s direction:

"The original mission of Solana was to build the decentralized backbone for Internet Capital Markets (ICM).”

"There are no zealots in Solana, only pragmatic engineers who want to build a platform that can support the world's most liquid financial markets.”

Solana is not a network optimized solely for decentralization, but rather a market infrastructure. Its goal is to become the backbone of an on-chain capital market that users around the world can actually use. Compared to values such as censorship resistance or decentralization, Solana places greater emphasis on faster transactions, lower latency, and more reliable execution. Every infrastructure innovation discussed in this article, including Firedancer, Alpenglow, DoubleZero, and BAM, serves this direction.

However, there is a major bottleneck that stands in the way, Solana’s MEV structure.

Solana’s average slot time is 400 milliseconds. Yet most transactions pass through Jito’s relayer, which introduces a short holding period to create an auction window for MEV bundles. Historically, this delay reached up to approximately 200 milliseconds, which is half of the slot time. In other words, transactions in this so-called on-chain Nasdaq were effectively waiting for MEV auctions to complete before execution. This is not widely recognized.

The issue goes beyond transaction speed. Solana’s high-performance validator client, Firedancer, initially saw limited adoption because it was less efficient at capturing MEV. Adoption only increased after official integration support from Jito was introduced. As of March 2026, Firedancer still accounts for roughly 12~13 percent of staked validators, while the majority of stake remains on Jito-enabled Agave clients.

MEV itself is not inherently negative. It contributes to the economic sustainability of the protocol. The problem is that the structure it creates has begun to hinder infrastructure development, impose hidden costs on users, and distort incentives across the ecosystem. In 2025 alone, MEV extracted on Solana reached approximately 720 million dollars, with MEV tips accounting for a significant portion of network revenue and consistently exceeding priority fees. Ultimately, MEV is paid by users, the ones clicking the swap button.

This article explores Solana’s infrastructure innovations in the context of its ambition to become the backbone of internet capital markets. It examines how the current MEV structure has constrained that vision, and how the ecosystem is attempting to resolve this tension.

1. Solana Architecture Fundamentals

Solana's performance emerges from a combination of several technical design choices. Understanding these concepts is a prerequisite for grasping the significance of the infrastructure innovations discussed later.

1.1 Gulf Stream and SWQoS: Transaction Delivery Without a Mempool

Most blockchains require transactions to wait in a public mempool before being included in a block. Solana has no public mempool. Gulf Stream forwards transactions directly to the next scheduled leader validator via the QUIC protocol, without any public queue. Because Solana can predict the leader schedule for the next several hundred slots at each slot (400ms), clients can proactively deliver transactions to future leaders.

This eliminates mempool congestion, lets leaders build blocks immediately, and reduces memory overhead. The tradeoff is that without a public mempool, MEV is theoretically impossible through conventional means, yet in practice, MEV on Solana is highly active.

SWQoS (Stake-Weighted Quality of Service) adds another layer. Since transactions are delivered directly to the leader without a mempool, being connected to the leader via QUIC is critical. But there is a physical limit to how many simultaneous QUIC connections a leader can handle. During network congestion, when many nodes attempt connections simultaneously, those slots become scarce. SWQoS prioritizes these limited slots based on stake weight: transactions forwarded from validators with more stake receive priority, while those from low-stake general RPC nodes may be deprioritized during congestion.

This mechanism is designed to suppress spam and rationally allocate network resources. However, as of March 2026, 33% of all Solana staking is concentrated in just 18 validators. Since SWQoS priority directly reflects this stake concentration, users and MEV searchers structurally benefit from routing transactions through high-stake large validators.

Source: solanabeach

1.2 Sealevel: Parallel Transaction Execution

Ethereum executes transactions sequentially. Solana's Sealevel executes transactions affecting different account states in parallel. Because transactions explicitly declare which accounts they read and write at submission time, the runtime can process non-overlapping transactions simultaneously. Sealevel's parallel execution is the core mechanism enabling Solana's high TPS.

1.3 Turbine: Shred-Based Block Propagation

Broadcasting an entire completed block creates bandwidth problems. Turbine splits blocks into ~1,200-byte units called shreds and propagates them in a tree structure. Because the leader generates and propagates shreds simultaneously, other validators begin receiving and reassembling pieces before the block is even complete. This enables Solana's streaming block production. Reed-Solomon error coding allows block recovery even if some shreds are lost. Alpenglow's Rotor, discussed later, is a new broadcast layer designed to replace Turbine.

1.4 Proof-of-History + Tower BFT: The Current Consensus Structure

Solana's current consensus operates on two layers.

Proof-of-History (PoH), commonly misidentified as Solana's consensus algorithm, is actually a cryptographic clock. It proves the passage of time by computing SHA-256 hashes sequentially. This allows validators to verify transaction ordering without agreeing on a global clock, and is the foundational design enabling Solana's fast block times.

Tower BFT is a BFT (Byzantine Fault Tolerance) consensus mechanism that leverages PoH. Validators must submit on-chain vote transactions each slot, and these accumulate to determine block finality. The problem is that these validator votes account for approximately 75% of all Solana transactions under normal conditions. A significant portion of blockspace that could hold user transactions is consumed by internal consensus traffic. Current finality time is approximately 12.8 seconds.

2. Solana's Infrastructure Innovations

2.1 Firedancer

Firedancer is Solana's second fully independent validator client, developed by Jump Crypto over three years starting in 2022. Unlike the existing Agave client written in Rust, Firedancer is written entirely in C/C++ from scratch.

The core architecture is a tile-based modular pipeline. Functions such as networking, signature verification (sig verify), block production (pack), and execution are separated into independent tiles, each pinned to a dedicated CPU core and communicating via shared-memory queues. No system calls are required for inter-tile data transfer, virtually eliminating context-switching overhead. Each tile is also sandboxed, so a crash in one does not bring down the entire process.

The performance gains are substantial. Firedancer achieved 1.4 million TPS in single-core fd_quic benchmarks and over 1 million TPS in controlled cluster environments, numbers that dwarf current Solana mainnet throughput by orders of magnitude.

The significance of Firedancer goes beyond performance: client diversity. Solana experienced 7 network outages in 5 years, 5 of which originated from validator client bugs. In June 2022, a single durable-nonce transaction bug caused a 4.5-hour network halt. With Jito-Agave dominating most stake, a single Agave bug could halt the entire network. Firedancer's independent C/C++ codebase forms a completely separate fault domain. Bugs in Agave do not propagate to Firedancer.

Status: Frankendancer (Firedancer networking + Agave consensus hybrid) launched on mainnet in September 2024; Full Firedancer (with Agave dependency fully removed) began mainnet deployment in December 2025. As of March 2026, Firedancer validators hold approximately 12.7% of stake, and all of them run Jito alongside Firedancer. Still, 83.8% of Solana stake remains on Agave.

Source: reports.firedancer.io

2.2 Alpenglow

Alpenglow (SIMD-0326) is the largest protocol upgrade in Solana's history. It passed community governance in September 2025 with 98.27% approval (52% stake participation). Anza lead economist Max Resnick called it "the most important protocol rewrite in Solana's history."

2.2.1 Votor

otor is Solana's new block finality engine. Under Tower BFT, validators publish on-chain vote transactions every slot, approximately 75% of all Solana transactions under normal conditions. Votor moves this voting off-chain.

Validators exchange votes directly using BLS12-381 signatures off-chain. Once the leader has collected sufficient votes, it aggregates hundreds or thousands of signatures into a single compressed aggregate signature, creates a "finality certificate," and posts only that on-chain. Hundreds of individual vote transactions are compressed into a single certificate.

There are two finality paths. If ≥80% of stake participates, the block is finalized in a single round (fast-finalization); if ≥60% participates, two rounds suffice (slow-finalization). The target finality time is 100–150ms, roughly 100x faster than the current ~12.8 seconds. Security is achieved by combining SHA256 hashing with BLS12-381 signature aggregation for 128-bit security.

Fault tolerance is also strengthened. Votor adopts a "20+20" model: the network continues operating even if 20% of nodes are malicious and another 20% are unresponsive simultaneously, a significantly stronger guarantee than Tower BFT.

The economic model changes too. Off-chain voting eliminates existing vote transaction fees. To replace them, the VAT (Validator Admission Ticket) is introduced: validators prepay 1.6 SOL per epoch, which is fully burned. This is approximately 80% of current voting costs (up to 1.1 SOL/day per Solana's official documentation).

2.2.2 Rotor

Rotor redesigns Solana's block propagation layer to replace Turbine. The core design insight is that "the bottleneck in block propagation is network latency, not bandwidth." Based on this, Turbine's multi-layer tree structure is replaced with a single-hop relay model.

Turbine propagates shreds through a multi-layer tree with a fanout of 200, passing data from the leader → first-tier nodes → second-tier nodes across multiple hops. Rotor simplifies this. The leader splits the block into erasure-coded shreds and sends each shred directly to stake-weighted relay nodes. Relay nodes then broadcast their shreds to the entire network. Most validators receive all necessary block data in a single network hop from a relay.

Another difference from Turbine: Turbine sends data shreds and recovery shreds separately; Rotor sends only a single erasure-coded version, reducing data duplication while maintaining the same recoverability. Shred integrity is guaranteed by the leader creating a Merkle tree of shred hashes and signing the root, and each shred includes its Merkle path for immediate authenticity verification by receivers.

Performance simulations are impressive: at 1Gb/s bandwidth, transmitting 1,500 shreds takes ~18ms; reaching 80% of total stake takes ~2ms. At this level, the bottleneck is not protocol overhead but the speed of light itself: physical network latency from geographic distance. Rotor is also natively compatible with DoubleZero's multicast system.

Concerns exist, however. Deterministically selecting relay nodes by stake weight could entrench large validators in bandwidth-efficient roles, reinforcing long-term economic advantages. MIT Professor Muriel Médard noted that the Reed-Solomon codes used by Rotor were "designed in the 1950s–60s for a different purpose" and may be vulnerable to the non-deterministic latency of Web2 networks.

Rotor is not included in SIMD-0326. The official document states: "Initially we stay with Turbine as the data dissemination protocol. Rotor will be introduced later and will get its own SIMD." Alpenglow v1 introduces only Votor; data propagation remains on Turbine for now. Rotor will be proposed separately via a future SIMD.

2.3 DoubleZero

Solana validators communicate over the public internet, which is designed for general-purpose use and subject to packet loss, jitter, and unpredictable delays, fundamentally mismatched with workloads like blockchain consensus that require thousands of nodes to synchronize within hundreds of milliseconds.

DoubleZero is the solution. Co-founded by Austin Federa, former Head of Strategy at the Solana Foundation, the project aggregates underutilized dedicated fiber bandwidth from institutions like Jump Crypto, Galaxy, and RockawayX to build a blockchain-dedicated private network. Validators exchange shreds and consensus messages through DoubleZero's direct connections instead of the public internet.

The ICM roadmap explicitly includes DoubleZero as a medium-term priority, targeting "up to 100ms reduction in routing latency and 10x bandwidth expansion."

Status: DoubleZero launched its mainnet beta on October 2, 2025. Per CoinDesk reporting, at launch approximately 22% of Solana stake and over 300 validators were connected, linked via 70+ high-performance fiber links across 25 global locations. The company raised $28M at a $400M valuation.

Notably, DoubleZero has explicitly committed to geographic decentralization. Given that Solana's goal is enabling internet capital markets accessible anywhere in the world without delay, geographic decentralization matters for Solana too. Starting March 9, 2026, its "Phase II Delegation Program" redirects 2.4 million SOL to validators in underrepresented regions including São Paulo, Singapore, Hong Kong, and Tokyo.

2.4 BAM

BAM (Block Assembly Marketplace) was announced in July 2025 and began its early mainnet in September 2025. It is Jito's next-generation block assembly system, described by the ICM roadmap as a "near-term solution."

BAM is an attempt to structurally address sandwich attacks in Solana MEV. The existing Jito Block Engine was a centralized off-chain auction system operated by Jito Labs, with transaction contents potentially exposed externally. BAM replaces it with a distributed node network running TEE (Trusted Execution Environment) hardware. Each BAM node sequences transactions in an encrypted state inside a TEE, so even the leader validator cannot see transaction contents before execution. BAM nodes generate cryptographic attestations for all sequencing decisions. If a validator arbitrarily changes the order, the entire network immediately detects it. This makes harmful MEV like sandwich attacks significantly more difficult.

BAM's second innovation is the ACE (Application-Controlled Execution) plugin. App developers can define transaction ordering rules directly for their own protocol: ensuring oracle updates execute before trades, liquidations take priority over market orders, or LPs receive preferential access within a batch. Drift, Pyth, and Dflow are already building plugins. ACE lays the groundwork for on-chain CLOBs to compete with centralized exchanges. This is the precursor implementation of protocol-level ACE (covered in Section 4.1), realized first in BAM's off-chain environment.

As of March 2026, approximately 28.7% of stake runs JitoBAM. However, BAM remains a centralized system with Jito operating the core infrastructure. As discussed later, excessive growth in Solana infrastructure dependency on a single entity is not ideal.

3. MEV: The Obstacle to Innovation, and Jito as a Necessary Evil

MEV on Ethereum is intuitive. Transactions broadcast to a public mempool, and bots exploit this information to insert themselves before or after, or reorder transactions for profit. Solana has no in-protocol mempool. Transactions are delivered directly to the current leader validator via QUIC rather than accumulating in a public queue. This structure should make MEV nearly impossible, yet MEV on Solana is highly active.

3.1 Before Jito

Even without a mempool, competition over transaction ordering was fierce. Without a mempool, the order in which the leader receives transactions decisively influences execution order. MEV bots exploited this by sending the same arbitrage transaction hundreds or thousands of times in a latency war.

According to Jito Labs research, before Jito's introduction, over 60% of Solana block compute units were consumed by arbitrage bot transactions, with 98% of those arbitrage attempts failing. Spam transactions dominated the network. Normal user transactions were pushed back and trade execution was highly unstable, far from the fast, reliable on-chain capital market Solana envisioned.

3.2 The Jito Block Engine

Jito launched the Jito-Solana client in 2022 to address this problem, forking Solana Foundation's Agave client with an off-protocol MEV auction system added.

A Bundle is an atomic execution unit of up to 5 transactions, all-or-nothing. If any transaction in the bundle fails, the entire bundle is rolled back. Searchers attach a tip (minimum 1,000 lamports, separate from in-protocol fees) to their bundle and submit it to the Block Engine, which selects the highest-tip bundle and delivers it to the leader.

Jito replaced the 98%-failure-rate spam war with a single auction, dramatically reducing wasted compute resources. But new problems emerged. A structure was created in which transactions must pass through Jito's off-chain infrastructure before execution to enable MEV extraction.

Solana, which had no mempool by design for performance reasons, now had a private mempool created by Jito, and transactions became more likely to be dropped. Even if a searcher submits a bundle, losing the auction means rejection; if an uncled block occurs (one not accepted by the supermajority), the bundle's atomicity breaks and individual transactions may be rebroadcast without ordering guarantees. This is the structural explanation behind the "transaction dropped even though I definitely sent it" experience familiar to anyone who has used Solana.

3.3 Structural Latency from Jito

As noted, Solana's average slot time is 400ms. But Jito-Solana's Relayer does not immediately forward incoming transactions to the leader. It holds them for the duration of the Block Engine auction window, giving searchers time to submit MEV bundle bids. Until mid-2025 this was 200ms; it has since been reduced to 50ms.

All transactions reaching a Jito-Solana validator pass through this Relayer. At peak Jito-Solana dominance (~87% of stake in mid-2025 per Blockworks), the vast majority of Solana blocks were produced on top of this delay structure. Holding user transactions to generate additional revenue for the network is fundamentally at odds with Solana's stated goals.

3.4 Economic-Incentive Monopoly

The reason Solana validators choose Jito is simple: MEV tips from searchers provide meaningful additional revenue. According to Blockworks Research, Jito tips accounted for 30% of validator revenue in January 2025. Not running Jito means offering lower APY than competitors and losing delegated stake. Individually rational, but at the ecosystem level it represents economic dependency on a single infrastructure provider.

Jito's Block Engine has become the critical path for Solana transaction processing. If this system fails, MEV flows are paralyzed.

3.5 Geographic Disadvantage

Jito currently operates 8 global Block Engine nodes:

• Europe: Amsterdam, Dublin, Frankfurt, London (4 nodes)

• North America: New York, Salt Lake City (2 nodes)

• Asia: Singapore, Tokyo (2 nodes)

Source: JITO docs

Validators seeking to maximize MEV have strong incentives to colocate in Europe or North America to minimize Block Engine latency. South America, Africa, and Oceania have no Block Engine nodes at all. Searchers in those regions are structurally disadvantaged in bundle auctions; validators face delayed receipt of high-value bundles and lower MEV tip revenue; and ordinary users experience slower, less reliable transaction settlement. For a chain claiming to be "the backbone of global capital markets," the geographic disparity is significant.

The ICM roadmap itself cites geographic decentralization as a core value. It argues that distributing validators globally is necessary for market events in Tokyo to reach the chain faster than from New York. Yet Solana's MEV incentive structure is excessively dependent on the geographic placement of Jito's Block Engine nodes. Solutions are needed: either reducing protocol-level dependency on Jito, or strengthening the geographic distribution of Jito's Block Engine.

3.6 MEV Delayed Firedancer Adoption

The most concrete example of MEV directly obstructing Solana infrastructure development is Firedancer.

When Frankendancer launched on mainnet in September 2024, only 12 validators ran it, representing just 5.4M SOL out of 392M total. Temporal engineering partner Ben Coverston explained directly: "The main reason most validators aren't using Frankendancer is that it doesn't capture MEV efficiently."

Frankendancer launched without Jito Block Engine integration. For validators, switching meant sacrificing revenue for network performance and decentralization. Only after Jito released an official Firedancer integration guide did adoption surge. Beyond making Solana's transactions wait, Jito's influence extends to governing the pace of infrastructure improvement itself.

3.7 The Rise of Harmonic and Rakurai

Jito's monopoly on Solana blockspace has been slowly fracturing since late 2025 with the emergence of Harmonic, an open block-building marketplace for Solana. Launched in November 2025 with a $6M seed round led by Paradigm, Harmonic allows multiple independent builders to compete by submitting block candidates, with validators selecting the most profitable. The structure resembles Ethereum's PBS (Proposer-Builder Separation).

"Block building should not be a black box" is Harmonic's core message. As of March 2026, Harmonic-based clients hold 16.9% of stake. Notably, Harmonic's co-founder is Ben Coverston, the same person who explained that Firedancer's low adoption was because "it doesn't capture MEV efficiently."

Rakurai is another notable alternative: a high-performance validator client forked from Agave, focused on optimizing transaction scheduling to pack blocks more efficiently and increase validator revenue. If Harmonic is "introducing competitive markets for block building," Rakurai is "a faster and more efficient block builder." In March 2026, Figment announced that after migrating its primary validator to Rakurai, Jito MEV tip capture increased 5x.

Meaningful alternatives to Jito's monopoly on Solana's blockspace market are emerging.

4. Solana's Long-Term Roadmap

4.1 MCL and Protocol-Level ACE (2027+)

The most ambitious proposals in the ICM roadmap are MCL (Multiple Concurrent Leaders) and protocol-level ACE.

Currently, Solana operates a single-leader model. The validator that becomes leader for a given slot has monopoly control over which transactions are included and in what order. MEV is fundamentally the abuse of this authority.

MCL allows multiple leaders to simultaneously produce blocks within a single slot. If one leader attempts to censor or reorder a transaction, another leader can include it, removing the structural basis for MEV at the protocol level. The ICM roadmap emphasizes that MCL carries significance beyond just reducing MEV: having multiple leaders globally receiving information simultaneously aligns perfectly with geographic decentralization goals.

If leaders exist by region, market events in Tokyo could reach the Tokyo leader before the New York leader, getting included in the block first. This roadmap can resolve geographic inequality inherent in the current architecture.

Protocol-level ACE allows apps to directly control their transaction ordering on-chain. Unlike BAM's off-chain TEE-based ACE, protocol-level ACE enforces app ordering rules at the protocol layer without relying on validator cooperation.

Why protocol-level ACE matters is illustrated by Robinhood's choice in May 2025. Robinhood was evaluating Solana and an Ethereum L2 built on Arbitrum Orbit as the base layer for its EU tokenized stock trading platform. The final choice was a custom L2 built on Arbitrum Orbit. Industry analysts attribute this partly to the need for fine-grained control over transaction sequencing and infrastructure-level customization: requirements that Solana, lacking protocol-level ACE, could not yet meet. ACE is not merely a performance upgrade; it is a prerequisite for Solana to accommodate institutional-grade financial applications.

4.2 APE: Separating Consensus from Execution

APE (Asynchronous Program Execution) addresses Solana's structural bottleneck at the most fundamental level. Relevant SIMDs have been filed (SIMD 192, 290, 297, 298, 301), and implementation complexity is expected to decrease after Alpenglow is deployed.

Currently, a transaction must complete execution before it can be included in a block; consensus and execution share the same critical path. APE separates the two.

The core concept is separating execution domains. APE divides Solana's program execution into two independent domains. The VED (Vote Execution Domain) handles only consensus voting-related programs; the UED (User Execution Domain) handles regular user transactions. The two domains cannot read or write each other's account state.

With this separation, validators can proceed with voting before user program execution completes. Transaction inclusion latency decreases, and consensus is no longer bottlenecked by execution. Combined with Alpenglow's 150ms finality, real-world perceived speed improves even further.

5. Conclusion

A consistent pattern emerges from examining Solana's infrastructure development. Even when there is a technically correct direction, economic incentives can block the path to it. MEV is the clearest example. The Solana ICM roadmap ultimately acknowledges that the core problem of on-chain capital markets is not raw TPS, but market microstructure. Specifically, how orders are settled, in what sequence, and under what rules.

Solana aims to use technology itself, rather than ideological blockchain values, to build infrastructure superior to non-blockchain systems. The goal is not simply the fastest blockchain, but the fastest trading network for capital markets. The roadmap and technical approach Solana is pursuing are sound. But if this roadmap fails to realign the ecosystem's incentives during implementation, the problems will resurface in different forms.

Solana drove the last memecoin boom. I don't believe that was accidental narrative luck. Through it, Solana proved numerically that it is a network capable of handling massive trading traffic.

But for Solana to become a true on-chain Nasdaq, it must solve at the protocol level what Nasdaq took decades to build. "There are no zealots in Solana, only pragmatic engineers" is both a strength and a weakness. Ideology-free pragmatism enables rapid execution, but it also means long-term design principles can easily be compromised in the face of short-term revenue incentives. The pursuit of incentives is not inherently wrong. The challenge is aligning the direction of infrastructure development with the direction of incentives.