What is MEV and How to Secure Your Solana Transactions

Overview

For developers building DeFi applications and trading bots on Solana, understanding Maximal Extractable Value (MEV) is crucial. MEV can impact the execution of user transactions or threaten the profitability of your own bots. 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 flow mechanics, common MEV types, and the growing risks they pose to developers building on the network. You will learn key strategies to mitigate the negative impacts of MEV and protect your transactions from disruption.

Recommended Prerequisites

• Basic understanding of blockchain concepts and Solana (refer to Solana Basics Guide)

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

Introduction to MEV on Solana

Maximal Extractable Value (MEV) refers to the maximum value that can be extracted from user transactions by reordering, including, or excluding them. In a Proof-of-Stake network like Solana, the validators acting as block producers have the ability to decide which transactions enter the block and in what order. This means that malicious or profit-seeking block producers can reorder transactions (or insert their own transactions) to capture arbitrage profits, front-run user transactions, or exploit the order of transactions in various ways. While Solana does not have 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 (DEXes), failing to consider MEV can lead to:

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

• Profit loss (bots front-running your trades).

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

In 2024, DeFi activity on Solana is thriving, and MEV is growing alongside it. Messari has shown the real economic value (fees + MEV) of Solana increasing over time:

Source: Messari: State of Solana - Q4 2024

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

Source: Jito - Arbitrage Explorer

For developers building DeFi applications and trading Bots on Solana, understanding MEV is crucial. MEV can impact the execution of user transactions (leading to unexpected slippage or failed trades) and even affect the profitability of your own Bots if competitors can intercept or reorder your transactions. Let's review some basics about Solana's transaction flow, examine common MEV types on Solana, and discuss measures you can take to protect your transactions from MEV.

Solana Transaction Flow

Solana's transaction flow differs from Ethereum in some key ways that impact how MEV manifests:

• No Global Mempool: Unlike Ethereum, Solana does not have a unified public mempool for pending transactions to wait in. Instead, Solana uses the Gulf Stream protocol to directly forward transactions to the next expected block leader (validator) before they generate the block. This means there is no long-lived, visible pending transaction pool for Bots to monitor the network. Each Solana transaction contains a recent blockhash that expires if not confirmed, roughly 150 slots later (about 1 minute). In short, transactions are either quickly picked up by the leader or discarded - the mempool has no persistence. This _reduces_ the window for MEV strategies like observing and front-running public pending transactions, although determined searchers can reduce this by running their own nodes to see incoming transactions.

• Stake-Weighted Quality of Service (QoS): Solana prioritizes incoming transaction flow based on stake. Validators allocate the majority of their inbound capacity to clients/relays proportional to their stake. In practice, this means transactions from or through high-staked nodes are less likely to be dropped during congestion. Stake-weighted QoS serves as a Sybil resistance mechanism: spam senders with no stake have their packets downgraded, while transactions through well-staked validators get faster processing.

• Priority Fees (Local Fee Market): Solana utilizes priority fees as an optional add-on fee users can attach to increase their chances of rapid inclusion during network congestion. Typically, Solana transactions have very low fixed fees, but in high-load situations (like NFT minting or meme coin trading frenzies) that cause congestion, users can specify a priority fee per compute unit, essentially bidding for block space. Validators receive 50% of these priority fees, with the remaining 50% burned under the oligarch oppervlakte rule, so higher priority fees make validators more likely to include your transaction. Priority fees are intended to address spam and allow time-sensitive transactions to "jump the queue." On the Solana network, this creates a local fee market per compute unit per block. As of 2024, priority fees make up a significant portion of Solana's total fee revenue, highlighting that users are indeed bidding for priority during congestion. For developers, this means that in a crowded block, your transaction will likely need priority fees to outpace spammers or competing transactions.

Common MEV Types on Solana

Here are some of the most common MEV types 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 across multiple exchanges in an atomic fashion. Arbitrageurs buy on the cheaper market and sell on the more expensive one, pocketing the difference, for example:

Since Solana allows combining multiple instructions into a single transaction, searchers often execute atomic arbitrage (two-legged in one transaction) to ensure the trade is truly risk-free. Failed transactions will result in the buyer losing their priority fee, so they need to balance opportunity size and the priority fee market.

Solana's arbitrage competition is fierce - Bots will spam many transactions attempting to arbitrage. Solana's low fees mean Bots can issue a large number of arbitrage trades; even if most fail or are unprofitable, the occasional success can still yield profits. In fact, over 50% of Solana transactions are actually failed arbitrage attempts (spam) - Bots blindly trying to capture price differentials (refer to Solana MEV - An Introduction). While this may be a network congestion issue, it typically means prices are able to stay balanced across the various DeFi platforms.

Sandwich Attack

Sandwich Attack is a classic negative MEV strategy that has also appeared on Solana. In a sandwich attack, the victim user's transaction is sandwiched between the attacker's transactions: one executed before the victim's transaction, and the other after it. Assuming the user submits a large-scale swap on a DEX; an MEV searcher aware of this pending swap can quickly submit their own buy transaction for the same asset (driving up the price) before the user's transaction, then let the user's large purchase execute at the now higher price, and finally immediately sell the asset, profiting from the spread. The attacker profits by buying low and selling high, while the victim gets a worse price (higher slippage) on their swap.

As a developer or trader, you should be aware that if a third party can observe your swap before it is finalized, they may attempt to sandwich it. Users' high slippage tolerance settings make them particularly vulnerable - if users allow up to 5% slippage, sandwich bots can exploit most of that range to profit. Reducing slippage and sandwich risk involves slippage, privacy, and ordering controls.

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 undercollateralized), the position becomes eligible for liquidation. Liquidators (often bots) can repay part or all of the loan on behalf of the borrower and receive some of the discounted collateral. This essentially profits the liquidator, as they buy the collateral at a price below the market rate.

MEV-searching bots constantly scan the on-chain state and oracle price data, detecting positions that are about to become insolvent. When they find one, they race to send the liquidation transaction to claim the reward. In Solana, due to the lack of a public mempool, liquidation bots ensure they quickly notice on-chain changes (such as oracle price drops or health factors crossing thresholds), then immediately send their liquidation transactions to the current leader. If multiple bots attempt to liquidate the same account, only the first transaction to successfully enter the block will receive the reward, with the others failing. Liquidations are seen as a fundamental safeguard for the protocol's health (to prevent bad debt).

Jito Bundles and Other MEV Applications

Solana's MEV ecosystem is evolving, with Jito Bundles playing a key role in the extraction (and potential mitigation) of MEV. Validators running the Jito-Solana client participate in an off-chain block building marketplace. Searchers directly send transaction bundles (and associated tip payments) to these block builders, rather than the normal Solana gossip network. The block producers then include the highest-tipped bundles in the blocks, earning the tips. This system allows MEV searchers to privately execute arbitrage, liquidation, and sandwich strategies (their transactions are not public before inclusion), as long as they pay competitive tips to get priority processing. As a result, this brings significant revenue to Solana validators. Currently, Solana's malicious MEV primarily comes from these private mempool operations.

MEV Risks for Solana Developers

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

• Validator Transaction Reordering: Since Solana validators can reorder transactions within the blocks they produce, potential malicious validators may reorder transactions to benefit themselves. For example, if your DEX trade generates an arbitrage opportunity, a validator may insert their own transaction before yours to capture the profit. This could result in worse execution for your trade, or even cause it to fail (if the opportunity disappears). The order of transaction execution can significantly impact DeFi outcomes, and without protection, your transactions will be at the mercy of the block producers' incentives.

• Spam and Network Congestion: A large portion of Solana transactions are MEV-driven (e.g., arbitrage spam). During high-demand periods (such as popular NFT mints or volatile markets), your legitimate transactions are competing with a swarm of bot transactions. This can lead to increased latency or higher failure rates if you don't account for it. If your transactions get intercepted by overloaded validators, or you submit through unstaked nodes and hit the spam storm, your transactions may get dropped. To pierce this noise, you may need to attach priority fees. Essentially, MEV activity can clog the high-speed highway your transactions need to traverse, so you'll need to plan for this (higher fees, retries, etc.) if you lack protection.

• Increased Slippage and User Experience Issues: For DEX developers, MEV can directly harm your users. Users may set a 1% slippage tolerance on their trades, but due to MEV (like sandwiching), they may end up getting a much worse price (down to the full 1%). In extreme cases, MEV bots can drive the price such that the user's trade fails (exceeds slippage), while the bots have already profited. This can lead to a poor user experience - failed trades or unexpectedly adverse rates. Users may blame the DEX or blockchain for these outcomes. For your trading bots, when adversaries can insert transactions that impact your trades, the results become less predictable, making it harder to reliably execute your strategies.

In summary, MEV in Solana can 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 any applications where transaction ordering impacts financial outcomes.

Protecting Transactions from MEV

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

• Protect Your Transactions: Utilize QuickNode Add-ons. The QuickNode Marketplace offers various tools to improve transaction settlement rates and minimize MEV exposure. The Lil' JIT - Jito Bundles & Transactions add-on allows you to bundle transactions for fast, ordered execution, including MEV and rollback protection. Additionally, the marketplace provides the ability to add MEV protection to your existing sendTransaction calls through the Solana MEV Protection & Recovery add-on. This add-on not only provides protection from front-running, but also supports MEV recovery (returning captured non-malicious MEV back to you), enhances privacy, and ensures fast execution.

• Protect Against Unnecessary State Changes: Utilize Transaction Guards. Lighthouse is a runtime assertion engine for Solana programs that will fail transactions when it detects on-chain state deviating from expected state. You can add Lighthouse assertions to your transactions to ensure that the state of specified accounts meets predefined expectations at the end of the transaction execution (e.g., if the specified token balance is less than X after this transaction, reject the entire transaction). This allows for more complex account checks beyond simple slippage, and enables assertions on Sysvar (slot) data, which can be used for blacklisting validators - achievable by leveraging getLeaderSchedule and a list of malicious validators.

• Set Limits: Establish Slippage Caps and Utilize Limit Orders. When making swaps, always set the slippage to a level suitable for your trade and risk tolerance. Assume malicious actors are trying to exploit any opportunity allowed by your slippage rate. When your use case permits, use limit orders to set a minimum price for selling tokens. Check out QuickNode's Metis API, which supports limit orders.

Summary

MEV is an important factor to consider when building on any Blockchain, and Solana is no exception. We've learned that Solana's design has changed the game, but MEV still manifests through arbitrage, liquidations, and sandwich attacks. As a Solana DeFi tool developer, ignoring MEV could lead to suboptimal transaction outcomes for your users or your bots losing profitability. The good news is that many tools can help you mitigate these issues, regain control over transaction ordering, and even capture MEV for yourself or your users.

Additional Resources

• Solana MEV: An Introduction

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

• Merkle.io MEV Protection Marketplace Add-on

• Open-Source Malicious Validator Tracker

• Lighthouse Runtime Assertion for Solana Programs

• Strategies for Optimizing Solana Transactions

• Tips to Improve Solana Jupiter Transaction Success Rates

• Jito Validator Clients

• Marinade: Decentralized MEV

• Paladin Validator Clients