A Brand New Sandwich Bot That Could Empty LP’s Wallet - EigenPhi

Photo by Michael Dziedzic on Unsplash

Here’s a sandwich trade from a genius. In the eyes of MEV searchers, this brilliant new strategy conducts risk-free arbitrage against the change in AMM’s swapping slippage. But in the eyes of the LPs, this may be a new attack vector enough to raise the alarm. LPs should carefully set checkpoint thresholds to avoid losing against such kinds of sandwich bots.

On November 4, 2022, EigenPhi detected a BRAND NEW type of sandwich transaction: a sandwich bot squeezed an add-liquidity transaction, which is weird according to our shared knowledge. Is it profitable to do so? Are there any restrictions? Unlike the previous article on a HUGE sandwich trade, including 37 transactions, this bot shows a rather different and innovative strategy. And this article will take you to find out how DANGEROUS the current situation of AMM’s LPs is.

A Summary and Token Flow Chart

From this trade, the sandwich bot got a revenue of 0.922832 WETH. After subtracting the gas costs of both front-run and back-run transactions, the remaining profit was about 0.023346 WETH. The bot achieved a perfect risk-free arbitrage in a bundle of transactions without risk exposure to assets other than WETH.

Trading Steps

Front-run Tx: The sandwich bot’s from address called its contract (to address) and swapped 21.477791967255461888 WETH to 458,875.769333569771126592 SYC through Uniswap V2: SYC 6.
Middle Tx: Someone added 15 WETH and 231,712.963735470964309251 SYC to the pool contract, Uniswap V2: SYC 6, and got 1,792.628826087529628699 UNI-V2 as a voucher. We call it a middle Liquidity Provider (LP) as follows.
**Back-run Tx: **The sandwich bot swapped 458,875.769333569771126592 SYC, as obtained in the front-run transaction, back to 22.400624171075764224 WETH.

The following figure shows the token flow graphs of each transaction.

A Quantitative Analysis of This Strategy

Why can the sandwich bot make a profit from an adding liquidity transaction? Where exactly does its revenue come from? Is it earning the maximum possible revenue? Who are the victims?

Next, we provide a detailed analysis of this strategy. And you will see that all liquidity providers of this pool bear the most loss compared to the pinched transaction’s user. What’s more interesting is that the sandwich bot may be possible to self-direct this trade without a strict prerequisite.

Constants and Variables

Firstly, we list the constants and variables needed to calculate the revenue of the sandwich bot. As shown in the following table, we use a bunch of characters to denote the parameters corresponding to the pool’s status before, during, and after the sandwich trade. For each character, we use subscripts to represent the corresponding time and superscripts to represent the corresponding token. In this case, token0 means SYC, and token1 means WETH.

Here is the Previous Swap in the table.

Several constants are needed to conduct the calculation, and we can fetch them from event logs and transaction data. To understand the calculation logic here, you may require some background knowledge related to Uniswap V2’s and its Router’s contracts. For example, the logic in functions such as swap() and addLiquidity().

Constraints

Secondly, there are also some constraints that the sandwich bot should obey.

Optimization Problem

Now we focus on the optimization problem. Given the liquidity pool’s initial status and the relative constant parameters, we formulate an attack vector into a constrained optimization problem concerning all the parameters defined.

We can tackle this problem by utilizing either the analytical method or simulation.

Victims In the Dark

Essentially, the bot’s revenue comes from a change in the slippage faced by a swap transaction with the same volume before and after adding liquidity. In other words, it is a risk-free arbitrage against the change in slippage. What about the LPs as counterparties? What are their PnL?

Based on the previous analysis, we continue calculating LP’s profit and loss in this trade. We consider two cases and define parameters as listed below.

Simulation Results

Case 1:

The lower right panel in the above figure shows that the parameters set by the sandwich bot correspond to the maximal loss other LPs bear.

Besides that, we can also find that beyond this threshold, the bot’s revenue comes mainly from the loss of the middle LP, and as more WETH is put into the pool by the bot, other LPs’ swap fee revenue will exceed their loss.

From this point of view, the reversion checkpoint set by the middle LP provides critical protection.

Moreover, the reversion checkpoint set by the middle LP cleverly coincides with the threshold corresponding to the maximum loss of other LPs. One wonders if this is a self-directed sandwich transaction; at least, it is far from being a loser**. **A sandwich bot can initiate both a sandwich transaction and an add-liquidity transaction, provided that the total p&l is guaranteed positive.

From the lower left panel, it seems that the middle LP might even be able to profit from this trade under specific parameter settings, which is worth a careful check.

Case 2:

If we suppose the middle LP is a separate individual ignorant of the sandwich bot, we should calculate its designated principal in another way. And the resulting PnL of the three kinds of participant is shown in the following figure.

In this case, the initial parameter set by the sandwich bot no longer corresponds to the maximum loss of other LPs, and the transaction will be reverted if it were true.

Case 1 is more likely to be consistent with the sandwich bot’s strategy.

To simplify the analysis, none of the above calculations takes into account the actual cost of Gas fees paid by the bot, and the conclusion does not change because of this.

Will a Self-directed Sandwich Trade Make Money?

There are more things to think about and learn from this case. For example,

Which kind of pool is suitable for making similar trades?
Can a sandwich bot implement the strategy without a third party initiating an add-liquidity transaction?

A Case-Specific Inference

Finding the answers to the above questions requires one to generalize the model in this article. Before doing a systematic study, we can conduct a brief counterfactual inference to get a sense.

Considering the revenue and profit out of the front-run and back-run transactions are 0.922832 WETH and 0.023346 WETH, respectively, we can conclude that the sandwich bot cannot profit by mocking the middle LP.

Simulation Model

One might ask, does this strategy depend on the pool and its state? Solving this question would require a generalized model and systematic learning. We first give an analytical framework here and share a more profound study in future reports.

We list the effects of these six steps on pool in the following table.

Conclusion

We highlight the key insights obtained from this case:

A sandwich bot made a surplus of nearly 1 WETH by sandwiching an add-liquidity transaction in Uniswap V2’s SYC-WETH pool. The validator got most of its revenue through gas fees.
The new strategy can be regarded as a risk-free arbitrage against the change in slippage before and after adding liquidity to the pool.
Compared to the middle LP, other LPs bear much more loss in this case. The parameters set by the sandwich bot and the checkpoint constraints imposed by the middle LP cleverly coincide with the threshold corresponding to the maximum loss of other LPs.
LPs should carefully set checkpoint thresholds, such as the minimum liquidity to be added when issuing an add-liquidity transaction. Otherwise, they may bear a complete loss by such a kind of sandwich bot.
From our preliminary analysis, a bot cannot self-direct the entire trading steps without waiting for a third party’s add-liquidity transaction. But one needs to check this with a more systematic model.
And the strategy is quite sensitive to the pool’s initial status, and the bot must adjust its parameters to a specific range to get the most surplus from other LPs.