A trader submits a swap on the Solana network expecting to exchange 100 USDC for SOL at the current market rate. Within seconds, the transaction appears in the mempool—the waiting area for pending transactions before they are included in a block. Before the trader’s transaction settles, another transaction pushes the price higher. Then the trader’s swap executes at a worse rate. Finally, a third transaction exits the position and captures the profit created by the price movement. This sequence is a sandwich attack, and it exploits the transparency that makes blockchain analysis possible. Understanding how to identify these patterns in transaction data is essential for anyone trading on Solana, because the ability to spot manipulation depends on reading the actual sequence of events rather than trusting interface-level confirmations.
Maximal extractable value, or MEV, refers to the profit that can be extracted from transaction ordering, inclusion, and exclusion within a block. On Solana, where transaction finality is measured in seconds and mempool visibility creates tactical opportunities, MEV tactics range from simple sandwich attacks to more complex liquidation cascades and arbitrage harvesting. A blockchain explorer designed for Solana transactions allows traders and developers to reconstruct exactly what happened: which address initiated which action, in what sequence, at what cost, and with what outcome. The challenge is that raw transaction data does not label manipulation as such. A sandwich attack looks like three ordinary swaps until you recognize the pattern and calculate whether the middle transaction paid an abnormal slippage cost relative to market conditions at the time of execution.
How sandwich attacks work and why they persist on Solana
A sandwich attack requires three components: visibility into pending transactions, the ability to execute transactions before and after a target, and a market condition that creates profit from the reordering. Solana’s architecture does not guarantee fixed transaction ordering within a slot, and validator clients can observe transactions in the mempool before they are finalized. Unlike some blockchains where mempools are intentionally obscured, Solana’s public mempool visibility means that a builder, searcher, or validator who monitors the network can see what others are about to do and position transactions accordingly.
The mechanics are straightforward. A user broadcasts a token swap through a decentralized exchange such as Raydium or Marinade, intending to trade SOL for USDC. The transaction enters the mempool with a signature and instruction set specifying the input amount, minimum output amount, and destination pool. A MEV searcher or bot monitoring the network observes this transaction. The searcher recognizes that the swap will move the pool’s price unfavorably for the user—meaning the user will receive less USDC than the current spot price would suggest. The searcher submits a transaction before the user’s swap that also buys from that same pool, driving the price higher. The user’s swap then executes at that worse price. Finally, the searcher sells the tokens they bought, capturing the difference between the price they paid and the price after the user’s swap moved the market.
The profit to the searcher is the victim’s loss. A user expecting 50 SOL from a 10,000 USDC swap might receive only 45 SOL if sandwich attacks extracted 10% slippage. Transaction tracking via a Solana blockchain explorer reveals whether this pattern is present in the historical record. The three transactions will appear in order, often within a single slot, with the searcher’s “entry” transaction moving the pool before the user’s swap and the “exit” transaction selling the tokens immediately afterward. The user’s swap shows a significantly larger price impact than would be expected from the trade size alone.
Reading transaction sequences in Solscan for MEV signals
Solscan provides access to full transaction details—sender addresses, receiver addresses, token amounts, fees, program invocations, and exact execution order within a block. When analyzing whether a transaction was subjected to MEV, the starting point is the transaction timestamp and slot number. All three transactions in a sandwich attack will typically execute within the same slot or adjacent slots, often within the same second. If a user’s swap shows a slot number and you can retrieve the full transaction list for that slot, you can observe the exact sequence without inference or speculation.
The next signal is the token flow pattern. In a sandwich attack, the attacker’s entry transaction will send tokens to a liquidity pool and receive tokens out. The victim’s transaction follows, sending tokens to the same pool and receiving fewer tokens out than expected. The attacker’s exit transaction then sends those received tokens onward, often to a wallet that frequently executes similar patterns. By examining the wallet tracker and following the token movements, a trader can confirm whether tokens flow from the attacker, through the pool, back to the attacker in rapid succession with the user’s transaction in the middle.
Fee analysis also provides evidence. A sandwich attacker must prioritize their transactions to ensure they execute in the correct order. On Solana, this means paying higher fees than competing transactions. If the attacker’s entry and exit transactions show fees 10 or 100 times higher than ordinary transactions in the same slot, that is consistent with deliberate prioritization. The user’s swap may show a modest fee, while the attacker’s transactions show much higher fees—evidence of intentional ordering rather than coincidence. A tool that enables you to examine Solana transactions in detail can make these comparisons visible side by side.
Identifying liquidation cascades and layered MEV
Sandwich attacks are the simplest form of MEV, but more complex patterns exist. A liquidation cascade occurs when a large price movement triggered by one transaction causes a second transaction—often an automated liquidation bot—to execute, which triggers further price movements that harm other users. A lending protocol tracks positions and liquidates accounts when collateral falls below a threshold. If a large swap moves the price and triggers liquidations, the liquidator may extract profit while the original user bears most of the loss.
In Solscan, a liquidation cascade appears as a cluster of transactions in quick succession affecting multiple wallets and pools. The initial transaction shows a large transfer that moves the market. Subsequent transactions show liquidations or forced sales by other protocols or bots responding to price changes. The user who submitted the first large transaction may not have intended to trigger the cascade, but they bear the cost through slippage, while the liquidator profits from executing at a better price due to the market movement they did not create.
Layered MEV combines multiple tactics. A searcher might execute an arbitrage trade across two pools, a sandwich attack against a third user, and a liquidation all within the same slot. Each transaction serves a specific purpose, but the combined effect extracts value from the network in ways that individual transactions do not reveal. Reading the full transaction sequence in wallet tracking data allows a developer or analyst to untangle which wallet initiated each action, what the economic outcome was, and whether the pattern suggests deliberate coordination or independent actions that happened to coincide.
Slippage tolerance as a MEV defense mechanism
Every decentralized exchange interface allows users to set a slippage tolerance—a threshold below which the transaction will revert rather than execute at an unfavorable price. A user trading SOL for USDC with a 0.5% slippage tolerance means the transaction will fail if the actual output falls more than 0.5% below the quoted rate at submission. This is a critical defense against sandwich attacks because it prevents the attacker from moving the price too far without aborting the user’s transaction entirely.
However, slippage tolerance is only as good as the quote it protects. If the interface shows a quote 5 seconds old because of network latency or staleness, the slippage tolerance will not protect against the difference between that old quote and the actual execution price. Additionally, a user who sets slippage tolerance too high—say, 10%—is essentially accepting a sandwich attack up to that threshold. The right slippage tolerance depends on volatility: a volatile pair might justify 1% or higher, while a stablecoin pair should rarely exceed 0.1%. Transaction tracking reveals what the actual slippage was, enabling users to compare their tolerance setting against reality and adjust for future trades.
Examining historical transactions in Solscan shows whether a user’s slippage tolerance was hit. If a swap executed and the user received within 0.5% of the expected amount, the slippage tolerance was effective. If the user received 15% less than expected, either the tolerance was set too high, or the user accepted the MEV cost as part of trading. Neither choice is inherently wrong, but understanding the actual cost of slippage—measured in tokens lost, not just percentage points—is important for evaluating whether trading behavior is profitable.
Validator and builder concentration as structural MEV risk
MEV is not only a transaction-level phenomenon. It is also a network-level one. Solana’s validator set concentrates stake among a handful of operators. Jito Labs, a builder and MEV infrastructure provider, processes a significant portion of Solana transactions. This concentration means that MEV extraction is not equally distributed among thousands of independent miners; it is concentrated in the hands of a few builders and validators who control block production and can observe and order transactions accordingly.
A trader using Solscan to analyze their losses should recognize that some MEV is structural—it cannot be avoided by choosing a different DEX or adjusting settings, because the same builder or validator will observe the transaction regardless. Other MEV is competitive—multiple searchers race to sandwich the same transaction, and the most profitable searcher wins, capturing the excess profit. Structural MEV extraction by concentrated entities is more concerning from a fairness perspective, while competitive MEV is at least distributed among many participants rather than concentrated in one builder’s hands.
The concentration of Solana’s validator set and builder market is not visible in individual transaction data. It requires analyzing the historical distribution of MEV rewards across addresses, the proportion of transactions processed by each builder, and the correlation between builder behavior and user losses. This analysis is possible using Solscan’s data exports and advanced search features, combined with analysis of on-chain MEV rewards and liquidation patterns over time. Users who understand this structural risk can make informed choices about which protocols to use, which validators to delegate to, and whether the cost of MEV on Solana is acceptable relative to the network’s finality and speed benefits.
Tools and methods for MEV detection and analysis
Manual analysis of transaction sequences is the most reliable method for identifying MEV in individual trades, but it does not scale to analyzing thousands of transactions. Several approaches exist for automating detection. A bot monitor can track known MEV extraction addresses and flag transactions that interact with them. These addresses often follow predictable patterns—they submit entry and exit transactions in close proximity, they hold diverse asset balances ready for rapid deployment, and they process high volumes of transactions relative to ordinary user wallets.
Pool impact calculation offers another detection method. By comparing a transaction’s input amount and output to the current pool state and spotting changes caused by preceding transactions, analysts can estimate how much worse off a user was due to price movements caused by preceding transactions. If the impact is larger than what would be expected from the transaction’s own size and the pool’s depth, external transactions—likely the attacker’s entry transaction—are responsible.
Time-series analysis of pool prices can reveal artificial moves. If a pool’s price jumps sharply within a single slot, then returns to near its previous level within the next slot, that is consistent with a sandwich attack where the attacker temporarily moved the price for profit. Legitimate price discovery would occur more gradually or in response to external price information. Solscan’s transaction and block data, combined with price feeds, allows these calculations to be performed retroactively on any past transaction.
Strategies to minimize MEV exposure in Solana trading
No single strategy eliminates MEV entirely, but traders can reduce exposure through deliberate choices. The first is batch auction design: splitting a large trade into smaller, randomized chunks over time rather than submitting one enormous swap. This reduces the profit available to a single sandwich attacker because the price movement from any one chunk is smaller, and the attacker cannot reliably order multiple chunks together.
The second is private pool routing. Some DEXes and routing protocols, such as Marinade’s internal swaps for SOL staking transactions, do not expose transactions to public mempool visibility before execution. Using these private routes prevents searchers from observing the transaction in advance, though the cost is typically reduced liquidity or higher fees due to the privacy benefit.
The third is off-chain aggregation. Instead of routing directly through a DEX, a user can submit a trade to an aggregator or intent-based system that batches orders and executes them in a single transaction. If the aggregator has access to sufficient liquidity and can guarantee execution, the batching reduces the transparency of individual intent to external observers, though the aggregator’s operator still knows the order details.
The fourth is threshold awareness. If a user is willing to trade only when the market meets certain conditions—for example, only when the bid-ask spread is below 0.1% and the pool has sufficient depth—they can reduce the profitability of sandwich attacks against them. A transaction that would be profitable to sandwich when the user is willing to tolerate 5% slippage becomes unprofitable when the user will reject any outcome worse than 0.3% slippage. Setting realistic but tight thresholds makes the user a less attractive target.
The relationship between blockchain transparency and MEV risk
MEV exists because the blockchain is transparent. In a traditional financial market, traders sometimes benefit from information advantages, but the exchange infrastructure typically obscures the order book from public view until execution. Solana’s public mempool provides that order book to everyone simultaneously, which is good for permissionlessness and bad for privacy. The same transparency that allows any developer to build an application and any user to verify transactions also allows any searcher to observe and frontrun pending transactions.
This is not a flaw unique to Solana. Bitcoin, Ethereum, and most blockchains face similar MEV challenges. Solana’s speed and cost make MEV less catastrophic in percentage terms—a 5% sandwich attack on a $100 trade costs $5, a meaningful but manageable loss. On Ethereum, the same attack might cost $10 in fees alone due to gas prices, making smaller trades uneconomical and concentrating MEV among larger participants. The trade-off between transparency and MEV resistance is structural to how blockchains work, and choosing to use Solana implicitly accepts some level of MEV exposure as part of the cost of finality and low fees.
Users can accept this trade-off consciously and optimize their behavior accordingly, or they can be surprised by sandwich attacks they did not know were happening. Transaction tracking via blockchain analysis is the difference between these two states. By reviewing historical transactions and understanding the patterns that indicate MEV extraction, traders and developers move from passive victims to informed participants who can evaluate their actual costs and make choices that align with their risk tolerance and trading frequency.
Frequently asked questions
How can I tell if my Solana transaction was sandwich attacked?
Review the transaction in Solscan by checking the slot number, examining all transactions in that slot, and comparing the token flows. If two transactions from the same address or related addresses surround your swap—one before and one after—and the surrounding transactions moved the same liquidity pool, a sandwich attack likely occurred. Calculate whether your slippage exceeded what would be expected from your trade size alone; if it did, external transactions moved the price against you.
Can I set slippage tolerance to zero to avoid sandwich attacks?
No. Slippage tolerance must account for legitimate price movement during the transaction’s execution time. Setting it to zero would cause transactions to fail unless the execution price matched the quote exactly, which is not realistic. Instead, set slippage tolerance to the smallest value that still allows transactions to succeed—typically 0.1% to 0.5% for liquid pairs—and understand that MEV may cause actual slippage to exceed this in extreme cases.
Which Solana DEX has the least MEV exposure?
No single DEX eliminates MEV entirely, but DEXes with private routing or batch auction designs reduce exposure relative to standard liquidity pools. Additionally, the amount of MEV depends on the transaction’s size and the pool’s depth as much as the DEX choice. A large swap on any DEX will be more attractive to sandwich attackers than a small swap, regardless of which protocol executes it. Comparing historical MEV costs across protocols using transaction data is more reliable than relying on marketing claims.