Maximal extractable value, or MEV, represents a persistent threat to decentralized exchange traders on Solana. When a transaction enters the mempool, validators and bot operators can observe pending orders, front-run desirable trades, or deliberately place competing transactions immediately after the user’s swap. These sandwich attacks—where a malicious transaction precedes and follows the target trade—can extract significant value through price slippage and forced settlement at worse rates. A trader paying a quoted price of 100 USDC per SOL may discover that their transaction actually filled at 102 USDC because intermediate transactions moved the market against them.
Understanding where MEV occurs and how to detect it requires more than intuition about market conditions. It demands access to detailed transaction data, program interactions, and the ability to reconstruct execution order from the blockchain itself. Solscan provides the infrastructure for this analysis: its transaction decoder, program explorer, and advanced search capabilities allow traders to examine the exact sequence of events, identify suspicious patterns, and understand the true cost of their execution. Rather than accepting slippage as inevitable, informed traders can use Solscan’s tools to measure whether their trades are victims of organized extraction.
How MEV manifests in Solana transactions
MEV on Solana differs from Ethereum in several important ways, but the fundamental opportunity remains the same: an actor with visibility into pending transactions can profit by reordering, inserting, or suppressing them. Solana’s faster block times and validator network reduce some traditional MEV opportunities—account locking prevents some forms of concurrent sandwich attacks—but they do not eliminate it. Instead, MEV on Solana takes shape through different mechanisms: a bot can copy a user’s swap parameters, execute a similar trade slightly ahead in the same block, and profit when the user’s larger transaction causes price movement.
This is distinct from Ethereum sandwich attacks, where front-running and back-running transactions are placed in explicit order around the target. On Solana, the attack often exploits the fact that transactions within a single block can be executed in a flexible order. A validator or bot operator can reorder instructions or place transactions strategically to profit from the state changes that a user’s trade causes. The attacker learns the user’s swap from mempool observation, executes a smaller version of the same swap themselves, then allows the larger user trade to execute and move the market, before the attacker sells their acquired tokens at the improved price.
The cost to the victim is direct: if the attacker acquires tokens before the user’s large trade, they benefit from the price increase that the user’s trade causes. The user suffers the same increase as slippage. Price impact from a legitimate trade is unavoidable on any DEX, but MEV-driven slippage adds an artificial layer on top. A user expecting 100 SOL for 10,000 USDC might receive only 98 SOL because 0.5 SOL went to the MEV actor and 1.5 SOL represents price impact that was made worse by the sandwich structure.
Reading Solscan’s transaction decoder to identify MEV patterns
The transaction decoder in Solscan breaks down every instruction and program interaction in sequence. Each DEX trade is composed of multiple instructions: the swap program call, the token transfer, the fee mechanism, and possibly oracle updates or governance interactions. By examining the decoder output, a trader can reconstruct exactly what happened and in what order. This becomes essential for detecting MEV because the patterns of a sandwich attack have specific signatures in the instruction sequence.
Start by identifying the main swap instruction. Use Solscan’s advanced search and filters to locate your transaction by wallet address or transaction ID, then open the transaction details page. The instruction list shows each program that was called and the order of execution. For a simple swap on Raydium or Orca, you will see a single swap instruction followed by token transfers that settle the trade. But when MEV is present, you often observe additional swap transactions from other addresses in the same block.
The key insight is to examine the accounts involved in the swap. Solscan displays which token account, pool, and authority are referenced in each instruction. If you see multiple swaps in the same block that reference the same liquidity pool, and one occurs before yours while another occurs after, you may be observing a sandwich. The price at which each swap executed depends on the pool state at that moment. If an attacker’s swap changed the pool state before your trade executed, your price impact will be worse than expected.
This requires comparing the reported slippage against actual execution. Most DEX interfaces show an expected output based on current pool reserves. If your transaction shows 98 SOL received but you expected 100 SOL with typical price impact, the difference might reflect MEV. By cross-referencing the token balances before and after each instruction using Solscan’s token account details, you can calculate the effective exchange rate and determine whether it matches your expected slippage or exceeds it.
Using the program explorer to understand liquidity pool interactions
Solscan’s program explorer provides detailed information about smart contracts and their state. For DEX trading, this means examining the liquidity pool accounts and their reserve balances before and after a transaction. Understanding the pool state is critical for detecting MEV because sandwich attacks specifically exploit price movement through legitimate trades. If you can see the pool balances at each step of a block, you can measure whether an attacker profited from artificial price movement.
To analyze a specific DEX program, search for it by address in Solscan. Major DEX programs like Raydium’s swap program or Orca’s whirlpool program have their own pages showing transactions that interact with them. This allows you to see all recent activity and identify patterns. If you notice multiple swaps involving the same pool in rapid succession, with consistent addresses executing small swaps immediately followed by much larger swaps, you may have found an active MEV bot.
The accounts section of the program page reveals the state accounts associated with the program. Liquidity pools are represented as accounts holding the reserve tokens. When you examine your swap transaction in detail, you can cross-reference the pool account address to see its exact state before and after your trade. Some block explorers show historical account balances, but Solscan’s interface makes this comparison more accessible by displaying the before-and-after values of key accounts in the transaction details.
This matters for a specific calculation: the constant product formula that Raydium and similar AMMs follow. If pool reserves are X tokens and Y tokens before your trade, the product X × Y must remain constant after the trade (minus fees). By verifying this math yourself using Solscan data, you can confirm whether the pool state changed before your transaction executed. If it did, a sandwich attack likely occurred.
Detecting front-running and back-running through transaction sequence analysis
A sandwich attack has three distinct components that appear as three separate transactions on the blockchain: the front-running transaction from the attacker, your legitimate trade, and the back-running transaction from the attacker. By analyzing the transaction IDs and block information visible in Solscan, you can identify whether this pattern occurred around your trade. The challenge is that within a single block, multiple transactions exist, and Solscan’s transaction tracking shows the order they appear in the block.
To detect this pattern, use Solscan’s advanced search to filter transactions by wallet address and time range. If you made a swap at a specific timestamp, look at the block that contains your transaction. Solscan displays all transactions in a block ordered by their position. If you see another wallet executing a similar swap to the same pool immediately before yours, and a third transaction immediately after, you have found the sandwich structure.
The attacker’s profit can be estimated by examining the prices they received. If the front-running bot acquired SOL at price A, then your trade moved the price to B, and the back-run sale occurred at price B, the profit is roughly (B – A) × quantity. By using Solscan’s transaction decoder to extract the token amounts involved in each swap, you can calculate this value directly. This transforms MEV from an abstract concept into a concrete measurement of extraction.
Account-level MEV is slightly different but equally detectable. A validator or private transaction pool might reorder transactions within a block without necessarily creating separate transactions. In these cases, Solscan shows the reordered instruction sequence within the same block. The key is comparing the order you submitted your transaction (shown in the mempool or your wallet records) against the order it actually executed. Significant reordering without matching transactions is a sign that off-chain reordering occurred.
Setting slippage tolerances intelligently using DeFi tools
Every DEX interface allows you to set a slippage tolerance—the maximum percentage difference between the quoted price and the actual execution price. Most traders set this to 0.5% or 1% to avoid catastrophic errors, but these are relatively arbitrary thresholds. A more rigorous approach uses Solscan data to understand your actual slippage distribution, then sets tolerances based on measured patterns rather than guesses.
Start by running several trades and recording both the quoted output (from your DEX interface) and the actual received amount (visible on Solscan). Calculate the percentage difference for each trade. If you consistently experience 0.3% slippage on normal trades and 0.5% on larger orders, you have a baseline. When a trade suffers 2% slippage in normal market conditions, that is a signal worth investigating—and Solscan can help determine whether MEV caused it.
The relationship between order size, pool liquidity, and slippage is deterministic. Larger trades against smaller pools will have predictably higher slippage. By examining historical trades on Solscan for the specific pool you plan to use, you can estimate realistic slippage for your order size. If you plan a 10,000 USDC trade, look at what recent trades of similar size experienced. This empirical approach beats guessing and helps you identify when a trade exceeded reasonable slippage.
Setting slippage too low can cause failed transactions, but that is sometimes preferable to accepting an MEV extraction. A transaction that fails consumes gas but preserves your funds. A transaction that accepts high slippage hands profit directly to an attacker. By using Solscan to measure your expected slippage carefully, you can set tight tolerances and accept the risk of occasional failures rather than routinely overpaying.
Identifying and avoiding high-risk pools and attack patterns
Not all liquidity pools are equally vulnerable to MEV. Deep pools with high trading volume tend to have smaller price impacts per transaction, which makes them less profitable targets for sandwich attacks. Conversely, shallow pools with infrequent trading can suffer large slippage for relatively small orders, making them attractive for attackers. By using Solscan to examine pool depth and recent trading patterns, you can avoid pools where MEV is most likely.
Search for the liquidity pool by its address or the token pair on Solscan. The pool details page shows recent transactions, trading volume, and reserve balances. If you see consistent patterns of small transactions followed by large transactions, all from different addresses, in rapid succession, you may have found a pool frequented by MEV bots. These pools are worth avoiding because the extraction is systematic.
Conversely, pools on Solscan that show long stretches between trades, stable reserve ratios, and transactions of varying sizes from many different wallets suggest a more organic trading environment. These pools typically have less predictable MEV because there is no single attacker monitoring them constantly. Volume and liquidity depth also correlate: higher-volume pools distribute extraction across more trades, making the percentage impact smaller on any single trade.
Another protective strategy is to use pools with slightly less obvious route mechanics. Direct swaps on major DEXs are commonly monitored by MEV bots because the programs are well-known and easy to scan. Swaps that route through aggregators or use less common pools may receive less attention. However, this comes with its own risks: liquidity may be lower, execution may be slower, and you must verify the route on Solscan before committing. The trade-off between convenience and safety requires judgment based on trade size and market conditions.
Private transaction pools and their relationship to MEV
Some traders use private transaction pools or MEV protection services to avoid sandwich attacks entirely. These services bundle transactions and execute them in a private environment before posting to the public blockchain. The advantage is obvious: if your transaction never enters the public mempool, a MEV bot cannot observe it. However, private pools introduce different risks that are worth understanding through the lens of what Solscan can and cannot show.
When a transaction settles through a private pool, it appears on the public Solana blockchain like any other transaction. Solscan can see it, analyze it, and show you the final result. But a private pool may have already optimized the execution, ensuring that slippage was minimized or MEV was extracted by the pool operator rather than by a random bot. This is not necessarily worse—the pool might take a flat fee rather than a percentage—but it is a different arrangement worth evaluating.
The question to ask is: where does MEV go if you use a private pool? Some services claim to eliminate MEV, but they actually capture it themselves. Others genuinely prevent extraction by using cryptographic commitments or threshold encryption to hide the transaction details until after settlement. The difference is visible indirectly: if your slippage on a private pool transaction is significantly better than comparable public swaps, the pool operator likely benefited. This is not necessarily harmful—the benefit might exceed their extraction—but it is worth measuring on Solscan by comparing your results against the baseline you established earlier.
The most transparent approach is to measure outcomes. Use Solscan to track your slippage on both public and private pool trades over a period of weeks. Calculate your average cost per trade including all fees and extractions. If a private pool service reduces your total cost below the public baseline, it is delivering value despite the opacity. If it merely shifts MEV extraction from random bots to a service operator, the outcome is the same but your alignment with the operator matters.
Advanced search and monitoring strategies on Solscan
Beyond one-time transaction analysis, Solscan offers tools for ongoing monitoring. The advanced search function allows filtering by transaction type, program, status, and time range. For a trader concerned about MEV, this means you can search specifically for swap transactions to your favorite pools within a narrow time window, then examine clusters of rapid trades that might indicate bot activity.
Create a list of your frequently used pools. Search Solscan for all transactions to each pool within the last hour. Note the addresses involved, the order, and the sizes. If the same address appears repeatedly in small trades immediately before larger trades from other addresses, flag that address as a potential MEV bot. Over time, this analysis reveals which pools are actively monitored and which are quieter.
You can also set up a monitoring workflow using Solscan’s API if you are technically inclined. Some traders build custom tools that watch specific pools, analyze transaction sequences in real time, and alert them when MEV activity spikes. This requires some development effort, but it can provide a significant edge if you execute large trades frequently.
Additionally, note the correlation between transaction confirmation time and MEV occurrence. High network congestion sometimes coincides with more aggressive MEV activity because delayed confirmation creates more opportunity for reordering. Using Solscan’s block explorer to monitor network conditions alongside your trades can help you identify optimal windows for execution. Trades during lower-congestion periods may naturally experience less MEV pressure.
Frequently asked questions
How can I tell if a sandwich attack happened to my trade on Solscan?
Look for your transaction in Solscan using your transaction ID or wallet address. Examine the block that contains your trade and note the transaction positions. If you see another wallet’s swap to the same pool immediately before yours, and a third transaction immediately after, you have found a sandwich. Compare the prices: if the front-runner acquired tokens before your trade at a lower price and sold them after at a higher price, they profited from artificially moving the market. Calculate the difference between your expected slippage and actual slippage using Solscan’s transaction decoder—unexplained slippage beyond normal price impact suggests MEV extraction.
What’s the difference between MEV on Solana and Ethereum as shown on Solscan?
Ethereum sandwich attacks often involve explicit front-running and back-running transactions placed sequentially before and after the target trade. Solana allows more flexible transaction reordering within blocks, so MEV attacks often exploit instruction-level reordering or copy a user’s swap parameters and execute a smaller version of the same trade. Solscan’s transaction decoder shows the exact instruction sequence, which makes Solana MEV patterns visible at a more granular level. Understanding these structural differences helps you interpret what you see on Solscan.
How do I use Solscan to choose a safer liquidity pool for my trades?
Search for the liquidity pool by token pair or address on solscan. Review the recent transactions: deep pools with frequent organic trades and no obvious patterns of small transactions followed by larger ones are generally safer. Check the reserve balances and trading volume—higher-volume pools distribute MEV extraction across more trades, reducing impact per trade. Avoid pools where the same address appears repeatedly in small swaps immediately before large swaps from other addresses, as this indicates coordinated MEV bot activity. Compare pools and prefer those with stable, diverse trading activity.
