Introducing: CashmereLabs’ MEV Strategy
In most of your transactions in a chain, with or without your knowledge, you are faced with MEV attackers which profit from your transaction. At the time of writing, various attacking techniques are present. Some of those techniques are fairly complicated and not widely studied/known. The most popular ones of those are back-running and front-running. In this paper, we study frontrunners who manipulate the slippage of transactions, and we present two countermeasures involving the examination of optimal slippage.
What is happening in MEV?
A typical attack consists of the attacker monitoring the mempool and examining the pending transactions, and continuously making a decision whether if it is possible to profit from the swap based on the minimum amount that the user is happy with. Firstly, the attacker searches for a maximum amount that can be placed in the according order, that does not overflow the user’s slippage. Then, with this value, the attacker creates a sandwich attack simulation by taking the actual pool reserves into account. If the simulation suggests a profit, then the sandwich attack is performed.
How does cashmere goat protect users from MEV attack?
The decentralized exchanges offer predefined slippages which oversimplify the slippage decision. Eventhough the users can specify the slippage they want, they are still exposed to successful attacks which results vast amount of profit. The main reason of this is that “slippage” is dynamic in nature, and is strictly dependent to the pool reserves.
Cashmere goat has solved the strategies of MEV sandwich bots currently working on blockchains, and Cashmere can perform profit simulations from attacks.
By adding the DEX reserves related to the swap transaction sent by Cashmere users and the amount the user wants to trade to the calculation parameters, Cashmere makes reverse-engineering against MEV bots and calculates the optimal slippage that MEV bots cannot profit from.
Simulation example on real transaction
Consider the following concrete case. An 25 ETH order was placed with 0.5% slippage that can be thought sufficiently small, but was attacked successfully. The frontrun bot filled the user’s slippage and sold their ethereum before the user, causing the user to sell their ethereum at a lower price.
FrontRun Bot:
https://etherscan.io/tx/0x73c3150780d6ad37f83c7ebad02c73faa71a043417817741df23593a5600ebce
Victim:
https://etherscan.io/tx/0xf60dfcebc91b78849a1538d3c81faef92960f92f76c5e4390b576b0591b15e57
At this point, we will run the Cashmere MEV simulation on a real transaction;
Here we examine the transaction of the front-run bot, which is the first transaction.
wad = 10.46 (The amount of ETH the MEV bot uses for the attack)
value = 11,908 (The amount of target asset it receives as output)
reserve0 = 4,763,175 (The amount of target asset in liquidity pool)
reserve1 = 4,185 (The amount of ETH in liquidity pool)
After obtaining these parameters, we calculate the initial reserves.
initialReserve0 = 4,763,175 + 11,908 = 4,775,083
initialReserve1 = 4,185 - 10.46 = 4174.54
This transaction is simulated by Cashmere with initial reserves to protect the user.
When we simulate the transaction, CashmereLabs detected that the attack will already be made with maxAmountIn: 10.46 ETH before the transaction occurs.
Cashmere also calculated suggestedSlippage: 0.004 to prevent this attack.
When the suggestedSlippage value is used, the MEV bot will not be able to make a profit and will be disabled.
Our users are protected from such MEV sandwich attacks when they use cashmere.exchange because CashmereLabs pre-simulates sandwich TXs and uses the suggested slippage value.
Simulation Logic
func Slippage(
amountIn, reserveIn, reserveOut float64,
) (float64, float64) {
f := func(step float64) float64 {
ou := GetAmountOut(vars...)
ou -= (ou * step) / 100.
frIn, _ := GetMaxAmountIn(varsX...)
frProfit := ExpectedProfit(varsY...)
return frProfit
}
return GssMin(f, min, max, tol, nil)
}We use Golden Section Search for countermeasures. GSS gives accurate results with 23 iterations with 10e15 tolerance.
Response to an attacker is effectively done by adjusting the slippage accordingly. Start with a slippage, calculate the maximum amount to be placed and the expected profit of the attacker.
Then, choose a direction for the slippage, and check if the expected profit is decreased. Repeat the process until you are happy with the attacker’s expected profit. This is actually an equilibrium point between you and the attacker. We are sure that the attacker will not be happy about it. Thus, you will not be on this kind of attacker’s radar.
The simplified version of the abovementioned search can be done in a sophisticated way with GSS.
Conclusion
To sum up, attackers take advantage of poorly chosen slippage by users. It also seems that decentralized exchanges do not help users, either. This is all roots in the dynamic nature of slippage. We dynamically specify it depending on the pool reserves.
We demonstrate a countermeasure to front-run attacks by mimicking frontrunners and finding an equilibrium by adjusting slippage.
CashmereLabs will be the first application to provide MEV protection on the cross-chain using decentralized liquidities.
