Overview

Understanding MEV (maximum value extraction) is crucial for developers who build DeFi applications and trading robots on Solana. MEVs may affect the execution of users' transactions or threaten the profitability of your own robot. Higher costs, lower profits, and network friction are common consequences of unprotected MEV risks. This guide covers the basics of MEVs on Solana, including transaction process mechanisms, common MEV types, and the increasing risks posed by developers built on the web. You will learn key strategies to mitigate the negative effects of MEV and protect your transactions from disruption.

Recommended prerequisite knowledge

A basic understanding of blockchain concepts and Solana (Solana Basics Reference Guide)

A certain understanding of DeFi or TradFi (What is DeFi?)

Introduction to MEV on Solana

Maximum extractable value (MEV) refers to the maximum value extracted from user transactions by reordering, including, or excluding user transactions. In a proof-of-stake network like Solana, verifiers as block producers have the ability to decide which transactions enter the block and the order. This means that malicious or profit-seeking block producers can reorder transactions (or insert their own transactions) to capture arbitrage profits, preemptive user transactions, or exploit the order of transactions in various ways. Although Solana does not have a public memory pool like Ethereum, MEVs still exist—usually through direct node connections, private memory pools, or other specialized infrastructure.

For developers who build trading bots or decentralized exchanges (DEXs), not considering MEVs can lead to:

worse transaction execution (e.g., sandwich attack).

Loss of profit (the robot rushes to execute before you trade).

Network congestion problem (affects your ability to successfully submit transactions on the network).

DeFi activity on Solana flourished in 2024, while MEVs are growing. Messari shows how Solana’s real economic value (fees + MEV) grows over time:

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

While most MEVs are relatively small, there are countless examples showing tens of thousands of dollars withdrawn from transactions (see screenshot below), and even millions of dollars transactions.

Source: Jito - Arbitrage Explorer

Understanding MEV is crucial for developers who build DeFi applications and trading robots on Solana. MEVs may affect the execution of users' transactions (causing unexpected slippages or transaction failures) and even affect the profitability of your own robots if competitors are able to intercept or reorder your transactions. Let’s review some basics about the Solana trading process, review the types of MEVs common on Solana, and discuss the measures you can take to protect your transactions from MEVs.

Solana Trading Process

Solana's trading process has some key differences from Ethereum, which affects the performance of MEVs:

No global memory pool: Unlike Ethereum, Solana does not have a unified public memory pool to wait for included pending transactions. Instead, Solana uses the Gulf Stream protocol to forward transactions directly to the next expected block leader (verifier) ​​before they generate the block. This means there is no long-standing visible pending transaction pool for robots to monitor the network. Each Solana transaction contains a recent blockhash which expires after about 150 slots (about 1 minute) if not confirmed. In short, transactions are either quickly picked up by the leader or discarded—the memory pool has no persistence. This reduces the windows of MEV strategies such as observing and preempting public pending transactions, despite the determined searchers who run themselvesnodes to reduce this to see incoming transactions.

Shared weighted quality of service (QoS): Solana prioritizes incoming transaction traffic based on shares. The validator allocates most of the incoming capacity to clients/relays with an equal share ratio. In practice, this means that transactions from or through high staking nodes are unlikely to be discarded during congestion. Share-weighted quality of service as a Sybil resistance mechanism: packets of spammers without shares are downgraded to prioritize, while transactions with staking good validators are faster to process.

Priority Fees (local expense market): Solana uses priority fees as an optional additional fee that users can attach to to to improve their chances of rapid inclusion when the network is busy. Typically, Solana transactions have very low fixed fees, but in heavy load situations such as NFT minting or meme currency trading booms, users can specify priority fees per calculation unit, basically in the bidding block space. Verifiers get 50% of these priority fees, and the oligopolis oppervlakte rule burns the remaining 50%, so the higher priority fees make it more likely that the validator includes your transaction. Priority fees are designed to deal with spam and allow time-sensitive transactions to "jump" ahead of the "queue". On the Solana network, this creates a local fee market for each block per computing unit. As of 2024, priority fees accounted for a large portion of Solana’s total fee revenue, highlighting that users are indeed conducting priority bids during congestion. For developers, this means that in a crowded block, your transaction will most likely require priority fees to surpass spammers or compete for transactions.

Common MEV types on Solana

The following are the most common MEV types that Solana developers should pay attention to:

Arbitrage

Arbitrage is one of the most common MEV forms on Solana. Arbitrage usually involves buying and selling the same asset in an atomic manner across multiple transactions. Arbitrageurs buy in cheaper markets and sell in more expensive markets, grabbing the difference in their pockets, for example:

Solana allows multiple instructions to be combined into one transaction, searchers usually perform atomic arbitrage (two stages in one transaction) to ensure that the transaction is actually zero risk. Failed transactions will cause the buyer to lose their priority fees, so they need to balance the opportunity size and the priority fees market.

Solana's arbitrage competition is very fierce - robots spam numerous transaction attempts to arbitrage. Solana's low fees mean that the robot can send out a large number of arbitrage transactions; even if most of them fail or have no profit, occasionally success may be profitable. In fact, more than 50% of Solana transactions are actually failed arbitrage attempts (spam) - robots blindly try to capture price differences (reference: Solana MEV - Introduction). While this may be a problem with network congestion, it usually means that prices are in various The Sandwich Attack is a classic negative MEV strategy that also appears on Solana. In a sandwich attack, the transactions of the victim user are sandwiched between the attacker’s transactions: one is executed before the victim’s transaction and the other is executed after it. Suppose the user submits a large exchange on DEX; a MEV hunter who understands this pending exchange can quickly submit his own transaction to buy the same asset (push up the price) before the user’s transaction, then let the user’s large purchases execute at the higher price now, and finally sell the asset immediately, obtaining the spread. The attacker makes a profit by buying at a low price and selling at a higher price, while the victim gets worse in his exchange (higher slippage).

As a developer or trader, you should realize that if a third party can observe it before your exchange is finalized, they may try to pinch it. The high slip tolerance set by users makes them particularly vulnerable—if the user allows up to 5% slip, the pinch robot can take advantage of most of the range to profit. Reducing slip and pinch risks involves slip, privacy, and sorting controls.

Cleaning

Cleaning is another important MEV opportunity, especially in Solana's DeFi In a lending agreement (e.g., Marginfi, Kamino, Save, etc.). When the borrower's collateral value is lower than the required ratio (i.e., their loan is owed to collateral), the position is liquidated. A liquidator (usually a robot) can repay part or all of the loan on behalf of the borrower and obtain some discounted collateral. This essentially brings profits to the liquidator because they are below the marketBuy collateral at the price.

MEV The search robot continuously scans the on-chain status and oracle price data to detect positions that are about to go bankrupt. When they find one, they scramble to send clearing transactions to grab the bonus. In Solana, since there is no public memory pool, the clearing bot ensures on-chain changes (such as falling oracle prices or health factors crossing thresholds) as soon as possible, and then immediately sends the clearing transaction to the current leader. If multiple bots try to clear the same account, only the first transaction that successfully enters the block can be rewarded, and the transaction of others will fail. Liquidation is regarded as a basic guarantee of the health of the agreement (which can prevent bad debts).

Jito Bundles and other MEV applications

Solana's MEV ecosystem is developing, and Jito Bundles plays an important role in the extraction (and potential mitigation) of MEVs. Verifiers running Jito-Solana client participate in the offline block construction market. Searchers send transaction bundles (and associated tip payments) directly to these block builders, rather than the normal Solana gossip network. The block producer then includes the highest paid tip bundle in the block, from which the tip is received. This system allows MEV seekers to privately execute strategies such as arbitrage, liquidation, and pinch (their transactions were not public until they were included), and can be prioritized as long as they pay a competitive tip. As a result, this generates significant revenue for Solana validators. Currently, Solana's malicious MEVs mainly come from memory pools for private operations.

MEV Risks to Solana developers

MEV presents various risks and challenges for Solana developers, especially those who build trading bots or DEX applications:

Verified transaction reordering: Because Solana validators can sort transactions in the blocks they generate, potential validators can reorder transactions for their own benefit. For example, if your DEX transaction creates an arbitrage opportunity, validators may insert their own transaction before you to capture profits. This can cause your trading output to become worse, or even cause it to fail (if the opportunity disappears). The order in which transactions are executed can greatly affect the results of DeFi, and without protection, your transactions will be dominated by block generator incentives.

Spam and Internet congestion: a large number of Solana transactionsAll are powered by MEV (arbitrage spam, etc.). During a period of scrambling (such as popular NFT coins or volatile markets), your legal trade is competing with a large number of robot trades. This can lead to an increase in latency or an increase in failure rate, if you don't consider this. If your transaction is intercepted at a high load validator, or you hit a spam storm when submitting a transaction through an unstaked node, your transaction may be discarded. To penetrate this noise, you may need to add a priority fee. Essentially, MEV activities can fill up the highways you trade for, so if there is no protection, you need to plan for it (higher fees, retry, etc.).

Additional slippage and user experience issues: For DEX developers, MEVs may directly harm your users. Users may set a slippage tolerance of 1% in the transaction, but the price they end up with may be reduced to 1% in full due to MEVs (such as pinch). In extreme cases, MEV robots can drive prices, causing users to fail (over slippage), and the robot has already made profits first. This can lead to a bad user experience – transaction failures or unexpectedly bad interest rates. Users may blame these results on DEX or blockchain. Therefore, failure to protect against MEVs may undermine user confidence in this platform. For your trading bot, when the opponent is able to insert a trade that affects your trading, the results become less predictable, which makes it more difficult to implement a strategy reliably.

In short, MEV in Solana can lead to higher costs, lower profits, and network friction. Developers should be aware of these threats and consider taking steps to mitigate these risks, especially in applications where transaction sorting affects financial results.

Protect transactions from MEV

There are many tools that can prevent or limit the negative impact of MEV on your transactions and users. Every use case is unique, so not every tool is suitable for your case.

Protect your transactions: leverage the QuickNode add-on. The QuickNode market offers a variety of tools to increase transaction landing and minimize exposure to MEVs. Lil' JIT - Jito Bundles & Transactions add-on allows you to bundle transactions for fast landing order execution, including MEV and rollback protection. Additionally, the market offers sendTransaction< that adds MEV protection to existing endpointsThe ability of /code> calls is by leveraging the Solana MEV Protection & Recovery add-on. This add-on not only provides protection from evading preemptive transactions, it also supports MEV recovery (returning captured non-malicious MEVs to you), improves privacy, and ensures quick execution.

Protect unnecessary state changes: use transaction protection. Lighthouse is a runtime assertion Solana program that fails when the state on the chain is found to deviate from the expected state. You can add the lighthouse directive to your transaction to ensure that the status of the specified account meets the predefined expected state at the end of the transaction (for example, if the specified token balance is less than X after this transaction, the entire transaction will be rejected). This allows for more complex account checks than simple slippages and allows assertions on Sysvar (slots), which can be used for blacklist validators—this can be achieved by leveraging getLeaderSchedule and a list of malicious validators.

Set limits: Set slippage and use limit orders. Always set the slippage to the level that suits your trading and risk tolerance when doing an exchange. Suppose a malicious actor is trying to take advantage of any chance your slippage rate allows. When your use case allows, use a limit order to set the minimum price of the tokens for sale. Check out QuickNode's Metis API, which supports limit orders.

Prevent transaction failure: Optimize your transaction. Since MEV drives large volumes of transaction spam traffic to the network, your transactions must be properly constructed to ensure they can be incorporated into specific blocks. In short, you must request the appropriate number of calculation units, provide competitive priority fees, and correctly combine your transactions (see strategies for optimizing Solana transactions or tips for improving the success rate of Jupiter transactions on Solana for more details). QuickNode's Priority Fee API and Send Smart Transaction methods can help simplify this process.

Follow pledge. Get to know your validators. Different validators and validator clients have different ways of handling MEVs. While this won’t directly affect your transactions, your stake (and others’ stakes) can affect the health status of the overall validator network and governance around MEVs. Here are some resources: Jito Verifier client, Marinade: decentralized MEV, Paladin Verifier client.

Participate. Solana Improved Documentation (SIMD). The Solana Foundation operates an open source GitHub repository, where Solana improves documentation, community members can come up with ideas and comment on existing content. Discussions around MEV, network fees/rewards, etc. are ongoing. If you have any comments, please participate!

Consider RFQ and fast relay systems. For advanced applications, consider Request Quotation (RFQ) systems (e.g., JupiterZ), and Express Relay, providing MEV protection through private order flow channels and independent priority auctions. These systems connect the protocol directly to the searcher, eliminating the validator from the MEV extraction, making pricing more efficient. Its key benefits include private transaction routing, direct competition among searchers and reduced integration costs.

Summary

MEV is an important factor to consider when building on any blockchain, and Solana is no exception. We learn that Solana’s design is a game-changer, but MEV still emerges through arbitrage, liquidation and pinch. As a developer of Solana DeFi tools, ignoring MEV can cause users of your application to get unsatisfactory transaction results, or your bot loses profitability. The good news is that many tools can help you alleviate these problems, allowing you to regain control of transaction sorting, and even obtain MEVs for yourself or users.

Extra Resources

Solana MEV: Getting Started

Lil' JIT - Jito Bundles & Transactions Market Add-ons

Merkle.io MEV Protection Market Add-ons

Open Source Malicious Verifier Tracker

Lighthouse Runtime Assertions Solana Program

Optimization Solana trading strategy

Tips to improve the success rate of Jupiter transactions on Solana

Jito Verifier Client

Marinade: Decentralized MEV

Paladin Verifier Client