🥪$215k Lost In One Swap! How Does A Sandwich Attack Happen?
If you have been spending time in the web3 space, you have probably heard about malicious actors and events that happen regularly in the industry. One week ago, one of these events took over Twitter since it was reported that an Ethereum user lost approximately $215k in just one swap.
Main web3 outlets such as Cointelegraph classified it as a Sandwich Attack. While I have doubts about the accuracy of the Cointelegraph report, which we won’t discuss here, I wanted to take advantage of the situation to explain how this type of attack happens.
Put simply, a Sandwich Attack occurs when a malicious user executes two instantaneous transactions, placing them before and after the victim’s transaction. This type of attack occurs frequently on DEX platforms because the attacker is waiting for a swap with a tiny slippage to execute. So, you may wonder why it happens in a short timeframe or how it is possible.
This article aims to go through the following aspects of a Sandwich Attack:
🔸How a Sandwich Attack happens (actors and process)
🔸How to avoid a Sandwich Attack
This analysis doesn’t intend to go in-depth but to give you a general idea and help you to prevent it. If you want to dig deeper, go to the end of this article and you’ll find your way to a deeper analysis.
Sandwich Attack (DEX Risk): Step-By-Step Guide
To understand how a Sandwich Attack occurs, we need to know the participants in a transaction and the process.
Who Are The Participants In A Sandwich Attack?
🔸User (victim)
🔸Validators
🔸Node Runners
🔸Block Builders
🔸Block Proposers
🔸MEV Searchers
🔸Attacker / Bot
This Is How They Sandwich-Attack You
1)Choosing Tokens: The victim chooses two tokens to swap in an exchange setting a slippage at 0.1%. The Telegraph report provides an example: The supposed victim wanted USDT in exchange for USDC.
If you don’t understand why someone would exchange stables, one reason is that USDT tends to be more liquid on-chain and, therefore, could have better exchange rates.
2) Transaction Construction: The wallet processes the swap into a transaction as in the example below.
to: DEX contract address
data: Swap parameters like amountOutMin
This fetches the to address (of the DEX smart contract you are interacting with) and encodes the data field. So the data field is encoded with a function selector like swapExactTokensForTokens and parameters like amountOutMin.
You are basically telling the smart contract to “swap even if the amount I will receive is minimum”.
3) Transaction Broadcast: After being sent to the Ethereum network, it enters the mempool. The problem here is that attackers can see all the transactions in the mempool.
At this point, you may wonder why it is publicly visible and if it would be a good idea to replace it with a private one.
Mempools are publicly visible as a form of transparency and decentralization. If mempool were private, the chain would need intermediaries to manage the transaction flow. This is why it would defeat decentralization.
4) MEV Bot Detector: The bot or attacker detects the vulnerable transaction. At this point, the bot makes several calculations in fractions of a second since this bot attacks multiple potential victims to obtain the maximum profit.
5) Block Building: Block builders assemble transactions into a block. This is when front runs (the bot buys the asset before the victim does) and back runs (the bot sells the asset right after) happen.
Since blocks in the Ethereum network are created every 12 seconds, the attack tends to be confirmed in approximately that timeframe, but it is set in fractions of seconds, if not within a few seconds.
6) Block Proposal: The validator selects the most profitable block from builders. Validators earn rewards from block fees + MEV. Therefore, the block and the attack are confirmed after validator approval.
7) Block Execution: The block is added to the blockchain and the victim’s swap has been executed.
This process is too theoretical and you may need a tool to understand better how things work. Let’s see if what I will tell you next will interest you.
Sandwich Attack Simulator: Upcoming
The first time I realized a Sandwich Attack existed, I thought it was diabolical but smart. I wondered then how often I had been sandwich-attacked without noticing it since I had been frequently swapping small amounts and a few times medium-sized amounts.
I wondered if small amounts were a profitable target for a bot and what the supposed profit margin they could have was.
Please don’t lose hope, I know it sounds hopeless but I have a solution! I am currently crafting a Sandwich Attack Simulator to help you prevent it, and it will be totally free!
I will post it soon in an upcoming Substack article. I have a sneak peek of the tool. Take into consideration that the simulator is only for educational purposes.
Until the final version is finished, let’s explore how you should avoid a Sandwich Attack for now since practical solutions are available.
Ethereum Security: What To Do To Avoid A Sandwich Attack?
Sandwich attacks have existed for some time, and many of us have learned to cope with them while taking precautions. Here are ways to minimize the risk.
🔸Use anti-MEV wallets like Metamask or Coinbase Wallet to enable the Flashbot Protection feature.
🔸Use private RPCs even if it goes against the decentralization ethos because they don’t send your transaction to a public mempool but directly to block builders.
🔸Use DEX aggregators like 1inch or Matcha which search rates across the most liquid exchanges.
🔸Consult the liquidity of every exchange you’ll use.
🔸Set a slippage between 3 and 5% since it will complicate the bot’s work to predict margins to manipulate the price and execute a Sandwich Attack.
The best option is to use all these recommendations at the same time.
If you aren’t careful, it can happen to you just like the user reported, even if the story could have been different, and instead of a Sandwich Attack, the user experienced high exchange rates due to a lack of liquidity in the decentralized exchange.
Conclusion
The Ethereum Network is working to prevent such events. Some of the most discussed solutions are the Proposer-Builder Separation, Encrypted Mempools, MEV-Boost Middleware, and Threshold Encryption.
These proposals aim to protect users by minimizing losses instead of completely eradicating the Sandwich Attack since no one wants to compromise blockchain principles.
Have you ever been sandwich-attacked? ✅ Yes ❌ No
🙋♂️Hey, the Sandwich Attack Simulator will be released in my first Substack article where I will dive deeper into the Sandwich Attack concept. Stay tuned!👇
