MEV Bots & Uniswap Implicit Assumptions
We recently received a user report regarding abnormal position value loss in Alpha Homora V2 on Ethereum after the position was opened. Looking at the transaction details, the slippage control values correctly reflected the 1% tolerance, but the LP value still did not conform.
So what’s going on? In short, a Miner Extractable Value (MEV) bot inspected the transaction, bundled the transactions such that the bot could make financial profits, and sent these transactions privately to a particular group of miners who then mined these transactions.
How did this happen and what is the original root cause? It turns out that the Uniswap V2 Router contract has implicit assumptions that are not clearly stated on the contract level. Hence, without stating these assumptions, slippage control for some trades on Uniswap V2 may not be checked and may not be taken into account at all in certain scenarios.
These implicit assumptions on Uniswap V2 resulted in 20 addresses on Alpha Homora V2 being impacted and lost a total of 40.93 ETH to miners who extracted this value. We have plans to compensate these 20 addresses. However, what’s more important is to share this with our community, especially other builders in the space to be aware of these implicit assumptions that are not stated, how you can detect this as a builder, and how to prevent/mitigate this.
Claiming process for relevant users
As mentioned above, 20 addresses were impacted and lost a total of 40.93 ETH. The list of these 20 addresses and the relevant ETH amount can be found here. On November 5, these 20 addresses can claim the relevant amount back in ALPHA tokens, and the exact number of ALPHA tokens can be found in the same link. We will share a guide on how to claim as we approach the actual claiming event.
While this amount was a result of the implicit assumptions that were not stated on the Uniswap V2 Router contract, Alpha Homora V2 users were impacted and we believe the best course of action is to compensate the users.
ALPHA stakers
In this case, the implicit assumptions not stated on the Uniswap V2 Router contract resulted in miners successfully extracting values from 20 addresses even though Alpha Homora V2 were audited three times by OpenZeppelin, Quantstamp, and PeckShield. To uphold the function of Alpha Tokenomics, which serves as an insurance for Alpha products, and the collective moral value we share in our community, 154,671 ALPHA (0.064% of total ALPHA staked) will be extracted from Alpha Tokenomics and be distributed to the relevant users as outlined in this same link here.
As a part of Alpha Tokenomics, ALPHA stakers stake to earn 1) Alpha protocol fees 2) Alpha Launchpad tokens and 3) Alpha Tiers to unlock special product features. In exchange, ALPHA stakers and the staked funds act to secure Alpha products in case when insurance is needed, which applies to this situation at hand.
For builders - How to detect and mitigate
For fellow builders out there, let us share more details on these unstated assumptions on the Uniswap V2 Router contract that allows MEV bots to take an unfair advantage as well as the mitigations you can do if you are in a similar situation.
First, we noticed that etherscan had marked the block with Flashbots and Private Transaction tags.
With further investigation into the transactions in that particular block, it turns out that the execute transaction the user submitted on Alpha Homora V2 was bundled and sandwiched by an MEV bot.
So, we performed local testing and revisited our code, and we were able to replicate the inconsistency and identify the issue that caused such a possible sandwich attack vulnerability.
NOTE 1: The fix has been patched. Only a few users were affected. Funds are safe.
NOTE 2: The vulnerability was present since the original version of Alpha Homora V2, which has undergone 3 different audits from OpenZeppelin, Peckshield, and Quantstamp. The issue has remained unnoticed until recently, which we had already fixed.
What’s the issue?
UniswapV2Router02
The issue revolves around the Uniswap V2 Router’s addLiquidity function, which internally calls _addLiquidity.
The function takes 2 amounts: amountXDesired and amountXMin amountXDesired determines the desired amount for adding liquidity to the pool. amountXMin determines the minimum amount of assets used. This may seem correct, but is in fact incorrect.
There is an implicit condition required:
amountADesired >= amountAMin, and
amountBDesired >= amountBMin
Otherwise, the amountXMins may not trigger reverts and are simply ignored. You can see in the code above that there are asymmetric checks for the amounts.
So, how does this affect Alpha Homora V2 transactions?
During execution, Alpha Homora v2 optimally swaps the input tokens before supplying to the Uniswap pool.
Note 1: From the transaction details, the vulnerability requires MEV bots to also risk large capital, which can be in the order of $1M from the transaction details.
Note 2: From our investigation, the MEV bots are generalized sandwich attack bots, which are not specific to Alpha Homora V2.
Mitigations
After we have confirmed and tested the fix, our team proceeded quickly to patch the issue. Extra checks were performed to ensure the pre-conditions are satisfied and such scenarios can no longer happen. The fix has also been confirmed by OpenZeppelin and Peckshield.
In fact, here are other possible mitigations, e.g.
- Uniswap V2 Router03 that performs checks for the undesirable condition.
- Alpha Homora v2 performs checks itself to ensure those min amounts are actually used, instead of relying on Uniswap V2 Router.
- Alpha Homora v2 uses outputs from Uniswap V2 Router to check against min amounts.
About Alpha Finance Lab
Alpha Finance Lab is a DeFi Lab, and on a mission to build