Skip to main content

What is MEV (Maximum Extractable Value) and How to Protect Your Transactions on Solana

Updated on
Feb 14, 2025

12 min read

Overview

For developers building DeFi applications and trading bots on Solana, understanding MEV (Maximal Extractable Value) is critical. MEV can impact your users' trade execution or threaten your own bot's profitability. Higher costs, lower profits, and increased network friction are common consequences of unprotected MEV exposure. This guide covers the fundamentals of MEV on Solana, including transaction flow mechanics, common MEV types, and the growing risks for developers building on the network. You'll learn key strategies to mitigate MEV's negative impacts and safeguard your transactions from manipulation.


Introduction to MEV on Solana

Maximum Extractable Value (MEV) refers to the maximum value that can be extracted from users' transactions by reordering, including, or excluding them within a block. In a Proof-of-Stake network like Solana, the validator who is the block producer has the ability to decide which transactions go into that block and in what order. This means a malicious or profit-seeking block producer could reorder transactions (or insert their own) to capture arbitrage profits, front-run users, or otherwise capitalize on transaction ordering. Although Solana does not have a public mempool like Ethereum, MEV still exists—often through direct node connectivity, private mempools, or other specialized infrastructure.

For developers building trading bots or decentralized exchanges (DEXs), failing to account for MEV can lead to:


  • Worse trade execution (e.g., sandwich attacks).
  • Lost profits (bots front-running your trades).
  • Network congestion issues (impacting the ability to land your transactions on the network).

DeFi activity on Solana has boomed in 2024, and with it, so has the growth in MEV. Messari demonstrates Solana's Real Economic Value (fees + MEV) growth over time:

Messari - Solana Total Economic Activity Source:Messari: State of Solana - Q4 2024

Though most of MEV is quite small, there are countless examples where transactions are extracted for tens of thousands of dollars (see screenshot below) and even instances of million-dollar trades.

Jito - Arbitrage Explorer Source: Jito - Arbitrage Explorer

For developers building DeFi applications and trading bots on Solana, understanding MEV is critical. MEV can impact your users' trade execution (causing unexpected slippage or failed trades) and even your own bot's profitability if a competitor can intercept or reorder your transactions. Let's recap some fundamentals about transaction flow on Solana, review common types of MEV on Solana, and discuss steps you can take to protect your transactions from MEV.

Solana Transaction Flow

Solana's transaction pipeline has some key differences from Ethereum's that influence how MEV plays out:

  • No Global Mempool: Unlike Ethereum, Solana has no unified public mempool where pending transactions sit waiting for inclusion. Instead, Solana uses the Gulf Stream protocol to forward transactions directly to the next expected block leader (validator) before it's their turn to produce a block. This means there isn't a long-lived pool of visible pending transactions for bots to monitor network-wide. Every Solana transaction includes a recent blockhash and expires after ~150 slots (~1 minute) if not confirmed. In short, transactions either get picked up quickly by a leader or are dropped--no persistence in a mempool. This reduces the window for MEV strategies like observing and front-running public pending transactions, though determined searchers mitigate this by running their own nodes to see transactions as they stream in.

  • Stake-Weighted Quality-of-Service (QoS): Solana prioritizes incoming transaction traffic based on stake. Validators allocate most of their inbound capacity to clients/forwarders proportional to stake weight. In practice, this means transactions coming from or through highly-staked nodes are less likely to be dropped during periods of congestion. Stake-weighted QoS acts as a Sybil-resistance mechanism: spammers with no stake have their packets de-prioritized, while transactions via well-staked validators get faster treatment.

  • Priority Fees (Local Fee Markets): Solana utilizes priority fees as an optional additional fee users can attach to transactions to improve their chance of quick inclusion when the network is busy. Normally, Solana transactions have a very low flat fee, but with heavy traffic (e.g. NFT mints or memecoin trading mania) causing congestion, users can specify a priority fee per compute unit to essentially bid for block space. Validators earn 50% of these priority fees and the other 50% is burned by protocol rules (though this may change through Solana's SIM process), so a higher priority fee makes a validator more likely to include your transaction. Priority fees were designed to combat spam and allow time-sensitive transactions to "jump" to the front of the "queue". On Solana, this creates a local fee market per compute unit per block. As of 2024, priority fees constitute a large portion of Solana's total fee revenue, highlighting how users are indeed bidding for priority during congestion. For developers, this means that in a crowded block, your transaction likely needs a priority fee to beat out spammers or competing trades.

Common Types of MEV on Solana

Here are the most common types of MEV that Solana developers should be aware of:

Arbitrage

Arbitrage is one of the most prevalent forms of MEV on Solana. Arbitrage typically involves the atomic buying and selling the same asset across multiple exchanges. The arbitrager executes a buy on the cheaper market and a sell on the pricier market, pocketing the difference, for example:

- $199 (Bot buys 1 SOL for 199 USDC on DEX A)
+ $200 (Bot sells 1 SOL for 200 USDC on DEX B)
-------------------------------------------------
+ $1 (Bot net gain $1)

Because Solana allows composing multiple instructions in one transaction, searchers often perform atomic arbitrage (both legs within one transaction) to ensure the trade is effectively risk-free. Failed transactions will cost the buyer their priority fees, so they need to balance the opportunity size and priority fee market.

The competition for arbitrage on Solana is fierce -- bots will spam many transactions attempting arbitrage. Solana's low fees mean bots can fire off a high volume of arb transactions; even if most fail or find no profit, the occasional success can pay off. In fact, it's estimated that over 50% of Solana's transactions are actually failed arbitrage attempts (spam)--bots blindly trying to capture price discrepancies (Ref: Solana MEV - An Introduction). Though this can be an issue for network congestion, it generally means that prices are able to stay in balance across the various DeFi platforms.

Sandwich Attacks

A sandwich attack is a classic negative MEV strategy that has also appeared on Solana. In a sandwich attack, a victim user's trade is “sandwiched” between an attacker's transactions: one that is executed right before the victim's trade and one right after. Suppose a user submits a large swap on a DEX; an MEV searcher who learns of this pending swap can quickly submit their own buy of the same asset just before the user's trade (driving the price up), then let the user's large buy execute (at the now higher price), and finally, immediately sell the asset right after the user's trade at that inflated price. The attacker earns a profit from buying low and selling higher, while the victim receives a worse price on their swap (higher slippage).

As a developer or trader, you should be aware that if a third party can observe your swap before it is finalized, they might attempt to sandwich it. High slippage tolerances set by users make them especially vulnerable--if a user allows up to 5% slippage, a sandwich bot can exploit most of that range for profit. Mitigating slippage,sandwich risk involves slippage, privacy, and ordering control.

Liquidations

Liquidations are another important MEV opportunity, especially in Solana's DeFi lending protocols (e.g., Marginfi, Kamino, Save, etc.). When a borrower's collateral value falls below the required ratio (i.e. their loan is under-collateralized), that position becomes eligible for liquidation. Liquidators (typically bots) can repay part or all of the loan on the borrower's behalf and in return claim some of the collateral at a discount. This essentially yields a profit for the liquidator, as they buy collateral cheaper than market price.

MEV searcher bots constantly scan the on-chain state and oracle price feeds to detect positions about to go bust. When they find one, they race to send the liquidation transaction to seize the bonus. On Solana, since there's no public mempool, liquidation bots instead ensure they are as fast as possible to notice the on-chain change (like an oracle price drop or a health factor crossing a threshold) and then immediately send a liquidation transaction to the current leader. If multiple bots try to liquidate the same account, only the first to land in the block wins the reward, and others' transactions fail. Liquidations are considered essential for protocol health (they prevent bad debt).

Jito Bundles and Other MEV Applications

Solana's MEV landscape is evolving, and Jito bundles have played a big role in how MEV is extracted (and potentially mitigated). Validators running the Jito-Solana client participate in an off-chain block-building market. Searchers send bundles of transactions (and associated tip payments) directly to these block builders rather than the normal Solana gossip network. The block producer then includes the highest-paying bundles in the block, earning the tip. This system allows MEV searchers to implement strategies like arbitrage, liquidations, and sandwiching privately (their transactions aren't public until included) and with priority, as long as they pay a competitive tip. The result has been a significant source of revenue for Solana validators. Most of Solana's malicious MEV comes from privately operated mempools.

The Risks of MEV for Solana Developers

MEV poses several risks and challenges for developers on Solana, especially those building trading bots or DEX applications:

  • Transaction Reordering by Validators: Because Solana validators can order transactions in the blocks they produce, a validator could reorder transactions to its advantage. For example, if your DEX trade would produce an arbitrage opportunity, a validator could insert their own trade before yours to capture that profit. This could leave your transaction with worse output or even causes it to fail (if the opportunity is gone). The order in which transactions execute can drastically affect outcomes in DeFi, and without protection, your transactions are at the mercy of the block producer's incentives.

  • Spam and Network Congestion: A huge volume of Solana transactions are MEV-driven (arbitrage spam, etc.). In times of contention (like a hot NFT mint or volatile market), your legitimate transactions are competing with a flood of bot transactions. This can lead to increased latency or failure rates if you don't account for it. Your transactions might get dropped if they hit a validator that's overloaded or if you submit via an unstaked node during a spam storm. You may need to attach priority fees to cut through the noise. Essentially, MEV activity can crowd the highway that your transaction is trying to travel on, so you'll need to plan for that (higher fees, retries, etc.) if unprotected.

  • Increased Slippage and User Experience Issues: For DEX developers, MEV can directly harm your users. A user might set a 1% slippage tolerance on a trade, but due to MEV (like a sandwich), they end up getting the full 1% worse price. In extreme cases, MEV bots can push the price such that the user's transaction fails (exceeding slippage) after the bot has already taken the profit. This can result in a poor user experience — failed trades or unexpectedly bad rates. Users may blame the DEX or the blockchain for these outcomes. Thus, not protecting against MEV can undermine confidence in your platform. It can also make it harder for your trading bot to reliably execute strategies since outcomes become less predictable when an adversary can insert transactions that affect your trade.

In summary, MEV in Solana can lead to higher costs, lower profits, and network friction. Developers should be conscious of these threats and consider measures to mitigate them, especially for any application where transaction ordering impacts financial outcomes.

Protecting Transactions Against MEV

There are many tools to prevent or limit the negative impacts of MEV on your trading and your users. Every use case is unique, so not every tool may be applicable to your use case.

  • Protect Your Transaction: Utilize QuickNode Add-ons. The QuickNode Marketplace offers several tools for increasing transaction land rate and minimizing exposure to MEV. The Lil' JIT - Jito Bundles & Transactions add-on allows you to bundle transactions for fast-landing sequential execution, which includes MEV and revert protection. Additionally, the Marketplace offers the ability to add MEV protection to sendTransaction calls on your existing endpoint, by utilizing the Solana MEV Protection & Recovery add-on. This add-on not only provides front-running protection but also enables MEV recovery (returning captured non-malicious MEV to you), enhances privacy, and ensures rapid execution.

  • Protect Unwanted State Changes: Utilize Transaction Guards. Lighthouse is a runtime assertion Solana program designed to fail a transaction when on-chain state is found to have diverged from an expected state. You can add lighthouse instructions to your transaction to ensure the state of specified accounts at the end of your transaction executed meets the pre-defined expected state (e.g., if after this transaction, a specified token balance is less than X, reject the entire transaction). This allows for more complex account checks than simply slippage and also enables assertions on the Sysvar (slots), which could be used to blacklist validators -- this could be achieved by utilizing getLeaderSchedule and a list of malicious validators.

  • Set Limits: Set Slippage & Utilize Limit Orders. When performing swaps, always set slippage to the level appropriate for your trade and risk tolerance. Assume bad actors are looking to exploit any opportunity that your slippage rate allows. When your use case allows, utilize limit orders to set a minimum price you are willing to receive for the sale of a token. Check out QuickNode's Metis API, which supports limit orders.

  • Prevent Transaction Failure: Optimize Your Transactions. Because MEV drives massive amounts of transaction spam traffic to the network, your transactions must be properly structured to ensure inclusion in a given block. In short, you must request the proper amount of compute units, offer competitive priority fees, and assemble your transaction properly (Check out Strategies to Optimize Solana Transactions or Tips to Improve Jupiter Swap Landing Rates on Solana for additional detail). QuickNode's Priority Fee API and Send Smart Transaction methods can help make this process easier for you.

  • Be Stake Aware. Know Your Validator. Different validator and validator clients have different approaches to handling MEV. Though this will not directly impact your transactions, your stake (and others) can influence the overall validator network health and governance around MEV. Here are a few resources: Jito Validator Client, Marinade: Democratizing MEV, Paladin Validator Client.

  • Participate. Solana Improvement Documents (SIMDs). The Solana Foundation operates an open source GitHub repository, Solana Improvement Documents where community members can propose ideas and comment on existing ones. Discussions around MEV, network fees/rewards, etc. are on-going. If you have an opinion, get involved!

  • Consider RFQ and Express Relay Systems. For advanced applications, consider Request for Quote (RFQ) systems (e.g., JupiterZ) and Express Relay provide MEV protection through private order flow channels and isolated priority auctions. These systems connect protocols directly with searchers, removing validators from MEV extraction and enabling more efficient pricing. Key benefits include private transaction routing, direct competition between searchers, and reduced integration costs.

Wrap Up

MEV is an important factor to consider when building on any blockchain, and Solana is no exception. We've learned that Solana's design changes the playing field, but MEV still arises through arbitrage, liquidations, and sandwich attacks. As a developer of Solana DeFi tools, ignoring MEV could mean your application's users get subpar trade outcomes or your bot misses out on profits. The good news is that many tools exist to empower you to mitigate those issues, giving you back control over transaction ordering and even capturing MEV for yourself or your users.

Additional Resources

Share this guide