Tracking MEV and Sandwich Attacks on Solscan: Detecting Hidden Transaction Ordering

Maximal Extractable Value (MEV) and sandwich attacks represent a persistent and often invisible threat on blockchain networks. A user submits a transaction intending to swap tokens at a certain price, only to find that the transaction executed at a worse rate than expected—sometimes because a bot detected the pending transaction, frontran it with a higher-priority trade, and then placed the original transaction after itself, extracting profit from the price movement it deliberately created. Solana, despite its speed and lower fees compared to Ethereum, is not immune to these attacks. The Solana network’s block production model and mempool design create both opportunities and blind spots for MEV exploitation.

The challenge for traders and developers is that MEV and sandwich attacks are not always obvious from a wallet’s perspective alone. A transaction may confirm and settle, yet the execution price can be substantially worse than the quoted rate. Identifying the mechanism behind poor execution requires deeper analysis: examining transaction ordering within blocks, understanding program call sequences, and recognizing patterns that suggest deliberate price manipulation. This is where a blockchain explorer becomes essential. By analyzing on-chain evidence through detailed transaction histories, program interactions, and block structure, users can build a practical understanding of what happened and how to reduce future exposure.

Understanding MEV and sandwich attacks on Solana

MEV refers to the profit that validators, bots, or other actors can extract by observing pending transactions and reordering them to their advantage. On Ethereum, the concept emerged from gas auctions and public mempools where transaction ordering was relatively transparent. Solana operates differently: the network produces blocks at fixed time intervals, validators process transactions deterministically, and the mempool design is more obscured. However, MEV still exists through several mechanisms.

A sandwich attack on Solana typically follows this sequence: a user broadcasts a transaction to swap, say, 100 USDC for SOL on a decentralized exchange (DEX). A searcher or MEV bot observes this transaction in real time or through a private transaction service. The bot immediately submits its own transaction ahead of the user’s (in the next block or the same block, depending on timing), buying SOL and driving the price up. The user’s transaction then executes at the higher price, receiving fewer tokens. Finally, the bot sells its SOL, pocketing the difference as profit. The user’s loss is the bot’s gain.

Transaction ordering is the fundamental lever. Unlike Ethereum’s gas auction mechanism, Solana blocks can contain transactions from multiple users, and the order in which they execute matters critically. A searcher who can place a transaction before another can exploit market-moving trades. The attack is “hidden” because the final transaction settles normally; the user receives the promised token type and amount, though not at the expected price. Without careful analysis, this appears to be normal market slippage rather than extractive behavior.

Sandwich attacks are not equally likely on all DEX protocols. Orca, Raydium, Magic Eden Swap, and other Solana DEXes have different liquidity models, fee structures, and front-end protections. Some allow users to specify maximum price impact or slippage tolerance; exceeding that parameter should cause the transaction to fail. However, a large swap or volatile market conditions can make slippage high, making it difficult to distinguish between legitimate market movement and bot manipulation. This uncertainty is where transparent data becomes valuable.

Using Solscan to identify transaction sequences and program calls

Solscan is the official and leading blockchain explorer for the Solana network, providing detailed visibility into every transaction and program interaction. When investigating a suspicious trade, the first step is to search for the transaction ID (known as a “signature” on Solana) or the wallet address involved. For real-time transactions, Solscan displays the complete execution record within seconds of confirmation, showing every program called, every instruction issued, and every account modified.

A DEX swap generates multiple program calls in a specific sequence. The user’s wallet must authorize a token transfer, the DEX program must execute the swap logic, and token balances must be updated. Solscan’s transaction details view shows each instruction in order. By examining this sequence, you can verify whether the transaction executed as intended or whether unexpected interactions occurred. For instance, if a swap transaction includes calls to multiple DEX programs or token transfers to unexpected addresses, that suggests a more complex flow—possibly the result of a router aggregating liquidity across pools, or potentially a sign of MEV manipulation.

The program log output on Solscan provides additional clarity. When a program executes, it emits log messages (often human-readable) that describe what happened. A legitimate swap might log “Swap executed: 100 USDC -> 48.5 SOL.” A suspicious transaction might show unexpected token transfers, failed error-handling branches, or interactions with programs the user did not intend to authorize. Reading these logs requires some protocol familiarity, but they often reveal the true flow of assets and whether the execution matched the user’s expectation.

Block information on Solscan also matters. Solana produces blocks approximately every 400 milliseconds. Within a block, transaction order is deterministic based on the validator’s scheduling. If you examine a suspicious swap transaction, Solscan shows the block slot in which it occurred, the block time, and the sequence of other transactions in that block. If a large buy transaction (the sandwich attack’s frontrun) appears immediately before your swap, and a corresponding sell appears immediately after, the pattern becomes visible. This reordering would not prove intent definitively, but it strongly suggests MEV exploitation.

Recognizing patterns of frontrunning and price impact

A single transaction examined in isolation can be ambiguous. Context and pattern recognition are necessary. On Solscan, when you view a wallet’s transaction history, you can begin to identify patterns. For instance, if you observe that your swap transactions consistently execute at worse prices than displayed by the DEX frontend, and if the slippage is far larger than market volatility alone would explain, repeated MEV exposure is likely.

The key pattern to look for is asymmetric transaction ordering. A legitimate market-moving transaction (a large swap) should update prices gradually according to the DEX’s liquidity model. If a smaller transaction (your swap) causes a disproportionately large price change, or if you see a simultaneous large purchase that moved price before your order, the ordering suggests frontrunning. Solscan’s real-time transaction tracking allows you to load multiple transactions in sequence and build a timeline of what happened in a particular block.

Sandwich attacks often create a specific signature on-chain: three closely related transactions (frontrun, victim, backrun) that involve the same token pairs and occur in rapid succession. Searching for tokens in a block on Solscan and sorting by time can help you identify these triplets. The frontrun transaction will typically show a token purchase; your transaction will show a swap at a worse rate; the backrun will show a sale. The combined effect is a net profit for the bot and a net loss for you, with all three transactions visible and verifiable on the blockchain.

However, not every bad execution is MEV. Legitimate slippage occurs because DEX liquidity is finite and prices move due to supply and demand. High market volatility, large transaction size relative to pool liquidity, or simply poor timing can all explain worse-than-expected outcomes. The distinction becomes clearer when you compare your transaction to others in the same block or in adjacent blocks. If other similar-sized swaps execute with minimal slippage while yours does not, MEV is more likely. If the slippage is consistent across multiple transactions regardless of market conditions, infrastructure issues or a private transaction service (such as Jito) may be relevant instead.

Analyzing program calls and authorization flows

Every action on Solana requires one or more instructions, and each instruction invokes a specific program. When you initiate a token swap, your wallet signs a transaction containing multiple instructions. Solscan displays each instruction’s program address, the accounts it accessed, and the data it processed. Advanced users can decode this data to understand exactly what parameters were passed—such as the minimum output amount, the slippage tolerance, and the target pool.

A DEX swap typically involves these programs: the token program (SPL Token), the DEX’s own program (e.g., Raydium, Orca), and possibly an aggregator or routing program if the transaction uses a DEX aggregator. If you see a transaction that involves unexpected programs—particularly programs you did not authorize—that is a red flag. For instance, if a swap transaction includes a call to an unknown or newly created program, that could indicate a compromised transaction or a scam attempt rather than MEV, but it still represents execution you did not authorize.

The account access list on Solscan is equally important. Each instruction specifies which accounts it reads from or writes to. For a legitimate swap, the accounts should include your wallet (the signer), the token accounts involved, the DEX’s liquidity pools, and the mint addresses of the tokens. If you see transfers to unfamiliar accounts or writes to accounts you do not recognize, that suggests the transaction did more than you intended. Comparing the accounts on Solscan to the addresses you explicitly approved in your wallet software helps verify that your transaction went where you authorized.

For developers or technically inclined users, Solscan provides API access to retrieve transaction details programmatically. This enables you to monitor your own transactions, build alerting systems, and analyze patterns over time without manually inspecting every swap. By querying transaction history, filtering by program, and analyzing instruction sequences automatically, you can detect systematic MEV exposure and refine your trading strategies or infrastructure accordingly.

Comparing DEX protocols and slippage tolerance settings

Different DEX protocols on Solana handle transaction ordering and price protection differently. Understanding these differences helps you choose protocols less vulnerable to MEV and to set appropriate safeguards. Constant product market makers (CPMM), such as those used by Raydium, determine price based on the ratio of liquidity in two pools. A large swap significantly changes that ratio, resulting in high slippage. Concentrated liquidity models, such as Orca’s, can reduce slippage for smaller trades by concentrating liquidity around current market prices, though this introduces other trade-offs.

Slippage tolerance is your primary defense against sandwich attacks. When you initiate a swap, most DEX frontends allow you to specify the maximum price change you will accept. If the swap would result in worse execution than your tolerance, the transaction fails and your tokens are returned. Setting slippage tolerance to a tight percentage (e.g., 0.5% for a volatile market) ensures that even if a sandwich attack occurs, your transaction will revert rather than execute at an unacceptable price. On Solscan, when you view a swap transaction that failed due to slippage, the program logs will typically show an error indicating that the output was below the minimum specified.

Private transaction services, such as Jito bundles on Solana, represent another approach to MEV protection. These services allow you to submit transactions that are bundled together and processed without public visibility until they are on-chain. This reduces the exposure window for frontrunning because bots cannot observe your pending transaction in real time. However, using these services involves a trade-off: you pay a bundle fee, and you trust the service provider not to extract MEV themselves. Examining transactions that used Jito on Solscan can help you understand whether the fee justified the protection.

Practical protection often involves combining multiple strategies: setting tight slippage tolerance, using private transaction services for large trades, choosing DEX protocols with lower liquidity concentration risk, and monitoring your execution on Solscan.io to detect patterns of poor execution. No single approach eliminates MEV, but together they significantly reduce both the frequency and magnitude of exploitation.

Building a personal MEV detection workflow

Routine monitoring of your transactions is the simplest way to detect systematic MEV exposure. After each significant swap, check Solscan for your transaction ID and note the execution price versus the quoted price. Over several transactions, patterns emerge. If slippage is consistently higher than market volatility would suggest, MEV is a likely explanation. If slippage is high specifically for large transactions or during volatile periods, that suggests the DEX’s liquidity model rather than directed attacks, and adjusting transaction size or protocol choice may help more than MEV-specific protections.

For regular traders, maintaining a simple spreadsheet of transactions (date, token pair, quoted price, execution price, slippage, protocol used) provides data for analysis. After 10 or 20 transactions, you can calculate your average slippage under different conditions and compare it to market benchmarks. If your average slippage significantly exceeds other users’ reported experience, that signals a problem worth investigating further through Solscan analysis and transaction detail review.

If you suspect a particular transaction was sandwiched, the analytical process on Solscan is straightforward. Search for your transaction ID, note the block slot and timestamp, then examine other transactions in that block. Look for patterns: a large token purchase immediately before your swap (frontrun), or a sale immediately after (backrun). Check the program logs to understand the execution flow. Solscan’s advanced search filters and wallet exploration features allow you to filter transactions by program, token, and time window, making it easier to identify related transactions and confirm a sandwich pattern.

Developers building trading bots or DEX integrations should use Solscan’s API and programmatic access to automate this analysis. By monitoring mempool activity (where available) and on-chain transaction outcomes in real time, you can identify MEV patterns, adjust strategies, and contribute to the broader understanding of Solana’s MEV landscape. The transparency that Solscan provides is the foundation for both defensive and offensive optimization.

Limitations and what Solscan cannot reveal

Solscan provides transparent, accurate data from the Solana blockchain, but it has important blind spots. Most critically, Solscan cannot directly observe transactions before they are confirmed. Solana’s mempool is not fully public, and private transaction services intentionally hide pending transactions. If a sandwich attack involved a private bundle (such as Jito), the frontrun and backrun transactions may not have been visible on public infrastructure before execution. In this case, Solscan will show the completed transactions, but not the full temporal picture of how the bot observed and reacted to your trade.

Solscan also cannot definitively prove intent. An observer can see that a bot bought tokens before you, increasing the price, and sold after you. The pattern suggests intentional extraction, but the blockchain record alone does not capture the bot operator’s actual awareness or decision-making. It is possible (though less likely) that the ordering was coincidental or the result of different strategies executing independently. However, when patterns are consistent and repeated, probabilistic confidence in MEV increases substantially.

Another limitation is that Solscan shows what happened on-chain, not what alternative outcomes were possible. If you executed a swap at an unexpected price, Solscan can help you confirm that the execution matched the DEX’s code, but it cannot tell you what price the pool would have offered five seconds earlier or later, or what would have happened if the transaction had been processed in a different block. That analysis requires additional context, external pricing data, and simulation—tools that are beyond Solscan’s scope but which Solscan’s data can support.

Finally, Solscan’s real-time data is accurate but can reflect network lag during periods of congestion. During extreme network activity, transaction confirmation can be delayed, and block times may vary. Under these conditions, relying solely on Solscan for time-sensitive MEV analysis can be misleading if you do not account for when data was recorded versus when transactions actually executed.

Practical next steps after detecting sandwich attacks

If analysis on Solscan confirms that you were the victim of a sandwich attack or consistent MEV extraction, several options exist. The most immediate is to adjust your trading behavior: use tighter slippage tolerance, split large trades into smaller ones to reduce market impact, use private transaction services, or shift to DEX protocols with different liquidity models. These are defensive measures that reduce the MEV-attackable surface without requiring protocol changes or external remediation.

For more substantial losses or frequent extraction, exploring alternative routing may help. Some DEX aggregators use MEV-aware routing that deliberately selects paths designed to minimize extractable value. Others integrate with private transaction services by default. By testing different frontends, routers, and protocols on Solscan and comparing execution quality, you can identify infrastructure choices that work better for your trading patterns.

Developers should consider whether their applications can surface this data more transparently to users. A DEX frontend that compares quoted slippage to actual execution and alerts users when they diverge significantly would make MEV visible and enable informed decisions. By building MEV awareness into user-facing applications, the ecosystem can reduce the information asymmetry that makes sandwich attacks profitable in the first place.

Finally, tracking and reporting patterns of systematic MEV extraction contributes to the broader goal of making the Solana network more fair. Researchers and developers use reported MEV data to improve protocol design, improve validator incentives, and develop better protection mechanisms. By using Solscan to understand your own transactions and contribute observations to the community, you participate in making the network more transparent and resilient.