Solana’s performance is often described in terms of throughput and latency, but the real user experience is shaped by something more subtle: how a transaction moves from intent to execution. 

Between wallets, RPCs, validators, schedulers, fee markets, and MEV infrastructure sits an evolving transaction supply chain that determines whether transactions land reliably, fairly, and on time. 

This blog traces how that supply chain has changed and why its design now matters as much as raw block speed.

Transaction Entry

Solana Remote Procedure Call Services (RPC services) are the fundamental infrastructure that acts as the gateway between all decentralized applications (dApps), wallets, developer tools, and the Solana blockchain itself. 

From a user perspective, poor RPC performance is no different than poor blockchain performance. To give users a great experience and show off Solana’s speed and low-latency, it is important to have RPC infrastructure that is up to the task.

In Solana’s early days, transactions were built in the user's local machine and then submitted to RPC nodes, which were typically dedicated as entry points rather than participating in consensus. RPC nodes then broadcast them toward the current (and next) leader. The process utilized a protocol called UDP. UDP was fast and simple, but connectionless and without built‑in flow control or delivery acknowledgments. Under heavy load (congestion, spam, or validator overload), packets could be dropped before ever reaching the leader’s transaction queue, leaving users with little control beyond retrying.

December 2022 Agave update v1.13.4 came with significant improvements. QUIC - a modern transport that adds sessions, acknowledgments, and congestion control on top of UDP - became the default protocol for transaction ingestion. This allows limits to be placed on individual traffic sources so the network can focus on processing genuine transactions. Stake-weighted QoS (Quality of Service) - an implementation feature which, when enabled, allows leaders (block producers) to identify and prioritize transactions proxied through a staked validator as an additional sybil resistance mechanism. 

Operators who enable this feature will improve the security and performance of the network by reducing the likelihood that low-or no-stake (lower quality) validators are able to “drown out” transactions emanating from higher-quality (higher stake) validators. This paved the way to certain agreements between Validators and RPC nodes. RPC nodes may land more transactions in blocks by agreeing to peer with Validators, and Validators may sell more capacity to RPC nodes, for example, BloxRoute and Marinade. Some RPC providers run their own validators with delegated stake pools, for example Helius.

Transaction Landing

On April 30, 2022, Solana experienced an unprecedented surge in transaction requests. Some nodes reported reaching six million requests per second, generating over 100 Gbps of traffic per node. 

This surge was driven by bots trying to secure newly minted NFTs through the Metaplex Candy Machine program. This minting mechanism operated on a first-come, first-served basis, creating a strong economic incentive to flood the network with transactions and win the mint. As transaction volume skyrocketed, validators ran out of memory and crashed, ultimately stalling consensus. 

The network restart took less than 1,5 hours after the canonical snapshot had been agreed upon. However, fundamental issues remained unresolved. The leader still processed transactions, contending for the same account data on a first-come, first-served basis without effective spam prevention, leaving users unable to prioritize the urgency of transactions. To address this priority fee was introduced. This fee-to-compute-unit ratio determines a transaction’s execution priority, ensuring a more dynamic and market-driven approach to transaction ordering, creating the Solana local fee market.

Solana can process transactions in parallel because each transaction must describe all the states it will read or write while executing. This allows non-overlapping transactions to execute concurrently. Hence, transactions targeting the same accounts will be executed sequentially, but leaving other threads free, thus these transactions create a localized priority fee structure. Local fee markets prevent localized hotspots from raising fees across the entire blockchain. In November 2024, the average fees for non-vote transactions reached an all-time high of over 0.0003 SOL. However, median fees remained steady at 0.00000861 SOL, approximately 35x lower. We can see that choosing the “right” priority fee is non-trivial as network demand fluctuates not just by slot, but also by the dApp. 

Without a deterministic method for calculating priority fees, developers often take a cautious approach by overpaying to guarantee their transactions are processed. Alternatively, they may overuse Jito tips as an alternative mechanism, even for transactions where securing the top-of-block is unnecessary. 

Due to these technical developments, modern Solana‑focused RPCs (e.g., Helius, QuickNode, Alchemy, others) differentiate from the outdated basic JSON‑RPC API by:

• Dynamic priority‑fee bidding
• QUIC‑native, multi‑leader broadcast: Maintain QUIC sessions to the current and next leaders, rebroadcasting intelligently until expiry while honoring blockhash lifetimes and avoiding stale forks.
• Staked ingress (SWQoS) Pair RPC frontends with staked validators (their own or trusted partners) so your transactions enter through a stake‑prioritized path during congestion.
• Better confirmation signaling: Use websockets l for fast feedback, then escalate to higher commitments for certainty, matching your app’s risk tolerance.

Modern upcoming RPC services also offer additional advanced features. 

LYS Labs lets users specify their intents (buy, sell, borrow,...) with certain parameters and conditions. LYS Labs server decodes, streams, and processes block data. This allows the server to build users’ transactions and sets priority fees dynamically based on the newest information to substantially improve the landing rate. With data availability, certain trades requiring 50+ RPC pings can be enabled in one RPC call, which saves money and avoids the rate limit. The user's private key is stored in a Trusted Execution Environment (TEE), which requires certain security assumptions and opens new attack vectors.

Besides the features above, Raiku also offers Ahead of Time (AOT) transactions, which are designed for users who require absolute certainty for planned operations. AOT allows users to pre-purchase a guaranteed inclusion slot for a transaction at a future time (35+ slots or >15 seconds ahead). 

This is indispensable for institutional settlements, scheduled oracle updates, complex DeFi operations like vault rebalancing, and large-scale batch processing. AOT transactions are priced via an open English-style auction, where users can bid against each other in real time for specific future slots. This allows for more efficient price discovery for planned blockspace and often rewards users who plan ahead with potentially lower fees.

On Solana and most other blockchains, nodes/validators sell one product, which is blockspace. Technical advancements and innovation, either in the blockchain itself or integrated protocols, expand the variety and customization of this product, and with it comes the premium, additional revenues for nodes/validators.

Transaction Bundling And MEV

Now transaction landing is far more reliable, the economic outcome of a transaction can still be degraded by toxic Maximal Extractable Value (MEV) - for example, order sandwiching. MEV on Solana operates differently from other blockchain networks due to its distinctive architecture and the lack of a global mempool. Out of protocol mempools must be developed independently, requiring adoption by a significant portion of the network’s stake to function effectively, which presents a high technical and social barrier. The MEV market is organized around searchers, validators, and relays/block engines that auction ordering rights. This structure improves efficiency but can also create avenues for abuse if not carefully governed.

In August 2022, the Jito Solana client was launched and has now become the default Solana MEV infrastructure. When leaders use the Jito client validator, their transactions are initially directed to the Jito-Relayer, which functions as a transaction proxy router. This relayer holds transactions for 200 milliseconds before forwarding them to the leader. 

This speed bump delays incoming transaction messages, providing a window for off-chain auctions via the Jito Block Engine. Searchers and applications submit bundles of atomically executed transactions together with a tip dominated in SOL. For its first nine months, the Jito-Solana client's adoption remained under 10% as network activity remained low and MEV rewards were minimal. Starting in late 2023, adoption accelerated significantly, reaching 50% by January 2024. Today, over 92% of Solana’s validators, weighted by stake, use the Jito-Solana client. 

If a pending transaction reveals a large trade (e.g., an AMM swap with generous slippage), searchers (MEV bots) could copy that signed transaction from a mempool/relay to sandwich it. Jito (the dominant MEV/block‑engine stack on Solana) used to provide a public mempool stream. That stream gave searchers a short preview window of pending user transactions. In March 2024, after weeks of mounting complaints about retail users being sandwiched, Jito shut down the public mempool stream. 

After the shutdown, the sandwiching fell, but didn’t vanish. Order flow shifted to private mempool. Several analyses attribute a large portion of remaining sandwiches to a DeezNode-operated private mempool and a single associated program/validator, highlighting how opacity re‑centralizes power.

Besides Jito clients, there are several other MEV-related projects in the Solana ecosystem, including Spur and Paladin. All of them sit in roughly the same design space, modified validator clients and block-building infrastructure, but they take very different approaches to how MEV is discovered, auctioned, and shared.

Spur is, like Jito, a modified validator client, but it changes who does the MEV work. Instead of relying on external searchers to submit specialized “bundles” of transactions, the Spur protocol itself searches for MEV opportunities directly. In other words, MEV extraction is more “in-house” rather than outsourced to third parties. Because the protocol is doing the work of finding and executing profitable opportunities, Spur is designed so that a higher percentage of the MEV revenue is shared back with the validators running Spur, rather than being captured primarily by searchers or external block builders.

Paladin takes a different route. Each Paladin-enabled client includes a built-in Paladin bot that activates when that validator becomes the leader for a slot. When it’s that validator’s turn to produce a block, the Paladin bot scans for profitable trades and opportunities. By default, its strategy focuses on beneficial arbitrage—things like aligning prices between different DEXes or markets—rather than predatory tactics. This type of “good MEV” can actually help the ecosystem by tightening spreads and maintaining price efficiency across markets, making it less likely that users trade at stale or wildly off-market prices.

A major criticism often directed at Jito is the centralization of its block engine. In the Jito design, bundle auctions, where searchers compete to have their bundles included, are run through a single, centralized Jito block engine. This creates a potential single point of failure and a locus of control: if the block engine has issues, is censored, or becomes captured by certain interests, the entire MEV flow for Jito validators can be affected.

Harmonic, an upcoming project, is positioned as a response to that concern. It aims to be an open builder market that aggregates blocks from multiple independent builders instead of relying on a single engine. Validators running Harmonic can receive block proposals from many builders and instantly choose the one that’s both the most valuable (in terms of fees/MEV) and best aligned with their own preferences or policies. This builder diversity helps reduce correlated failures (everyone breaking at once because of one centralized component) and lowers lock-in risk, since validators aren’t tied to a single block engine. In theory, this should create a more competitive, resilient, and decentralization-friendly MEV ecosystem.

Suave, a cross-chain intent marketplace, can act as an additional layer on top of Harmonic. Users submit intents that may span multiple blockchains, and an agent accepts an intent only if it is confident it can be executed successfully (for example, a cross-chain arbitrage between Ethereum and Solana). An agent can reliably execute such intents by participating in the block-building marketplaces on both Ethereum and Solana and winning the relevant bids on each chain at the same time. This expands the available MEV surface across chains, creating additional revenue opportunities for agents and, ultimately, higher income for validators.

Application-Specific Transaction Ordering

In the coming years, Solana will need to clearly define its role among competing blockchain ecosystems. Ethereum, with its horizontal scaling via L2s, is increasingly positioned as a global settlement layer, particularly attractive for institutional and high-value use cases. Solana, by contrast, is leaning into its comparative advantages, high throughput, low latency, and low fees, to become an on-chain capital market, effectively a decentralized Nasdaq where most of the actual trading and price discovery happens.

However, the fundamental primitives of today’s blockchains were not designed with high‑frequency trading in mind. Even on Solana, where mechanisms like priority fees and Jito tips exist, transaction ordering and inclusion remain probabilistic and often unpredictable. For latency-sensitive strategies, it is still difficult to know when a transaction will land in a block and what will be executed before or after it.

This unpredictability is exacerbated by the fact that application teams can also be infrastructure operators. A dApp that runs its own validator can prioritize its own transactions regardless of what other users are paying in priority fees or MEV tips. Recently, this has been especially visible in the context of proprietary AMMs (propAMMs), where a fast, early oracle price update at the beginning of the block is critical. By ensuring their own maintenance or oracle transactions land first, these protocols reduce their exposure to arbitrage on stale prices, but they also implicitly bend the fee market and order guarantees in their own favor.

The validator’s scheduler and transaction selection algorithm further complicate the picture. Some schedulers construct the block gradually over the whole slot, adding transactions as they arrive. Others wait and assemble the block in the final few milliseconds, making sure to select the most profitable combination of transactions at the very end. This “last 10 ms” strategy can increase fee and MEV capture, but pushes close to Solana’s 400 ms slot budget and increases the risk of slot lagging, slots effectively stretching beyond their intended duration. In practice, some validators even deliberately extend slot time to ingest more transactions and collect additional fees, at the expense of network latency, throughput guarantees, and overall user experience.

‍

All of this behavior cascades into some pretty serious consequences for Solana’s market microstructure:

• Execution becomes less deterministic. Users and applications can’t reliably predict when a transaction will land in a block, or what will execute immediately before and after it, even if they pay aggressive priority fees or Jito tips.
  
  
• Blocks behave differently from leader to leader. Each validator may run a different scheduler or custom logic, so the effective matching rules change every slot. That makes it much harder to backtest strategies, simulate fills, or reason about execution quality in a clean, modelable way.
  
  
• Market makers pull back. When you don’t have strong, repeatable execution guarantees, professional liquidity providers face higher adverse selection and inventory risk. They either quote wider spreads, shrink size, or simply don’t participate in certain venues. Over time, this widens the spread and degrades market efficiency.
  
  
• Users leave for better venues. Worse apps, more slippage, and unreliable fills mean traders gravitate toward environments with tighter spreads and more predictable execution, centralized exchanges, rollups with custom match engines, or app-chains. Liquidity and order flow leaking away is the opposite of the “on-chain Nasdaq” vision.

To move Solana toward that role, the primary on-chain capital market, new execution primitives are needed that make ordering more predictable, auditable, and application-controlled. Two complementary directions are Jito BAM and Temporal’s Fermi DEX.

Jito’s Block Assembly Marketplace (BAM, often called JitoBAM) is a redesign of how blocks are built and how transactions are sequenced on Solana. Instead of each leader locally deciding ordering via its own scheduler, BAM introduces a shared, programmable sequencing layer that sits in front of validators.

BAM nodes run inside Trusted Execution Environments (TEEs) and maintain an encrypted mempool. Transactions sent to BAM are private until execution, which reduces many forms of predatory MEV such as classic mempool sandwiching, even though using TEEs introduces some computational overhead, requires some additional trust assumptions, and opens new attack vectors.

BAM exposes a plugin framework where applications can define their own custom sequencing rules - things like “always process maker cancels before taker trades”, “apply a tiny speed bump to toxic taker flow”, or “inject an oracle update immediately before any trade that relies on that price”. Exactly this customization might enable a Solana perp DEX that might compete with Hyperliquid, or a more efficient prop AMM. These plugins run inside the TEE along with the mempool, so their logic is private until execution but still verifiably enforced via attestations.

More importantly, JitoBAM supplies the whole block (unlike the current Jito block engine, where the bundles don’t fill the whole block), so validators cannot create any toxic MEV by insertion, and the scheduler is uniform across all BAM nodes.

On the other hand, Fermi DEX is a Solana-based CLOB that focuses on capital efficiency. The DEX lets traders post limit orders without locking capital up front, i.e., orders express intent to trade, not a precommitted deposit. Orders are matched off-chain in submillisecond time but settle atomically on-chain, so users never relinquish custody or finality guarantees. When an order is matched, Fermi pulls in funds “just in time”, debiting the user’s wallet only at settlement instead of at order creation. Settlement is done via an explicit smart contract call that atomically finalizes trades, and there are penalty and reputation mechanisms to discourage counterparties who fail to deliver JIT liquidity. Fermi DEX also provides a cryptographic sequencing layer that delivers publicly-verifiable, microsecond-resolution FIFO ordering to any blockchain or roll-up. By proving that no one, not even the sequencer, can reorder or censor transactions, Continuum removes the economic drag of MEV and gives every participant an equal shot at best execution.