What is MEV and How to Secure Your Solana Transactions

Overview

Understanding MEV (Maximum Extractable Value) is critical for developers building DeFi applications and trading bots on Solana. MEV can impact trade execution for your users, or threaten the profitability of your own bot. Higher costs, lower profits, and network friction are common consequences of unprotected MEV risk. This guide covers the basics of MEV on Solana, including transaction flow mechanics, common MEV types, and the increasing risks for developers building on the network. You’ll 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)

• Some familiarity with DeFi or TradFi ( What is DeFi?)

Introduction to MEV on Solana

Maximum Extractable Value (MEV) refers to the maximum value that can be extracted from a user’s transactions by reordering, including, or excluding their transactions. In a proof-of-stake network like Solana, validators, who are block producers, have the power to decide which transactions go into that 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 users, or exploit the order of transactions in a variety of ways. While Solana does not have a public mempool like Ethereum, MEV still exists - typically through direct node connections, private mempools, or other specialized infrastructure.

For developers building trading bots or decentralized exchanges (DEXs), not accounting for MEV can result in:

• Worse trade execution (e.g., sandwich attacks).

• Loss of profit (bots execute before you trade).

• Network congestion issues (affecting the ability of your transactions to be successfully submitted on the network).

In 2024, DeFi activity on Solana flourished, and at the same time, MEV also grew. Messari shows the growth of Solana’s real economic value (fees + MEV) over time:

Source: Messari: State of Solana - Q4 2024

While most MEVs are relatively small, there are countless examples of tens of thousands of dollars being extracted from transactions (see screenshot below) and even million-dollar transactions .

Source: Jito - Arbitrage Explorer

For developers building DeFi applications and trading bots on Solana, understanding MEV is critical. MEV can affect your users’ trade execution (causing unexpected slippage or trade failures) or even the profitability of your own bots if competitors are able to intercept or reorder your trades. Let’s review some basics about the Solana transaction flow, review common types of MEV on Solana, and discuss measures you can take to protect your transactions from MEV.

Solana Transaction Flow

Solana’s transaction flow has some key differences from Ethereum, which affect MEV’s performance:

• No Global Memory Pool: Unlike Ethereum, Solana does not have a unified public memory pool for pending transactions to be included. Instead, Solana uses the Gulf Stream protocol to directly forward transactions to the next expected block leader (validator) before they produce a block. This means there is no long-lived pool of visible pending transactions for bots to monitor the network. Each Solana transaction includes a recent blockhash that expires after about 150 slots (about 1 minute) if unconfirmed. In short, transactions are either quickly picked up by leaders or discarded - there is no persistence in the memory pool. This _reduces_ the window for MEV strategies like watching and preempting public pending transactions, though determined seekers can reduce this by running their own nodes to see incoming transactions.

• Stake-Weighted Quality of Service (QoS): Solana prioritizes incoming transaction traffic based on stake. Validators allocate the majority of incoming capacity to clients/relays in proportion to their stake. In practical terms, this means that transactions 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: packets from spammers with no stake are downgraded in priority, while transactions through well-staked validators receive faster processing.

• Priority Fees (Local Fee Market): Solana utilizes priority fees as optional additional fees that users can attach to improve their chances of fast inclusion when the network is busy. Normally, Solana transactions have very low fixed fees, but in situations where heavy load (like NFT minting or a memecoin trading boom) causes congestion, users can specify a priority fee per computational unit, essentially bidding for block space. Validators receive 50% of these priority fees, and the oligopoly oppervlakte rule burns the other 50%, so 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 fee market per 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 bidding for priority during periods of congestion. For developers, this means that in a congested block, your transaction will likely need a priority fee to get ahead of 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 prevalent forms of MEV on Solana. Arbitrage typically involves buying and selling the same asset atomically across multiple exchanges. Arbitrageurs buy on the cheaper market and sell on the more expensive market, pocketing the difference, for example:

<span ) 10px 10px / 40px no-repeat ;height: 30px;width: 100%;margin-bottom: -7px;border-radius: 5px;'>

Since Solana allows for multiple instructions to be combined into one transaction, seekers typically perform atomic arbitrage (two stages in one transaction) to ensure that the trade is effectively risk-free. Failed trades will cause the buyer to lose their preferred fee, so they need to balance opportunity size and preferred fee markets.

Solana arbitrage competition is fierce - bots will spam many transactions trying to arbitrage. Solana's low fees mean that bots can issue a large number of arbitrage trades; even if most fail or are unprofitable, the occasional success can be profitable. In fact, over 50% of Solana transactions are actually failed arbitrage attempts (spam) - bots blindly trying to capture price discrepancies ( ...

Sandwich Attack

Sandwich Attack is a classic negative MEV strategy that has also been seen on Solana. In a sandwich attack, a victim user’s transaction is sandwiched between an attacker’s transactions: one that executes before the victim’s transaction, and one that executes after it. Let’s say a user submits a large swap on a DEX; a MEV seeker that knows about this pending swap can quickly submit its own transaction to buy the same asset before the user’s transaction (driving up the price), then have the user’s large purchase execute at the now higher price, and then immediately sell the asset, pocketing the difference. The attacker profits by buying at a low price and selling at a higher price, while the victim gets 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 may try to sandwich it. High slippage tolerances set by users make them particularly vulnerable - if users allow up to 5% slippage, a pinch bot can exploit much of the range to profit. Reducing slippage and pinch risk involves slippage, privacy, and ordering controls.

Liquidation

Liquidation is another important MEV opportunity, especially in Solana's DeFi lending protocols (e.g., Marginfi, Kamino, Save, etc.). When the value of a borrower's collateral falls below the required ratio (i.e., their loan is undercollateralized), the position is liquidated. A liquidator (usually a bot) can repay part or all of the loan on behalf of the borrower and receive some discounted collateral. This essentially results in a profit for the liquidator, as they buy the collateral at a discount to the market price.

MEV hunting bots constantly scan the on-chain state and oracle price data, detecting positions that are about to go bankrupt. When they find one, they race to send liquidation transactions first to grab the bonus. In Solana, since there is no public memory pool, liquidation bots ensure that on-chain changes (such as oracle price drops or health factor crosses a threshold) are noticed as soon as possible, and then liquidation transactions are immediately sent to the current leader. If multiple bots try to liquidate the same account, only the first transaction that successfully enters the block will receive the reward, and the transactions of others will fail. Liquidation is seen as a basic guarantee for the health of the protocol (it 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 MEV. Validators running the Jito-Solana client participate in an off-chain block building market. Seekers send bundles of transactions (and associated tip payments) directly to these block builders, rather than to the normal Solana gossip network. Block producers then include the highest paying tip bundle in a block, earning a tip from it. This system allows MEV seekers to perform strategies like arbitrage, liquidations, and pinch-hitting privately (their transactions are not public until included) and receive priority processing as long as they pay competitive tips. As a result, this generates significant revenue for Solana validators. Currently, Solana’s malicious MEV primarily comes from privately operated mempools.

MEV Risks for Solana Developers

MEV presents multiple risks and challenges for Solana developers, especially those building trading bots or DEX applications:

• Transaction Reordering by Validators: Since Solana validators can order transactions in the blocks they produce, potential validators can reorder transactions for their own benefit. For example, if your DEX trade generates an arbitrage opportunity, a validator may insert their own transaction before yours to capture the profit. This can cause your trade output to deteriorate, or even cause it to fail (if the opportunity disappears). The order in which transactions are executed can greatly affect DeFi outcomes, and without protection, your transactions are at the mercy of the incentives of the block producers.

• Spam and Network Congestion: A large amount of Solana trading is driven by MEV (arbitrage spam, etc.). During periods of contention (like hot NFT minting or volatile markets), your legitimate trades are competing with a large number of bots. This can lead to increased latency or higher failure rates if you don’t account for this. Your trades may be dropped if they are blocked by a validator under heavy load, or if you are hit by a spam storm when submitting trades through an unstaked node. In order to cut through this noise, you may need to attach priority fees. Essentially, MEV activity may crowd the highway your trades are traveling on, so you need to plan for this if there are no protections (higher fees, retries, etc.).

• Increased Slippage and UX Issues: For DEX developers, MEV can directly hurt your users. A user might set a 1% slippage tolerance on a trade, but the price they end up receiving could be reduced to the full 1% due to MEV (e.g., pinching). In extreme cases, a MEV bot can drive prices such that a user’s trade fails (beyond slippage) while the bot has already taken 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. Failure to protect against MEV can therefore undermine user confidence in the platform. For your trading bot, outcomes become less predictable when an adversary is able to insert trades that affect your trades, making it more difficult to reliably execute your strategy.

In summary, MEV in Solana can result in higher costs, lower profits, and network friction. Developers should be aware of these threats and consider taking steps to mitigate them, especially in any application where the ordering of trades affects financial outcomes.

Protect Transactions from MEV

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

• Protect Your Transactions: Leverage QuickNode Add-ons. The QuickNode Marketplace offers a variety of tools to increase transaction landing rates and minimize exposure to MEV. Lil' JIT - Jito Bundles & Transactions The add-on allows you to bundle transactions for quick landing sequential execution, including MEV and rollback protection. Additionally, the Marketplace offers the ability to add MEV protection to existing endpoints’ sendTransaction calls by leveraging the Solana MEV Protection & Recovery add-on. This add-on not only provides protection from front-running, but also enables MEV recovery (returning captured non-malicious MEV to you), improves privacy, and ensures fast execution.

• Protection from Unwanted State Changes: Leverage Transaction Protection. Lighthouseis a runtime assertion Solana program that will fail transactions when it finds that the state on the chain has deviated from the desired state. You can add the lighthouse directive to your transactions to ensure that at the end of the transaction execution, the state of the specified account meets a predefined desired state (e.g. if the balance of the specified token is less than X after this transaction, then reject the entire transaction). This allows for more complex account checks than simple slippage, and allows assertions on Sysvars (slots), which can be used to blacklist validators - this can be achieved by leveraging getLeaderSchedule and a list of malicious validators .

• Set Limits: Set slippage and utilize limit orders. When making an exchange, always set slippage to a level that is appropriate for your trade and risk tolerance. Assume that malicious actors are trying to take advantage of any opportunities your slippage rate allows. When your use case allows, use limit orders to set a minimum price for selling tokens. Check out QuickNode's Metis API, which supports limit orders.

• Preventing Transaction Failures: Optimizing Your Transactions. Because MEV drives a large amount of transaction spam traffic to the network, your transactions must be constructed correctly to ensure they can be included in a specific block. In short, you must request the right amount of compute units, offer a competitive priority fee, and compose your transaction correctly (check out Strategies for Optimizing Solana Transactions or Tips for Improving Jupiter Transaction Success on Solana for more details). QuickNode’s Priority Fee API and Send Smart Transaction method can help simplify this process.

• Focus on staking. Know your validators. Different validators and validator clients have different approaches to handling MEV. While this won’t directly impact your transactions, your stake (and that of others) can impact the health of the overall validator network and governance around MEV. Here are some resources: Jito Validator Client, Marinade: Decentralizing MEV, Paladin Validator Client.

• Get involved. Solana Improvement Document (SIMD). The Solana Foundation operates an open source GitHub repository, Solana Improvement Documents, where community members can propose ideas and comment on existing content. Discussions around MEV, network fees/rewards, and more are ongoing. If you have an opinion, please get involved!

• Consider RFQ and fast relay systems. For advanced applications, consider request-for-quote (RFQ) systems (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 seekers, eliminating validators from MEV extraction and making pricing more efficient. Key benefits include private trade routing, direct competition between seekers, and reduced integration costs.

Conclusion

MEV is an important factor to consider when building on any blockchain, and Solana is no exception. We learned that Solana’s design is a game changer, but MEV still occurs through arbitrage, liquidations, and pinch-hitting. As a developer of Solana DeFi tools, ignoring MEV could result in your app’s users getting suboptimal trading results, or your bot losing profitability. The good news is that many tools can help you mitigate these issues, allowing you to regain control of transaction ordering and even obtain MEV for yourself or your users.

Additional Resources

• Solana MEV: Getting Started

• Lil' JIT - Jito Bundles & Transactions Marketplace Add-ons

• Merkle.io MEV Protection Market Add-ons

• Open Source Malicious Validator Tracker

• Lighthouse Runtime Assertions for Solana Programs

• Strategies for Optimizing Solana Transactions

• Tips for Improving Jupiter Transaction Success on Solana

• Jito Validator Client

• Marinade: Decentralized MEV

• Paladin Validator Client