Sandwich bot attack on DeFi in Tezos

Hello world! Some time ago, we discovered the appearance of Sandwich bots in Tezos, which interfere and slightly profit from DeFi and 3Route users. Here is a list of contracts that currently carry out malicious activity https://tzkt.io/tz1cHdLXcXmHF163J2ZPB951wer6Eg6327Sx/contracts

“Sandwich” (or sandwich attack) is a malicious use of DeFi (mainly DEXes) tools in order to make a profit. Sandwich bots are not a new, but quite relevant problem lately, and therefore we think it's worth telling users about it.

What is a sandwich attack?

A sandwich attack allows an attacker to profit by worsening the victim's trading conditions using a trade slippage setting. Algorithms called sandwich bots track the mempool of operations in search of a possible victim.

A mempool is a list of transactions that have not yet been executed, and can be executed later. In simple words, this is a queue of requests for adding transactions to the blockchain. In the blockchain, as a rule, the mempool is open, which means all network users can view it. That's what malicious bots do when they're looking for the right query for their machinations.

What's the point: when we create an exchange order, we have some market price as well as a possible slippage, that is, an acceptable deviation from the market price. It is needed to allow the user to buy the required volume of tokens at a price slightly worse than the stated price in case of worsening conditions at the time of the transaction.


Typically, for such an attack, an exchange order with a sufficiently large value of slippage should appear in the mempool. As soon as one is found, the sandwich bot tries to execute its exchange order in the same direction, before the victim's one, thereby worsening the price at which the victim's order is executed for the slippage specified by the victim. Thus, the sandwich bot frontruns (outstrips) the victim's order and executes the transaction first, and the victim gets a less favorable deal.

Right after the victim's transaction, the bot creates a reverse transaction and returns the price to a balanced state with this second transaction. As a result, the victim makes a transaction at a less favorable price, and the attacker gets the difference between the buying and selling of the token. This is approximately equal to the victim's transaction volume multiplied by the slippage, minus the network and DEX commission.


The bot makes both transactions in the same block together with the victim's transaction.

Why is this happening?

The algorithms of the blockchain node perform operations based on priority. The protocol (node) collects all operations and distributes them into a queue depending on the weighted commission (Sum Fee / Gas limit) that the user sets himself when confirming the transaction, or the DeFi does it for him). If user A places an order with a higher Fee than user B, then A will end up in the queue with a higher priority than B. This maneuver is called "front-running".

In this block you can see an example of this attack, which made the bot a profit of 0.5 Tez https://tzkt.io/4072342/operations



Sandwich attacks are not always successful

There is one feature in Tezos that sometimes when trying to make a Sandwich attack, the bot changes the parameters of the Token's storage so that it simply does not allow the victim's transaction to be executed due to the lack of the declared Storage for the transaction. As a result, the bot trades, and the user fails. So, the bot just gets a loss instead of a profit. An example can be found here https://tzkt.io/4063229/operations



How to fully exclude Sandwich attacks

Soon we will release the execution protocol via 3Route without any slippage with the help of Limit Orders. We'll post about this later, just stay in touch!

PS: Appeal to those who use Sandwich bots

As we have shown above, there are cases when an attacker will suffer losses and at the same time will not allow the user order to be fulfilled. No one has a profit from such an action, but on the contrary, the attacker has losses. Also, an unexpected event may occur with the victim's transaction and it will fail at the last moment and the attacker will also suffer losses.

So we strongly do not recommend the use of such attacks in Tezos. It's never worth it ;)

An error has occurred. This application may no longer respond until reloaded.