Sandwich-Proofing Your DEX Swaps: A 2026 MEV Protection Playbook

By using sandwich bots, large amounts of money are being stolen from Solana users over a period of 16 months estimated at between $370M to $500M (or about $45M/month). Ethereum sandwich attacks bring about $180M/month in losses to traders from that blockchain. Since attacked blockchains use public mempools and provide reliable slippage tolerances, the bots can front-run your transaction by placing their buy transactions just before yours and back-run them by placing sell transactions for that same asset just after yours. One way to mitigate your occurrence of being attacked is by tightening your slippage tolerance, routing through private RPC nodes or protected order flow, and splitting large orders between multiple DEXes. You should verify the executable price of your transaction matches with the quote, and also check for toxic markup (meaning addresses of toxic flow or address that consistently front-run for profit).

What Is a Sandwich Attack, in Plain Terms?

In layman's terms, a sandwich attack refers to a type of MEV (Maximal Extractable Value) attack on blockchain transactions. When a bot suspects that you will initiate a transaction on a decentralized exchange (DEX), they take action to initiate a buy (or sell) order in advance of your transaction occurring.

The sequence occurs as follows. When you put an order to buy/sell (swap) on a DEX, your transaction will be stored in a public area (referred to as the mempool) waiting to be included in a blockchain. The mempool is constantly being monitored by MEV searchers. If a searcher monitors one of the pending orders, the searcher may view your order, view the amount being transacted, and confirm the slippage that has been agreed on. If all these parameters work in favor of the searcher, they will initiate an order to buy just before yours (this will help push the buying price of the order higher); your order will then execute at this new price, and once the order is complete, the searcher will then sell back into the new higher buying price you have helped to create (the difference is profit).

Economics of sandwich bots are a real and measurable thing. The Developer Community estimates that in about 16 months, bots extracted between $370M to $500M from Solana users, approximately $45M of revenue per month through around 16 months; whereas on Ethereum, bots have extracted approximately $180M per month (Source: DEV.to). For large and thinly-routed trades, the sandwich bot fees can range between 8% to 10% of the swap value; however, there is an estimated savings of approximately 2% to 5% per trade using MEV protected routing.

How are Public Mempools Allowing for This?

Transparency without privacy creates the issue. Public blockchains allow for visibility of pending transactions, allowing anyone to verify and propagate them; therefore, this feature promotes decentralization; however, it also allows extraction bots a source of public intelligence.

Three Attributes Create This Opportunity:

1. Visibility. Pending swaps are available to be read prior to finalizing.
2. Ordering Control. The person who proposed the block or people who provide higher transaction fees to get the transaction included in the block control the order in which transactions are included. As a result of this, bots compete to get their transaction placed surrounding other people’s transaction(s).
3. Predictable Tolerance. If there is a high slippage tolerance setting, the extraction bots can calculate the maximum price movement that the trader is willing to pay; therefore, there is an exact amount of MEV that can be taken out of the trade prior to it reverting.

While Block Times of Solana are quicker than Ethereum and the fee market is different, thus the mechanics of attacking will be different, the fundamental principle of the bot having visibility to your intent and being able to create an expected tolerance, allows for the sandwich bot to position around your transaction and extract from your pending transactions. The monthly extraction for Ethereum vs Solana also has to do with having the average per block value comparatively larger than Solana and an established ecosystem of searchers.

When considering slippage, it’s important to remember that slippage has another function beyond being a protection mechanism against volatility. If the slippage is set too loosely then it simply becomes the budget that a sandwich bot uses to profit at your expense.

The Defensive Playbook: Five Tiers

No one setting will completely eliminate the risk of getting taken advantage of by a sandwich bot. Defense is layered, meaning each layer of defense removes a portion of the sandwich bot's advantage (visibility, predictability, size).

Layer 1: Slim and Calibrate Slippage

Slippage tolerance is the measure of how far the execution price can move away from the quote before the trade reverts back. A small (slim) slippage tolerance reduces the bot's profit window, therefore if the bot cannot move the market enough (within your slippage), it isn't worth their while to front-run you (either with a sandwich or through stealth).

If you set your slippage too low, then the trades will revert legitimately (due to those trades occurring in volatile pairs) and you pay for the gas for nothing. You should calibrate to the pair you are trading: deep liquid trading pools will accept a very low slippage tolerance; thin pools will need more room for slippage — this is exactly why thin pools are more risky than deep pools when trading for large amounts.

Layer 2: Use a Private RPC or Protected Order-Flow Service

A private RPC endpoint or an order-flow service routes your transaction so that it is not seen in the public mempool until after it has been included in a block. Whenever a sandwich bot observes your transaction (before front-running you), it is not able to see that transaction in the public mempool. This type of MEV protection tooling exists on both Ethereum and Solana and is the most advantageous counter to Mempool surveillance.

Trade-offs include: Transact with the assurance your transaction will be included, at slightly decreased speed, while trusting the relay operator will not expose your order flow improperly. Select endpoints to verify Order Flow. Be careful with opaque relays.

Layer 3: Split Large Orders

Large trade orders greatly affect prices since the larger the order, the more likely they will create price movement. Because large order fills attract large slippage and create price opportunities for traders, breaking an order into multiple smaller orders creates lower price impact for each fill of the smaller order and reduces the potential for trader's taking advantage of the slippage created.

As a comparison, splitting one order into multiple orders incurs additional transaction costs, gas costs (when using automated execution) or delays in execution. There are thresholds at which the cost of splitting an order into smaller orders is greater than the amount saved due to slippage, therefore the size of the smaller orders being split should match the pool's depth instead of being split regardless of the order size.

Layer 4: Compare Executable Price To Quoted

When trading at a Decentralized Exchange (DEX), the price that shows in a DEX User Interface is the quoted price and not an executable price. The executable price will depend upon; current pool depth, routing path and price impact of the trade size at a specific instance in time during trading. The difference between the quoted price and executable price is the amount of slippage with which one may be surprised during a trade.

A DEX scanner is a tool which can assist the trader in determining the difference between quoted price of the trade and executable price of the trade prior to taking action i.e., if the quoted price exceeds the difference in slippage, then it would not be reasonable to swap, it is better to split the order, select another pool or defer buying until pool liquidity increases.

Layer 5: When to Trade, When to Verify Available Liquidity

Price impact is a function of pool depth at the time the trading transaction occurs. Making a trade during times of low liquidity produces exaggerated slippage as well as increased opportunity for sandwich trades. To minimize the impact of your trading on the market, you need to check the depth of the pool being used, the recent amount of volume, and if liquidity is being concentrated at some venues or spread out among multiple venues.

When weighing the pros and cons of using another method to reduce slippage or improve execution, we generally look at opportunity cost: waiting for better depth could mean missing out on a good spread; we need to weigh the slippage we save against the spread we were after.

Defensive Methods vs. Trade-offs

A Quick Example of Slippage Costs

Let's say you want to swap $50,000 for a mid-liquidity token pair. (The figures below are illustrative; they show the math, not a price quote for a specific pool.)

• The quoted amount is $50,000 worth of tokens.
• You use 5% slippage as a common default for volatile pairs.
• A bot sees your trade in the pending state and sees your 5% slippage. It then jumps ahead of you in line; it affects the execution price, causing your swap to happen at the edge of the 5% tolerance and resulting in you receiving $47,500 worth of tokens (a $2,500 loss due to slippage). This bot then takes the opportunity to buy up a large quantity of those tokens.

Now let's use the playbook.

• You tighten your slippage tolerance to 1% for this token pair after confirming that it has the depth to support it. Upon checking the real executable price, we see there is a substantial gap between the quote and the executable price of $50,000, so we will divide the execution into 5 slices each worth $10,000.
• To ensure the slices are not made publicly available I will route through a protected endpoint.

With the extractible budget cut to approximately 1% and the price impact of each slice being reduced my estimated worst-case loss is around $500 or less which is consistent with observed 2% - 5% savings that resulted from MEV protected routing relative to executing the same trade on DEX. The total loss depends on pool depth and market conditions when orders are actually executed.

If I keep my trade boring it will be the cheapest way to win against a Sandwich Bot; in other words, I will execute a small, private, and compact trade so that there is nothing available to be extracted.

Identifying Toxic Flow Prior to Trading

Certain addresses are known for repeat searches - sandwich operators or sources of toxic flow (people trading with very large amounts). If I can identify the identifiers that each of these address types displays (transaction patterns including types and value of transactions and the timing of the transaction against all other transactions and routing) then I will be able to avoid being in pools or places where they are active.

Wallet level intelligence is key to understanding whether any given wallet meets the criteria that would be consistent with being a searcher or having exhibited toxic flow or behavior in any way. Artificial intelligence scores wallets based on 272 unique criteria which provide me with the ability to view their historical behavior to determine basis for extra caution. By using a DEX scanner I will conduct an executable-price check against current market value on the exchange, and I will use an arbitrage screener that lists the actual spreads at over 80 CEX trading 25 DEX, the goal will always be to create trades where you as a trader have an advantage over a bot. Traders adding automated checks into their workflow can access all necessary data through the API, and the options for different plans are on the pricing page.

FAQ

Is it possible to make a DEX swap completely free from sandwich attacks?
While there is no way to eliminate all chances of a trade being affected by a sandwich attack, you can create a scenario where there is little or no financial incentive for an attacker by using strategies such as limiting slippage, using private routing, and using order splitting before executing the transaction. The goal is to eliminate any possible profit that an automated attacker could earn from the transaction, not to provide protection from attacks.

Is using a private RPC all that better than the public ETH mempool?
Using a private RPC to route your orders will never provide you with any visibility prior to the transaction being created; knowing the transaction value before execution is one of the main factors that allow for sandwich attackers to execute their trades. However, the trade-off to this is your transaction may experience slightly more latency than a trade completed using a public order-flow route. The trade-off of a private RPC is worth the increased risk for larger or sensitive trades; however, for smaller transactions, the trade-off may not be as beneficial.

What is the difference between the reported sandwich attack figures on Solana vs. Ethereum?
For example, according to research done by DEV.to, the estimated dollar amount of extraction attempts due to sandwich attacks for each respective blockchain were as follows: Solana ($45 million/month) vs. Ethereum ($180 million/month). These disparities do not mean that either protocol is safe from sandwich attack; instead the variance is attributable to the amount of value per block, variance in the respective fee markets, and maturity of the searchers on each blockchain.

How does utilizing the set executable price for execution help reduce the likelihood of sandwich attack?
When utilizing the displayed quote for assets (i.e. ETH), it does not accurately represent, in actuality, the true price that you will execute your transaction at when you take your specific size into consideration. By utilizing the set executable price, you can see how your actual transaction size will impact the available liquidity prior to executing the actual transaction. If you see that your transaction size is causing a large gap between the executed price and displayed quote, then you can decide whether to split the order, route it differently, or to wait until the pool is able to temporarily absorb your transaction.

Does splitting orders help mitigate losses in value resulting from being subjected to sandwich attacks?
Generally, but there are limits to the number of slices that you use to execute a transaction. Using less volume will allow increased liquidity, but more transactions will also incur more transaction fees and take longer to execute. Therefore, there may be an increased probability of incurring additional negatives resulting from slippage than from splitting the transaction into smaller volumes. Thus, making certain that your volume does not exceed the liquidity level at the time of making the transaction is critical.

Use ArbitrageScanner free for 1 day; to check your executed price and wallet signals prior to making the transaction via: https://t.me/arbitragescanner_info25_bot

Disclaimers: Important; We are software developers; thus, we do not provide any sort of investment or earnings advice; and we will not tell you where you should put your money; we provide fully manual software; thus, your monetary assets will always remain under your control; we use examples of how past customers profited from arbitrage in the past, you are not guaranteed to repeat the same results; only you and the overall market conditions effect whether/how many earnings you make.