Research Summary: Analyzing and Preventing Sandwich Attacks in Ethereum

TLDR

  • Token trades on decentralized exchanges can change an asset’s market price. Bots generate a profit by frontrunning these trades, buying the asset for a low price, and then selling it for a high price.
  • In this work, we present an analysis of such sandwich attacks for twelve months. During this time there were at least 480’276 attacks in Ethereum leading to an accumulated profit of 190 million USD.
  • By splitting frontrunnable trades into multiple transactions, traders could have saved more than 90 million USD. We present a tool that helps them find an ideal order split.

Core Research Question

How common are sandwich attacks in Ethereum and is there a way to prevent them?

Citation

Züst, P. (2021). Analyzing and Preventing Sandwich Attacks in Ethereum

Link

Background

  • Decentralized Finance (DeFi): A set of finance-focused blockchain protocols that enable users, among other things, to take out loans or exchange tokens.
  • Decentralized Exchange (DEX): Allows users to trade crypto tokens without the involvement of a central intermediary.
  • Constant Product Automated Market Maker (AMM): Currently the most widely used implementation of a decentralized exchange. The basic idea is to keep token funds in liquidity pools. Traders are then able to swap tokens in a pool, as long as the product of the token amounts is constant before and after the swap.
  • Uniswap: One of the most popular decentralized exchanges. More than 3 billion USD in token value locked and the basis for other exchanges like SushiSwap or PancakeSwap.
  • Network Fees: Incentive for miners to include a given transaction in a block. Needs to be paid for every Ethereum transaction. Amount depends on the computational complexity of the transaction, as well as the chosen gas price.
  • Exchange Fees: Cost of using an exchange. On Uniswap it’s 0.3% of the input amount of a swap.
  • Slippage Tolerance: Token prices can be volatile. The slippage tolerance indicates the maximum price increase a trader is willing to accept in a given token swap.
  • Mempool: Nodes store pending transactions locally in the mempool before they are included in the blockchain. The time a transaction is pending depends on the chosen gas price and the available block space.
  • Transaction Ordering: When assembling a new block, miners are free to select any transactions from the mempool and arrange them in any order. The traditional strategy is to include the transactions with the highest gas prices in descending order, but there is no requirement to do so.
  • Frontrunning: When an attacker observes a pending transaction, they can broadcast a new transaction with a slightly higher gas price. If a miner orders transactions strictly according to the gas price, the attacker’s transaction will be executed right before the original transaction. This mechanism has been studied in traditional markets for decades and is usually prevented by regulation.
  • Backrunning: Same principle as frontrunning, but the attacker chooses a slightly lower gas price. This is how they try to ensure that their transaction is executed right after the victim transaction.
  • Miner Extractable Value (MEV): Since miners have full control over how they arrange transactions, profit through frontrunning is considered miner extractable value (MEV). This term refers to the value that miners can generate by adding new transactions to a block or favorably ordering pending transactions.
  • Sandwich Attacks: A swap on a decentralized exchange can lead to a significant boost of an asset’s market price. Attackers continuously monitor the mempool to find a transaction that entails large price differences. They then release a frontrunning transaction to buy the given asset, and a backrunning transaction to sell it for an increased price.
  • Proxy Contracts: Transactions in a sandwich attack are typically sent to a proxy contract instead of a router offered by the exchange. This allows attackers to check whether the respective liquidity pools still hold the expected amount of tokens before executing the swap. If this is not the case and an attack would not be profitable, the swap can easily be canceled.
  • Flashbots: A software project which allows users to submit suggestions for block compositions directly to miners. This turns MEV extraction from a central process into an open market where bots continuously search for the most lucrative way to assemble a block with pending mempool transactions.

Summary

  • Bots continuously scan pending Ethereum transactions and employ different tactics to profitably frontrun them. A common type of frontrunning is the so-called sandwich attack.
  • We created a large-scale analysis of sandwich attacks for a period of twelve months. During this time there were at least 480’276 attacks on AMM DEXes in Ethereum leading to an accumulated profit of 190 million USD for attackers.
  • Our paper also shows that miners have recently begun to play a more active role in these value extractions which drastically changes the patterns we observe for sandwich attacks.
  • Splitting up frontrunnable trades can be a valid mitigation strategy. We explain how traders could have saved 90 million USD by releasing multiple smaller swaps instead of one large trade.
  • A public tool to check whether a transaction is susceptible to sandwich attacks and to find a suitable order split was released on www.DeFi-Sandwi.ch.
  • Finally, we initiated a survey to understand how users perceive sandwich attacks and what mitigation strategies they know. While all participants had a clear understanding of the attack, most of them didn’t know how common they were nor how they could be prevented.

Method

  • We first provide some mathematical background to understand how a token swap affects an asset’s market price, and how the profitability of a sandwich attack is determined.
  • The paper then describes the heuristics used to classify sandwich attacks. The approach differs from related work, as it mainly focuses on the input and output amounts instead of the sender addresses.
  • Next, we outline the structure of our data analysis. We used a modified Geth client to export all receipts of Ethereum transactions from May ‘20 to May ‘21. This dataset was filtered to only include receipts where a swap event was emitted. We then look for two transactions fulfilling the given heuristics for a sandwich attack.
  • The discovered attacks were further analyzed, allowing us to learn more about the strategy attackers used, the profit they generated, and the sandwich opportunities they missed. A special emphasis is put on sandwich attacks which are executed in collaboration with miners.
  • After describing the current state of sandwich attacks in Ethereum, the paper suggests a method for traders to prevent being attacked: By splitting a token swap into multiple transactions, a sandwich attack becomes unprofitable. We introduce the mathematical concepts to find an ideal order split.
  • A web interface was developed which enables traders to check whether a given trade is susceptible to sandwich attacks. If this is the case, the tool suggests an ideal order split. We use backtesting to quantify how much money traders would have saved by using this trading strategy.
  • Finally, we present our findings from a user study around the perception of sandwich attacks.

Results

  • Number of Attacks

    In the given period, we analyzed 2’367’980 blocks using specific heuristics. In total, we discovered 480’276 sandwich attacks. The graph above shows how sandwich attacks became much more common over time.
  • Involved Token Pools
    Overall, the sandwich attacks we discovered made use of 5387 different ERC-20 tokens. The most popular pair was ETH-YELD which was attacked 3498 times. Around 55% of the involved token pools were attacked ten times or less.
  • Proxy Contracts
    We found 964 different proxy contracts that received at least one attack transaction. Attackers appear to switch their proxies frequently, as a contract is only in use for two weeks on average (90’913 blocks). The most active proxy contract processed 51’475 of the attack transactions we discovered (5.36%).
  • Profitability
    To make statements about the profitability of attacks, we focus on transactions where at least one of the two involved tokens is ETH (which is the case for 96.28% of attacks).
    • Accumulated Profit

      The accumulated profit over time can be seen above. The profit started increasing rapidly in July 2020. This coincides with the total number of sandwich attacks we are observing. Although the number of attacks stayed high through fall 2020, the profitability of the individual attacks decreased, most probably because of increased competition. The surge of profit at the beginning of 2021 could be connected to attackers collaborating with miners. In total, attackers earned 64’217 ETH (189’311’716 USD) in the given timespan. This also includes unprofitable attacks which constitute 18.14% of all attacks. If unprofitable attacks were excluded, the profit would amass to 73’337 ETH (216’197’476 USD).
    • Maximizing Profit
      Our analysis showed that attackers almost always achieve the maximum possible profit, i.e. they choose an ideal input amount for the buy transaction and push the price to its limit. The minimum output and the actual output of the victim transaction differed by less than 1% on average.
    • Most Profitable
      The most profitable attack with a single victim transaction occurred on Feb 17, 2021 on Uniswap V2: A known sandwich bot released the respective frontrunning and backrunning transactions, netting a profit of 39.17 ETH (100’626 USD) in a single attack.
    • Least Profitable
      The ten most unprofitable attacks all happened on Dec 19, 2020, and seem to stem from a misconfiguration of an attacker. They lost at least 219 ETH (645’612 USD) in less than 90 minutes.
  • Allowed Unexpected Price Slippage

    The figure shows how the selected slippage rates are distributed. Especially the share of transactions with a slippage tolerance of more than 10% is notable. The official Uniswap V2 interface suggests values between 0.1% and 1%.
  • Active Reordering by Miners

    We consider a sandwich attack to be in collaboration with a miner if the gas prices of the frontrunning and backrunning transactions are both at most 1 Gwei. There was a surge of such attacks since the beginning of 2021. This timing coincides with the release of the Flashbots project. The table shows how increased control over the block order leads to a surge of profitability for sandwich attacks.
  • Unused Sandwich Opportunities

    In total, we found 3’612’343 swaps with ETH as input token that could have been profitably attacked, but were not. The diagram shows how the share of unused sandwich opportunities declined over time. The largest missed opportunity for a sandwich attack could have earned an attacker 724 ETH (2’134’352 USD). It is likely that some of these transactions were never broadcast to a public mempool.
  • Backtesting Order Splits
    To analyze the effectiveness of order splits as a mitigation strategy, we made a selection of 226’905 profitable sandwich attacks. The analysis showed that 160’347 (70.67%) of these attacks could have been prevented if a suitable order split had been used. In these transactions alone, traders lost 42’504 ETH (125’301’792 USD). Applying the order split strategy would have saved them 30’525 ETH (89’987’700 USD).
  • User Perception of Sandwich Attacks

    To conclude our study, we conducted a survey with experts of the Ethereum community. While almost all participants agree that DeFi users can be negatively impacted by sandwich attacks, a clear minority considers the attacks immoral. Two people even brought up the point that sandwich bots should not be considered attackers.

Discussion and Key Takeaways

  • Data Analysis: We used block analysis to investigate sandwich attacks on decentralized exchanges in Ethereum. Compared to related work, we apply heuristics better suited for the current DeFi environment and present more recent and extensive data.
  • Order Splits: We established order splitting as a mitigation strategy in a theoretical framework, verified its effectiveness using backtesting, and created a public tool that suggests ideal order splits for given trades.
  • User Perception: Our user study showed the large information gaps around sandwich attacks and confirmed the need for continued research in that area.

Implications and Follow-ups

  • The paper suggests that in the future every profitable frontrunning opportunity will be used, potentially harming traders and challenging the current architecture of decentralized exchanges.
  • Our work also shows that the number of sandwich attacks executed in collaboration with miners is rapidly increasing. It can be assumed that, in the long run, all profit generated through sandwich attacks will be made by - or shared with - miners.
  • Projects like Flashbots enable frontrunning bots to directly influence the transaction order in a block. This allows for attack schemes far more sophisticated than the sandwich trades highlighted in our paper, potentially leading to a steep increase in MEV extraction.
  • There are large information asymmetries around frontrunning. Whether or not sandwich attacks are immoral is a controversial topic. As frontrunning becomes more prevalent, the Ethereum community will have to think about what this new paradigm means for the platform.
  • We are currently adapting the given report for publication in a scientific journal. It will be extended to include an additional user study focussing on the perception of sandwich attacks.
  • The Ethereum platform and the DeFi ecosystem are undergoing rapid changes. Extending the block analysis for a longer period will reveal how sandwich attacks are influenced by different factors, like Ethereum’s switch to proof of stake, the release of Uniswap V3, or the continuous proliferation of the Flashbots project.
  • The tool we built is a research prototype and there are several possibilities to make it more user-friendly. Apart from improving the design, it could be extended by including multiple exchanges, or functionality that lets users directly sign and broadcast the suggested order split transactions.

Applicability

  • We released a web interface on www.DeFi-Sandwi.ch which is based on the mathematical principles presented in the paper. Users can check whether a given trade on Uniswap V2 can be sandwich attacked. They see how the input amount, slippage tolerance, and transaction fee impact the profitability of the attack. The tool also suggests an ideal order split, such that sandwich attacks won’t be profitable anymore.
  • Various services were developed which allow users to submit transactions directly to a miner. Using these private mempools, traders can circumvent the risk of being sandwich attacked. Examples include the Taichi network and 1inch’s Private Transactions.
  • The growing number of sandwich attacks also led to the development of new decentralized exchanges. They are tailored to an Ethereum network where frontrunning is not an exception, but the norm. Archer Swap, Mistx, Cowswap, and Swapswap were all built with MEV extraction in mind. They use different approaches to share profits generated through frontrunning with traders.
  • As users become more aware of sandwich trades, they want to know whether they were ever attacked. Sandwiched.wtf is a tool that lets users check whether they ever fell victim to such an attack.
11 Likes

It’s a wonderful summary and a very nice tool! @PatrickZuest
I have a question about the backtesting transaction. Was sent directly to the router of an exchange data source? Because if the first router of the price is different from the second access to the router, then it would need to recalculate result.

4 Likes

@PatrickZuest you mentioned in 4.3.3 that although you’ve seen hundreds of unique users on good days, you have not found any traces of these trades or the suggested order splits in the actual blockchain.

I’m curious about the details of how you are matching unique users and their traces of order splits?

My wild guess is that you would collect their input at your website, and see if any transaction taking place shortly afterward did a split that matches the advice you gave online.

If it’s that case, how do you deal with the following scenarios which could lead to these errors:

Alice, after learning about the risks from your website, ended up not trading with any pool at all (Type II error).

Bob, after taking your advice, decided to do small transactions. However, the actual transaction amount was different from what he fed to the website (Type II error).

And once you do observe someone taking the advice:

Someone didn’t visit your site but made a split that matches a data entry collected from Alice, Bob, or someone else (Type I error).

Just as importantly, thank you for the research, website, and wonderful summary.

2 Likes

Hi @Sean1992076 - thanks for the nice words and your excellent question!
This is a good point and we solved it like this: At first, we are checking the original token amounts in the liquidity pool. When we simulate a transaction, we also simulate the change of tokens in the respective pool (because every swap can have an impact on the relative token prize). We hence only need to check the pool content once, but each transaction’s impact on the liquidity pool is taken into account. Hope this makes sense!

2 Likes

These are great questions and I appreciate your feedback, @Twan
We logged the input data as well as the suggested order split amounts on the website. And you guessed right - we tried to match our suggested order splits with input amounts observed on chain (+/- some margin).

Let’s distinguish the specific scenarios you asked about:
Alice, after learning about the risks from your website, ended up not trading with any pool at all
Using our analysis, we can’t tell whether this happened or not. However, Alice didn’t actually use the order split our tool suggested, so I wouldn’t consider it an error.

Bob, after taking your advice, decided to do small transactions. However, the actual transaction amount was different from what he fed to the website
Even if the total input amount is different, the first split transaction would be the same. You can think of that number as the largest input amount that you can trade without being sandwich-attacked. In our analysis, a match on the input amount of the first split transaction would have been identified already. However, we couldn’t find any ‘ideal’ input amounts on-chain.

Someone didn’t visit your site but made a split that matches a data entry collected from Alice, Bob, or someone else.
We (unfortunately) didn’t have to think about that scenario, since we didn’t find any matches. If we had found matching entries, we probably would have compared the timestamps of our logs on the website with the actual execution of a transaction in the blockchain. There is of course no way to make conclusions with absolute certainty, but if an order split was suggested shortly before the transaction was executed (and if even the total input amount matches), it would at least be a strong indication that our website was used.

I hope this clarifies things a bit. It would be interesting to redo the analysis now, as the awareness of sandwich attacks (and of our tool) increased quite a bit since the publication of the thesis.

3 Likes

@PatrickZuest Thank you for your wonderful summary and tool. I’m looking forward to the result of the redo as well. I wonder how do Uniswap V3 and Ethereum 3.0 affect the applicability of the tool? Did you do or expect to do any adjustments for it to gear to the environmental change? Thanks!

2 Likes

Happy to hear that you liked the summary, @Astrid_CH
And thanks for bringing up these questions: Our tool currently only works for Uniswap V2. In V3, calculating the output amount of a swap is far more complicated than on V2: The liquidity can be concentrated on certain price ranges which means that we cannot directly calculate the results of the swap, but would have to simulate it. So far, we haven’t made the necessary adjustments for the tool to work on Uniswap V3. If there is enough interest in the community, that might be something to consider.

The upgrade of Ethereum itself won’t affect the applicability of the tool, as the underlying smart contracts stay the same. However, it might have an impact on the way MEV is extracted. Flashbots wrote a blog post about MEV on ETH2 which you could also find interesting.

4 Likes

That’s really interesting and worth studying. @PatrickZuest, thank you for answering the questions and sharing the blog post.

1 Like

Excellent summary @PatrickZuest!

Great to see so many excellent questions popping up.

My question relates to the mechanism you devised to mitigate sandwich attacks, whereby a swap is split into many orders. In the case of sandwich attacks, you were able to show how an optimal order split drastically decreases the profitability of an attack.

What is interesting to me is that there appear to be additional benefits in splitting CFMM orders beyond sandwich attack mitigation. A couple of months ago, we had a great discussion with @tarun on the privacy properties of popular CFMMs, such as Uniswap.

His publication introduced the idea of using order splits to improve the privacy of CFMM users. They propose a model which samples order splits for every swap using a Dirichlet distribution. This makes it incredibly difficult to associate a set of swaps to a single blockchain pseudonym, thereby increasing privacy.

Although this is a very different model than what you have devised, I wonder if there is a way to potentially combine the two and build a quasi Order Management System for CFMMs that can offer both privacy and sandwich attack mitigation.

Is this something you have considered before?

2 Likes

@PatrickZuest – Thanks for this very well-written summary of your research, which shows that during a twelve-month investigation there were “at least 480,276 attacks leading to an accumulated profit of 64,217 ETH (189,311,716 USD).”

Given the huge toll taken on the community at large, I was particularly struck by the “User Perception” section of your paper, in which you state that:

• Despite considerable effort, it was difficult to find traders who were aware of sandwich attacks and willing to fill out a survey.
• Despite clear agreement that DeFi users and the Ethereum platform were negatively impacted by sandwich attacks, a clear majority also felt that these attacks were not immoral.
• That even experts are unsure about the actual impact and frequency of sandwich attacks.

How do you account for this seemingly irrational reaction to the clear facts of overt dishonesty and corruption plaguing the DeFi community?

1 Like

Thanks for the feedback, @cipherix. I agree – it’s great to see so many smart discussions and questions in this thread.

That’s a very interesting idea which I haven’t considered before. As @tarun mentioned, our tool currently suggests a deterministic split which does not help users in terms of privacy. (In fact, it might make it even easier to associate different swaps to a pseudonym.) But it seems like there is definitely potential to combine the two ideas: If trades are split up anyway, why not do it in a privacy-protecting way? Would be interesting to include a functionality in a future version of our tool which takes these findings into account. I need to have a closer look at the math they use, but will keep you posted.

2 Likes

Thanks for bringing up the user survey, @rlombreglia. So far the focus in this thread was mainly on our quantitative analysis, but I agree that it’s important to also consider the perception of users.

In order to understand their reaction, it is important to consider the time our survey was conducted. As prices were highly volatile, most users were not too concerned about receiving slightly fewer tokens from a trade than expected. This would have probably been different if prices were more stable. We also noticed that many DeFi traders had a lack of understanding (and also a lack of interest) regarding the detailed functionalities of decentralized exchanges. We were curious to learn more and extended our work in that area. Among other things, we conducted several qualitative interviews and a workshop on Clubhouse. A respective paper is currently under review for publication, and I will post it here, as soon as it is out.

Whether or not these attacks are dishonest is a difficult question. When users set a slippage tolerance for their trade, they agree to swap tokens for a given price. Most users, however, are not aware that other factors than natural price fluctuations can have an impact on their swap.

My personal opinion is also split: These attacks definitely won’t help attracting new users to the DeFi world. It should be easy and safe to swap tokens on a DeX, even for non-technical users. However, I also believe that there are examples of dishonesty and corruption in the DeFi world far worse than what we describe. Regular arbitrage trades are not too different from sandwich attacks.

2 Likes

Thanks for your answer, @PatrickZuest. You’ve helped expand my understanding of the issues.

1 Like

It’s an excellent summary

@Mehrdad_Khosravi was there anything in particular in Patrick’s summary that was particularly useful or interesting to you? We like to use the comments section for discussing scientific research and industrial applications of scientific research, so we’d love to get your input.

1 Like

This is a great analysis of your research and a great explanation of the logic behind the methodology. I am curious to know if there is a failure rate associated with the separated ordered transactions either due to gas fees not staying the same during the attempted execution or sandwich attacks occurring on transactions that are just large enough to flag bots?

This type of tool could be extremely useful for solving many aspects of network congestion from the user side, so that is what makes me want to know the success rate of the transactions that get broken up and if there is an upper limit on how much can be transacted before bots get flagged.

2 Likes

This is very interesting @PatrickZuest! I might have missed it, but did you release your code anywhere on Github or anything like that?

1 Like