Sandwich Attacks on Uniswap V2

Connecting to Ethereum

Parameters

Tokens to Swap

Select from list
From: To:
Paste ERC20 token contracts
From:
To:
Set your own liquidity pools
Amount Token 1 (TK1):
Amount Token 2 (TK2):
Note: The calculations will not include gas fees.

Pool Content

Amount Token 1:
Amount Token 2:

Transaction

Input Amount (TK 1):

Slippage Tolerance:
0.1%
0.5%
1%
%
Gas Price (Gwei):

Current Price:

Options

Attacker has to pay for gas.
(Not the case when attack is executed by miner or flashbot searcher.)
Display liquidity pools
Generate Sandwich Attack

Liquidity Taker Attack [1]

Attacker Tx1

Pool Content

Amount Token 1:
Amount Token 2:

Swap

Input Amount (TK 1):

Output Amount (TK 2):
_
Update Attack

Victim Tx

Pool Content

Amount Token 1:
Token 1
Amount Token 2:
Token 2

Swap

Input Amount (TK 1):
Output Amount (TK 2):
_

Attacker Tx2

Pool Content

Amount Token 2:
Token 1
Amount Token 1:
Token 2

Swap

Input Amount (TK 2):
_
Output Amount (TK 1):
_

Total

Revenue (TK 1):
Profit (TK 1):

Mitigation by Order Split

Victim output without attack (TK 2):
Victim output with attack (TK 2):
Victim output with order split (TK 2):

Victim output without attack (TK 2) minus gas:
Victim output with attack (TK 2) minus gas:
Victim output with order split (TK 2) minus gas:
Savings (TK 2):

Inputs for order split (TK 1):
Only profitable attacks are being considered. This order split doesn't take potential arbitrage transactions into account.



What is this all about?

The problem: Crypto traders lose millions every month because their transactions are being sandwich-attacked. There are dozens of bots continuously monitoring the mempool to find transactions they can frontrun. So far it was difficult for traders to estimate whether their swaps on decentralized exchanges were susceptible to sandwich attacks or not.

The attack: If a victim swaps asset A for asset B, this will increase the price of A in the respective liquidity pool. Bots spot the victim transaction before it executes. They then release two transactions that surround the victim trade (frontrunning and backrunning it). In their first transaction, 'Attacker Tx1', they swap A for B. After the victim transaction executes, they swap B for A, and make a profit due to the price increase after the victim transaction.
Attackers have to pay an exchange fee (on Uniswap this is 0.3% of the input amount). In case they are not colluding with the miner, they also have to pay for gas. The price difference resulting from a victim transaction is not necessarily large enough for a profitable sandwich attack.

The tool: This tool checks whether a trade on Uniswap can be profitably attacked. If a potential attack is discovered, it suggests how the order can be split such that sandwich attacks are prevented.

The limitations: The tool only takes into account the current content of the respective liquidity pool, as well as the transactions of the attacker and the victim. An independent trade in the opposite direction may be included before the victim transaction, which would change the maximum non-frontrunnable input amount.

The people: This is part of a bachelor thesis written at ETH Zurich. We are doing a lot of things related to sandwich attacks; please reach out if you have any feedback or comments: zuestp[at]ethz.ch We also created a short survey to learn how sandwich-attacks affect DeFi users. It will only take a few minutes and we really appreciate your participation.