Analyzing MEV and Frontrunning: Using Solscan to Identify Suspicious Transaction Ordering

Maximal extractable value (MEV) and frontrunning represent persistent vulnerabilities in decentralized finance, where network participants can observe pending transactions and rearrange their execution order for profit. On Solana’s fast-moving blockchain, where thousands of transactions settle per second, these attacks can occur with minimal latency. The challenge for traders and developers is that suspicious ordering often looks identical to legitimate transaction sequences without careful analysis. Understanding how to spot these patterns requires access to detailed transaction data and the ability to correlate behavior across multiple blocks and accounts.

Solscan, the leading blockchain explorer for the Solana network, provides the essential tools to inspect transaction timing, account interactions, and fund flows that reveal MEV and frontrunning attacks. By examining transaction sequences, token movements, and program invocations through Solscan’s interface, traders can identify when their orders were likely exploited, distinguish accidental slippage from intentional extraction, and build a clearer picture of DeFi economics on Solana. This article examines how to use Solscan’s search, filtering, and wallet analysis capabilities to detect these attacks and understand the mechanics that make them profitable.

Understanding MEV mechanics on Solana through transaction data

Maximal extractable value emerges when a participant with visibility into the mempool—typically a validator, searcher, or bot operator—rearranges transactions to capture profit. On Ethereum, MEV is visible because transaction ordering is determined by gas price auctions within blocks; Solana’s architecture is different but MEV still occurs. Solana uses a leader-based consensus where one validator proposes transactions for each slot. Searchers can submit transactions that execute ahead of or alongside legitimate orders, or validators can reorder transactions they see in their memory pool. The profit opportunity exists whenever two consecutive transactions have an exploitable relationship: a swap that moves price, followed by another swap in the opposite direction, creates a spread. This pattern—transaction A, transaction B—visible in a block—can indicate MEV if both transactions originate from related addresses or execute through the same liquidity pools.

The first step in detecting MEV is recognizing what a normal transaction sequence looks like. A legitimate swap on a Solana decentralized exchange (DEX) typically involves a user’s instruction to move token A into a program, the program performing arithmetic against a price curve, and token B being transferred to the user’s wallet. The time between confirmation and settlement is measured in milliseconds. If a second transaction appears between the user’s swap and its settlement, or if a separate transaction immediately precedes the user’s swap and moves price in a way that worsens the user’s output, MEV has likely occurred.

Using solscan, you can examine this sequence by looking at transaction IDs and their order within a block. Each transaction’s details page shows inputs, outputs, token transfers, and the programs invoked. Comparing the token amounts sent to the DEX against the amounts received can reveal slippage that exceeds what the market price movement alone would justify. If a user initiated a swap expecting 100 token B but received only 95, and the price moved less than 5 percent during the transaction’s execution, an MEV extractor likely captured the difference.

The timing data available in Solscan is also crucial. Each transaction shows its slot number and confirmation time. Comparing multiple transactions within the same slot can reveal patterns: if a searcher’s transaction executes before a user’s swap, followed by another transaction that reverses the position, the structure is a classic sandwich attack. The searcher placed the bread on both sides, profiting from the price impact of the user’s order.

Identifying sandwich attacks using advanced search and transaction sequencing

A sandwich attack is the most recognizable form of MEV. A bot purchases token X, the user’s large swap executes against the liquidity pool (moving the price), and the bot sells token X for profit. The attack is profitable only if the attacker’s trades and the victim’s trade occur in the correct sequence within the same block or adjacent blocks. Detecting this pattern on Solscan requires examining not just one transaction but a series of related transactions across the same time window.

The advanced search features on Solscan allow users to filter transactions by program address, timestamp, token transfers, and account involvement. To identify potential sandwich attacks, begin by searching for the DEX program address (such as Raydium, Orca, or Marinade). Then narrow the results to a specific time window, typically a few seconds around your suspicious transaction. Look at the resulting transactions in order. If you see three transactions executing in rapid succession—one buying token X, one large swap involving your account, one selling token X—you have found the attack pattern.

The token transfers tab on Solscan provides another angle. For each transaction, you can see exactly which tokens moved, in what quantity, from which account to which account. An attacker’s wallet will show a characteristic pattern: a transfer of token X into the DEX, then a transfer of token Y out. Checking whether the attacker’s wallet has executed this pattern repeatedly on the same DEX program across multiple blocks can confirm intentional sandwiching rather than coincidental ordering. Sophisticated attackers use new addresses to obscure their activity, but the pattern—rapid profit-taking on small volumes—remains visible if you compare the attacker’s profit margin against the slippage imposed on the user’s transaction.

Solscan’s ability to track account activity across time is essential here. By searching for a specific wallet address, you can review all its interactions with DEX programs. If the address consistently precedes large swaps and profits from small trades, it is likely a sandwich bot. The consistency is the signal: legitimate users do not execute the same transaction pattern thousands of times per day across different pairs with perfect profit margins.

Analyzing MEV through program invocations and token flow visualization

Program invocations on Solana transactions show which smart contracts were called and in what order. This is more granular than checking the block structure alone. When you view a transaction on Solscan, the instruction logs show the sequence of program calls. A legitimate DEX swap will show a specific sequence: a token transfer instruction to move the user’s token into the DEX program, an execution instruction that performs the swap, and a return transfer instruction that delivers the output. An MEV attack may insert additional instructions before or after the user’s instructions.

Examining the token flow visualization helps clarify the direction and magnitude of money movement. Solscan displays how many tokens were transferred, at what point in the transaction sequence, and between which accounts. If a transaction shows an unusually large fee or an intermediate transfer to an address that is not part of the expected DEX mechanics, it may indicate that funds were routed through an attacker’s account or that slippage was extracted before the output reached the intended recipient.

Solana transactions can also include multiple swaps or complex routing, where a user’s order is executed across several liquidity pools to achieve better pricing. Distinguishing legitimate multi-hop routing from MEV routing requires understanding the program logic. If Solscan shows that a transaction invoked five different DEX programs sequentially, each one could be legitimate price-improvement routing, or the extra hops could be there to disguise an MEV extraction step. Checking whether each intermediate transfer improved or worsened the user’s effective price is the diagnostic test. Legitimate routers improve price; MEV extraction degrades it.

The transaction log also includes error messages and partial failures. If a transaction shows a successful token transfer but an instruction marked “failed,” it may indicate that an attacker’s sandwich was unsuccessful or that a transaction was partially executed. Solscan displays this information clearly, allowing you to understand whether your transaction settled fully, was reverted, or executed in an unexpected state.

Comparing wallet activity to identify coordinated MEV operations

Sophisticated MEV operations often involve multiple accounts working in coordination. A searcher might use one account to identify arbitrage opportunities, another to execute the attack, and a third to collect rewards or intermediate positions. By comparing wallet activity on Solscan, you can identify whether accounts that execute related transactions are coordinated or independent.

Start by searching for a wallet address on Solscan. The wallet dashboard shows all transactions, token balances, transaction history, and interactions with specific programs. If you suspect an MEV attack, compare the attacking account’s activity against a legitimate trader’s activity. Legitimate traders show diversity: swaps across different token pairs, different program addresses, varying amounts, and varying time intervals. MEV bots show repetition: the same pairs, the same programs, the same time intervals, and consistent profit margins.

Cross-referencing wallet activity also reveals relationships. If you identify an account suspected of sandwiching, check whether it frequently receives transfers from or sends transfers to a small number of other accounts. MEV operations often have a distribution structure where a primary bot sends funds to subsidiary accounts, or where profits are periodically consolidated to a single address. Solscan’s transaction search allows you to follow these fund flows across multiple transactions and accounts, building a map of the operation’s structure.

The profit calculation is straightforward but revealing. Calculate the difference between what an MEV extractor paid for a token and what they sold it for, accounting for fees. If the profit is consistently 0.5 to 2 percent on every transaction across hundreds of blocks, the account is operating a systematic MEV strategy rather than making occasional profitable trades. Real-world traders show variation due to market conditions and position sizing; bots show consistency, which is a diagnostic signal visible through Solscan’s data.

Detecting failed MEV attempts and learning from unsuccessful attacks

Not all MEV attempts succeed. A bot may predict an opportunity incorrectly, submit a transaction too late, face congestion that prevents proper ordering, or encounter a transaction that executed differently than expected. Solscan reveals failed and partially executed transactions through transaction statuses and error messages. Learning to read these failures provides insight into how MEV operations actually function and can help you identify transactions where an attacker tried but failed to exploit you.

A transaction marked with a partial or failed status typically shows an error code or reason string. Common MEV failure patterns include “slippage exceeded,” where the bot’s sandwich attempt moved the price so far that the reversal trade received less than expected; “insufficient output,” where the pool balance changed between when the bot calculated the opportunity and when it tried to execute; and “account locked,” where another transaction held a write-lock on the pool account, preventing the bot’s transaction from settling.

Examining Solana transactions that show these errors alongside successful sandwiching attempts on similar pairs reveals the attacker’s methodology. If they succeeded on pair A at slot 200 with a 1 percent profit but failed on pair B at slot 201 with “slippage exceeded,” you learn that the attacker’s threshold for profitability is below 1 percent and their tolerance for price slippage is tight. This information helps explain why some of your trades may have experienced unexpected slippage (the attack succeeded) while others settled near fair value (the attack failed or was not attempted).

Using Solscan to filter transactions by program and time window, you can build a dataset of attempted MEV on a specific DEX over a day or week. Comparing success rates across different pairs, times of day, and transaction sizes reveals when MEV pressure is highest and when it is relaxed. This empirical understanding from actual Solana transactions is more reliable than theoretical predictions and directly informs trading strategy.

Using DeFi tools and Solscan’s API for systematic MEV monitoring

For traders and developers who want to move beyond manual investigation, Solscan provides APIs and advanced features that allow programmatic access to transaction data. The API supports queries for transactions, token transfers, wallet balances, and program invocations. Integrating Solscan’s API with your own monitoring system lets you build alerts for suspicious transaction patterns and accumulate data for statistical analysis of MEV on your preferred DEX.

DeFi tools built on top of Solscan’s data include MEV trackers, sandwich detection services, and arbitrage analyzers. Many of these tools are open-source and free to use, allowing developers to contribute improvements or customize the detection logic for their specific needs. The underlying principle is consistent: pull transaction data from Solscan, identify patterns that match known MEV structures, and flag suspicious transactions for human review or automated response.

Implementing systematic monitoring requires defining what “suspicious” means in your operational context. A 0.5 percent deviation from fair value on a 10,000 token swap is noise; on a 100 token swap, it is an attack. Automated tools must incorporate position size, market volatility, liquidity depth, and DEX fee structures to avoid false positives. Solscan’s real-time data and historical archives make it possible to backtest detection logic against actual transactions before deploying alerts.

For developers building MEV-resistant protocols or DEX front-ends, Solscan is the primary diagnostic tool for understanding whether their protections are working. After deploying batch auctions, encrypted mempools, or other MEV mitigation techniques, examine the Solana transactions on the new protocol through Solscan to confirm that sandwich patterns no longer appear. Tracking MEV levels before and after a protocol change requires the ability to search, filter, and analyze transaction data at scale, which Solscan’s interface and API support directly.

Privacy and risk considerations when researching MEV

Investigating MEV by examining Solscan transaction data does not expose your own transactions unless you choose to analyze your own wallet. However, publishing your findings or sharing specific wallet addresses can have consequences. If you publicly identify an MEV bot, the bot operator may respond by targeting you, moving to a new address, or adopting more sophisticated obfuscation. There is no perfect response to this risk, but awareness is essential: do not assume that analyzing an attack is a safe activity with no potential for escalation.

When using Solscan to investigate suspected attacks, avoid sharing your wallet address or transaction IDs in public forums until you have decided whether to pursue recovery or dispute resolution. Solscan is a public explorer, and all data visible there is already public, but drawing attention to it can speed up countermeasures. If you intend to dispute a transaction with a DEX or exchange, collect your evidence through Solscan first, then engage with the platform through proper channels rather than social media.

On the technical side, understand that Solscan’s data is only as accurate as the Solana network’s consensus. In rare cases of chain reorganization or validator issues, historical transaction data may be rewritten. For critical investigations, cross-reference Solscan’s data against other Solana RPC providers or archive nodes. Additionally, Solscan’s user interface and API have rate limits; do not exceed them in automated queries, as this can result in temporary blocks or access restrictions.

Moving forward: Adapting to MEV-resistant protocols and trader strategies

The existence of MEV on Solana is not a reason to avoid the network; it is a normal cost of transparent, decentralized finance. Understanding how to recognize and measure MEV through Solscan is the foundation for either accepting this cost or choosing to trade on protocols and DEX designs that reduce it. Some traders integrate MEV estimates into their slippage expectations; others use MEV-resistant routing to minimize exposure; still others trade during periods of lower MEV pressure.

The most actionable next step is to examine your own recent transactions on Solscan. For any swap you made that resulted in unexpected slippage, pull the transaction details and review the surrounding transactions in the same block. Compare your output against what you would expect based on the price at the time of execution. If you find consistent patterns of worse-than-expected outcomes, MEV is likely a factor in your trading. This empirical observation should guide your next choices: whether to adjust order size, use limit orders instead of market orders, employ MEV-minimizing routers, or trade on DEX designs like batch auctions that reduce sandwich opportunities.

Solscan remains the essential tool because it provides the transparency needed to make these decisions. Without access to detailed transaction sequencing, token flows, and account activity, MEV would be invisible and traders would be forced to guess. By learning to read Solscan’s data, you are equipping yourself with the same information that attackers and sophisticated traders already use. This is not a guarantee against losses, but it is a foundation for understanding them.