Analysis of the MEV bot attack on Alpha Homora

The cross-chain DeFi protocol Alpha Finance Labs stated that historically a total of 20 addresses lost 40.93 ETH while using the leveraged mining protocol Alpha Homora V2, because their transactions were discovered by MEV bots.

And as Defi trading continues to grow, MEV bots are becoming more and more common, and many users are being arbitraged by MEV without realizing it. Thus we need to understand how MEV arbitrages and more importantly, what MEV really is.

Firstly, let’s have a look at what MEV is.

As we all know, Ethereum miners can package transactions and generate blocks, and can also include transactions, exclude them, sort them within the blocks they generate. In addition to transaction fees and block rewards, miners can extract more value through the above operations. And that value is MEV - Miner Extractable Value.

In DeFi world, MEV occurs mainly in terms of arbitrage trading. Arbitrage trading, for example, exists between different DEXs, such as Uniswap and Sushiswap.

Generally, a certain amount of price slippage occurs after a larger transaction on Uniswap. And the arbitrage bot tends not to miss such opportunities. It submits arbitrage trades to miners.

We often see “pre-emptive trading” when trade in DEX such as Uniswap, where a bot trades first after a user initiates a trade, manipulates the price, and finally sells it for a profit. This amounts to an invisible increase in transaction costs for the user. “Sandwich attacks” are the most common ones, where the attacker knows that the trade will raise the price of the asset and plans to buy the asset in bulk at a lower price to drive up the price, allowing the trader to buy at a higher price and then sell the asset at a higher price.

Let’s see what exactly happened with the attack on Alpha Homora.

Since the information is relatively limite, our analysis is based on the main resource of a blog written by Alpha Homora.

Alpha Homora calls the Uniswap V2 router contract in its implementation, and the attack revolves around the addLiquidity function of the Uniswap V2 router contract, which calls _addLiquidity internally.

This function requires 4 amounts: amountADesired, amountBDesired, amountAMin and amountBMin. amountXDesired is the expected amount of liquidity to be added to the pool. amountXMin is the minimum number of assets to determine the amount of liquidity to be added, considering that there will be slippage, so passing parameter is a range and cannot be a definite value.

In the normal case, amountXDesired > actual number of deductions > amountXMin.

But since Alpha Homora ignores an implicit condition — amountADsired >= amountAMin, this leads to the possibility that amountXMin > amountXDesired when the project side calls Uniswap’s router contract. This situation gives the MEV bot a chance! Because it means that there could be an actual payment > amountXMin > amountXDesired!

Going back to the specific scenario, there are the following main steps.

1. A user adds liquidity by entering an expected value (i.e. amountXDesired), at which point the project owner also gives a minimum value (amountXMin), and the user finds it acceptable to make a transaction.
2. The MEV bot finds this opportunity and quickly pulls up the response price by pre-empting the trade.
3. At this point, since it may appear that mountXMin >amountXDesired and the actual number of deductions must be greater than mountXMin, this leads to the possibility that the actual number of deductions may far exceed the user’s expected value (i.e., mountXDesired), resulting in a loss of the user’s assets.
4. The MEV robot then trades again quickly to achieve an arbitrage exit.

So, what is our take home message from this?

With the rapid development of Defi, contracts from different projects are frequently called between each other, which leads to a rapid increase in coupling risk, and this risk is difficult to detect by general auditors because two projects are involved.

For example, Alpha Homora has been audited 3 times by OpenZeppelin, Peckshield and Quantstamp, and none of them found the problem. This shows that the original static security testing is already hard to find the rapid growing security risks.

While dynamic on-chain asset detection can be more effective in finding risks and promptly alerting them, which is also the direction Go Pocket safe wallet is optimizing.