Sandwich attacks are a form of maximal extractable value (MEV) and a persistent cost for DEX traders. Between November 2024 and October 2025, they extracted an estimated $60 million from Ethereum users across 60,000 to 90,000 attacks per month.
THORChain addresses this through an alternative execution model designed to make these attacks unprofitable. Let’s explore how MEV works and how THORChain prevents it.
What Is a Sandwich Attack?
A sandwich attack is a strategy where a bot pays to place one trade immediately before a user's swap and another immediately after it, capturing the price movement the user's own trade creates.
When a trader submits a transaction on a chain like Ethereum, it enters a public waiting area called a mempool. Block builders then select which transactions to include and determine their order within the block.
Because pending transactions can be seen before they're executed, bots can identify large swaps that are likely to move an asset's price. This lets them pay block builders to position their own transactions before (front-running) or after (back-running) the trader's swap, and profit from the resulting price movement.
Front-running occurs when an attacker identifies a pending transaction and submits another one with a higher gas fee, ensuring it's processed first. The attacker aims to benefit from the price movement the original transaction is expected to create.
Back-running occurs when an attacker places a transaction immediately after a large trade. By anticipating how the first transaction will affect the market price, the attacker can trade on the resulting movement.
A sandwich attack combines both strategies. The bot first buys the asset ahead of the user’s transaction, pushing the price higher before the user’s swap executes. The user then trades at a worse price and receives fewer tokens than expected (the loss), while the swap itself creates additional buying pressure and pushes the price up further. The bot immediately sells at the higher price, capturing the difference between its entry and exit prices and extracting value from the user’s trade.
The user doesn't usually see this extraction as a separate fee: tt shows up as worse execution and greater slippage instead while the bot's profit comes directly from the additional price impact imposed on the user.
Example: A pool holds 100 ETH and 350,000 USDC, pricing ETH at 3,500 USDC. A bot spots a pending 10,000 USDC buy and purchases 0.5 ETH for about 1,759 USDC, pushing the price to roughly 3,535 USDC. The user’s swap then returns about 2.75 ETH instead of 2.78 ETH without the attack. After the user’s trade pushes the price higher, the bot sells its 0.5 ETH back for about 1,860 USDC, earning roughly 101 USDC.
Why THORChain Prevents Sandwich Attacks
On THORChain, swaps do not execute based on who pays the most to go first. Every trade goes through the Advanced Swap Queue, which orders swaps by price impact. In simple terms, the trade that moves the pool the most gets priority. That completely changes the economics of a sandwich attack.
When executing a swap on THORChain, fees depend on three parameters: the size of the swap (x), the size of the source pool (X), and the size of the destination pool (Y). While the formula may look complex to non-technical users, the principle is simple: the larger the swap relative to the available liquidity, the higher the fee.
This creates a built-in cost for an attacker. To gain priority over a user, the attacker must submit a trade with greater price impact, which generally means committing more capital and paying a higher fee. For large trades, the capital required can become significant (several millions). For smaller trades, the cost of the attack can quickly exceed the value available to extract. And a simple mathematical simulation can demonstrate the effect.
The example below compares a sandwich attack under a fixed 0.3% fee model with THORChain's slip fee model. The attacker swaps 1,001 RUNE for 8,271.22 ASSET. After the user's transaction executes, the attacker swaps the 8,271.22 ASSET back and receives only 972.48 RUNE, closing the sandwich with a 28.52 RUNE loss. The result is independent of pool size: under the slip fee model, the combined cost of the attacker's entry and exit trades exceeds the value made available by the transaction in between.
Importantly, L1SlipMinBps doesn't change this either. The queue scores each swap on the fee it actually pays, floor included, so priority still tracks the trade's impact on the pool.
Conclusion
Sandwich attacks rely on the ability to pay for transaction priority. THORChain removes that advantage by tying execution priority to price impact and fees to trade size relative to available liquidity.
That changes the economics entirely: getting ahead of a user requires a larger, more expensive trade, while the attacker's entry and exit both incur slip-based costs, making sandwich attacks economically unviable.
In the end, this design benefits swappers by protecting them from the value extraction that can occur on other DEXs and chains.
