What is MEV and how to protect your Solana transactions?

Solana’s design has changed the game rules, but MEV still appears through Arbitrage, liquidation, and sandwich attacks.

Written by: QuickNode, ChainNews Community

For developers building DeFi applications and trading bots on Solana, understanding MEV (Maximal Extractable Value) is crucial. MEV may impact the execution of user transactions, or threaten the profitability of your own bot. Higher costs, lower profits, and network friction are common consequences of unprotected MEV risks. This guide covers the basics of MEV on Solana, including transaction process mechanisms, common MEV types, and the increasing risks for developers building on the network. You will learn key strategies to mitigate the negative impact of MEV and protect your trades from interference.

Recommended prerequisite knowledge

• Have a basic understanding of blockchain concepts and Solana (Solana Basics Reference Guide)
• Have a certain understanding of DeFi or TradFi (What is DeFi?)

Introduction to MEV on Solana

The Maximum Extractable Value (MEV) refers to the maximum value extracted from user transactions by rearranging, including, or excluding them. In proof-of-stake networks like Solana, validators as block producers have the ability to decide which transactions go into a block and in what order. This means that malicious or profit-seeking block producers can reorder transactions (or insert their own) to capture arbitrage profits, front-run user transactions, or exploit the order of transactions in various ways. Despite Solana not having a public mempool like Ethereum, MEV still exists—often through direct node connections, private mempools, or other specialized infrastructure.

For developers building trading bots or decentralized exchanges (DEX), not considering MEV may lead to:

• Worse trade execution (e.g., sandwich attack).
• Profit loss (robots execute before you trade).
• Network congestion issues (affecting your ability to successfully submit trades on the network).

In 2024, the DeFi activity on Solana is booming, and at the same time, MEV is also growing. Messari shows the real economic value of Solana (fees + MEV) growing over time:

Source: Messari: Solana Status - 4th Quarter of 2024

Although most MEVs are relatively small, there are countless examples of extracting tens of thousands of dollars from transactions (see the screenshot below), and even cases of million-dollar transactions.

Source: Jito - Arbitrage Explorer

For developers building DeFi applications and trading bots on Solana, understanding MEV is crucial. MEV may impact the execution of user transactions (resulting in unexpected slippage or transaction failures), and even affect the profitability of your own bot if competitors can intercept or reorder your transactions. Let’s review some basic knowledge about the Solana transaction process, examine common MEV types on Solana, and discuss measures you can take to protect your trades from MEV impact.

Solana Trading Process

The trading process of Solana has some key differences from Ethereum, which affects the performance of MEV:

• No global memory pool: Unlike Ethereum, Solana does not have a unified public memory pool to wait for pending transactions to be processed. Instead, Solana uses the Gulf Stream protocol to directly forward transactions to the next expected block leader (validator) before they generate a block. This means that there is no long-lived visible pending transaction pool available for bots to monitor the network. Each Solana transaction includes a recent blockhash, which expires after approximately 150 slots (about 1 minute) if unconfirmed. In short, transactions are either quickly picked up by the leader or discarded - the memory pool is not persistent. This reduces the window for MEV strategies, such as observing and front-running public pending transactions, although determined seekers reduce this by running their own nodes to see incoming transactions.
• Service Quality (QoS) based on stake weighting: Solana prioritizes incoming transaction traffic based on stake. Validators allocate most of their incoming capacity to clients/relays in proportion to their stake. In practice, this means that transactions from or through high-stake nodes are less likely to be dropped during congested periods. Stake-weighted QoS serves as a Sybil resistance mechanism: groups without stake, such as spam senders, are deprioritized, while transactions from well-staked validators are processed faster.
• Priority Fees (Local Fees Market): Solana uses priority fees as an optional additional fee that users can attach to increase their chances of rapid inclusion in the network during busy times. Typically, Solana transactions have very low fixed fees, but in high load situations (such as NFT minting or meme coin trading frenzy) causing congestion, users can specify a priority fee per computational unit, essentially bidding for block space. Validators receive 50% of these priority fees, while the oligopoly burns the remaining 50%, thus higher priority fees make validators more likely to include your transaction. Priority fees are designed to combat spam and allow time-sensitive transactions to ‘jump’ to the front of the ‘queue’. On the Solana network, this creates a local fees market for each computational unit per block. As of 2024, priority fees account for a large portion of Solana’s total fee revenue, highlighting that users are indeed engaging in priority bidding during congestion. For developers, this means that in a congested block, your transaction is likely to need a priority fee to outbid spammers or competing transactions.

Common MEV Types on Solana

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

Arbitrage

Arbitrage is one of the most common forms of MEV on Solana. Arbitrage typically involves buying and selling the same asset across multiple exchanges in an atomic manner. Arbitrageurs buy on the cheaper market and sell on the more expensive one, pocketing the price difference, for example:

Due to Solana’s ability to combine multiple instructions into one transaction, traders often perform atomic Arbitrage (two stages in one transaction) to ensure that the transaction is actually risk-free. A failed transaction will result in the buyer losing their priority fee, so they need to balance the size of the opportunity with the priority fee market.

The Arbitrage competition of Solana is very intense - bots spam numerous trades attempting to Arbitrage. The low fees of Solana mean that bots can execute a large number of Arbitrage trades; even if most fail or are unprofitable, occasional successes can be lucrative. In fact, over 50% of Solana trades are actually failed Arbitrage attempts (spam) - bots blindly attempt to capture price differences (see: Solana MEV - Introduction). While this may be a problem of network congestion, it generally means that prices can be kept in balance across various DeFi platforms.

Sandwich Attack

Sandwich attack is a classic form of negative MEV strategy, which also occurs on Solana. In a sandwich attack, the victim’s transaction is sandwiched between the attacker’s transactions: one executed before the victim’s transaction, and the other after. Suppose a user submits a large-scale coin exchange on a DEX; a MEV searcher familiar with this pending exchange can quickly submit their own transaction to purchase the same asset before the user’s transaction (driving up the price), then allow the user’s large purchase to be executed at the now higher price, and finally immediately sell the asset to profit from the difference. The attacker profits from buying at a low price and selling at a higher price, while the victim receives a worse price in their exchange (higher slippage).

As a developer or trader, you should be aware that if a third party can observe it before your exchange is finalized, they may try to sandwich it. User-set high slippage tolerance makes them particularly vulnerable - if users allow up to 5% slippage, sandwich robots can take advantage of most of the range to profit. Reducing slippage and sandwich risk involves slippage, privacy, and order control.

Clearing

Liquidation is another important MEV opportunity, especially in Solana’s DeFi lending protocols (e.g., Marginfi, Kamino, Save, etc.). When the collateral value of a borrower falls below the required ratio (i.e., their loan is under-collateralized), the position is liquidated. Liquidators (typically bots) can repay a portion or all of the loan on behalf of the borrower and receive some discounted collateral. This essentially brings profit to the liquidators, as they buy the collateral at a price lower than the market value.

MEV search robots continuously scan on-chain state and oracle price data to detect positions on the verge of liquidation. When they find one, they race to send liquidation transactions to seize the bonus. In Solana, due to the absence of a public mempool, liquidation robots ensure prompt awareness of on-chain changes (such as oracle price drops or health factor crossing thresholds), and then immediately send the liquidation transaction to the current leader. If multiple robots attempt to liquidate the same account, only the first transaction successfully included in a block will receive the reward, while others will fail. Liquidation is considered a fundamental guarantee of protocol health (preventing bad debts).

Jito Bundles & Other MEV Apps

Solana’s MEV ecosystem is developing, and Jito Bundles plays an important role in the extraction (and potential mitigation) of MEV. Validators running the Jito-Solana client participate in the off-chain block building market. Searchers directly send bundled transactions (and associated fee payments) to these block builders, rather than through the normal Solana gossip network. Subsequently, block producers include the bundled package with the highest fee payment in the block, from which they earn fees. This system allows MEV searchers to privately execute Arbitrage, liquidation, and sandwiching strategies (their transactions are not public before being included), as long as they pay competitive fees to prioritize processing. As a result, this brings significant income to Solana validators. Currently, Solana’s malicious MEV primarily comes from privately operated memory pools.

Risks of MEV to Solana developers

MEV brings various risks and challenges to Solana developers, especially those building trading bots or DEX applications:

• Validator transaction reordering: Because Solana validators can reorder transactions in the blocks they generate, potential validators may reorder transactions for their own benefit. For example, if your DEX transaction creates an Arbitrage opportunity, validators may insert their own transactions before yours to capture profits. This may result in deterioration of your transaction output, or even lead to its failure (if the opportunity disappears). The order of transaction execution can greatly affect the outcome of DeFi, and without protection, your transactions will be dominated by the incentives of block producers.
• Spam and network congestion: A large number of Solana transactions are driven by MEV (Arbitrage spam, etc.). During contention periods (such as popular NFT minting or volatile markets), your legitimate transactions are competing with a large number of bot trades. This may result in increased delays or failure rates if not taken into consideration. If your transaction is intercepted by overloaded validators, or if you run into spam storms when submitting transactions through unstaked nodes, your transaction may be dropped. To cut through this noise, you may need to attach a priority fee. Essentially, MEV activities could clog the highway for your transaction passage, so if left unprotected, you need to plan for this (higher fees, retries, etc.).
• Slippage increases and user experience issues: For DEX developers, MEV may directly harm your users. Users may set a 1% slippage tolerance in their trades, but due to MEV (such as sandwich attacks), they may end up receiving prices reduced by the full 1%. In extreme cases, MEV bots can manipulate prices, causing users’ trades to fail (exceeding the slippage), while the bots have already profited. This could result in a poor user experience - failed trades or unexpectedly unfavorable rates. Users may attribute these outcomes to the DEX or blockchain. Therefore, failing to protect against MEV impact could undermine user confidence in the platform. For your trading bots, when adversaries can insert trades that affect your trades, the results become less predictable, making it more difficult to reliably execute strategies.

In short, MEV in Solana may lead to higher costs, lower profits, and network friction. Developers should be aware of these threats and consider taking measures to mitigate these risks, especially in applications where any transaction sequencing affects financial outcomes.

Protecting Trades from MEV Impact

There are many tools that can prevent or limit the negative impact of MEV on your trades and users. Each use case is unique, so not every tool is applicable to your case.

• Protect Your Trades: Utilize QuickNode Add-Ons. The QuickNode Marketplace offers a variety of tools to enhance trade settlement and minimize exposure to MEV. LilJIT - Jito Bundles & Transactions Add-On allows you to bundle transactions for fast settlement sequencing, including MEV and rollback protection. Additionally, the marketplace also offers the ability to add MEV protection to existing endpoints’ sendTransaction calls by leveraging Solana MEV Protection & Recovery Add-On. This add-on not only provides protection against front-running trades but also supports MEV recovery (returning captured non-malicious MEV to you), enhances privacy, and ensures swift execution.
• Protection against unwanted state changes: Take advantage of transaction protection. Lighthouse is a runtime assertion Solana program that will fail transactions when it detects that the on-chain state deviates from the desired state. You can add a lighthouse instruction to your transaction to ensure that at the end of the trade execution, the state of the specified account meets the predefined desired state (e.g., rejecting the entire transaction if the specified token balance is less than X after this transaction). This allows for more complex account checks than simple slippage, and allows for assertions on sysvars (slots), which can be used for blacklist validators – this can be achieved by utilizing getLeaderSchedule and a list of malicious validators.
• Set Limits: Set slippage and take advantage of limit orders. When making an exchange, always set the slippage to a level that suits your trading and risk tolerance. Suppose a malicious actor is trying to take advantage of any opportunity that your slippage rate allows. When your use case allows, use a limit order to set the minimum price at which the token can be sold. Check out QuickNode’s Metis API, which supports limit orders.
• Preventing Transaction Failures: Optimize your transactions. Due to MEV driving a large volume of transaction spam to the network, your transactions must be properly constructed to ensure inclusion in specific blocks. In short, you must request the appropriate amount of computational units, provide competitive priority fees, and correctly compose your transactions (see strategies for optimizing Solana transactions or tips for increasing transaction success rates on Jupiter on Solana for more details). QuickNode’s Priority Fee API and Send Smart Transaction methods can help simplify this process.
• Pay attention to staking. Understand your validators. Different validators and validator clients have different approaches to handling MEV. Although this does not directly affect your transactions, your staking (and that of others) can affect the overall health of the validator network and governance around MEV. Here are some resources: Jito validator client, Marinade: decentralized MEV, Paladin validator client.
• Participate. Solana Improvement Documentation (SIMD). The Solana Foundation operates an open-source GitHub repository, Solana Improvement Documentation, where community members can contribute ideas and comment on existing content. Discussions around MEV, network fees/rewards, etc. are ongoing. If you have any opinions, please join in!
• Consider RFQs and fast relay systems. For advanced applications, consider a Request for Quote (RFQ) system (e.g., JupiterZ), as well as Express Relay, which provides MEV protection through private order flow channels and independent priority auctions. These systems connect the protocol directly to the searcher, eliminating validators from MEV extraction, making pricing more efficient. Key benefits include private transaction routing, direct competition between searchers, and reduced integration costs.

Summary

MEV is an important factor to consider when building on any blockchain, and Solana is no exception. We understand that Solana’s design changes the game, but MEV still appears through Arbitrage, liquidation, and sandwich attacks. As a developer of Solana DeFi tools, ignoring MEV may result in suboptimal trading outcomes for your app’s users, or your bots losing profits. The good news is, there are many tools to help you mitigate these issues, regain control of transaction ordering, and even capture MEV for yourself or your users.