MEV Attacks
Usually, such attacks are not done manually by users, but with the help of MEV bots with programmed strategies, who identify opportunities and execute them.
On a high level, MEV attacks can be separated into two categories: malicious, i.e. profiting from users, and non-malicious, i.e. gaining additional profit without causing others to lose. We’ll start with the latter.
Non-Malicious Attacks
Arbitrage trading
First, let’s understand what is arbitrage trading and then find out how it’s possible via MEV attacks. If we look at Investopedia, the definition is the following:
The simultaneous purchase and sale of the same or similar asset in different markets in order to profit from tiny differences in the asset’s listed price.
In Web3 it would be buying ETH on DEX A for $3400 and selling on DEX B for $3375.
It is one of the strategies that can be easily programmed into the MEV bot to extract additional value from the current blockchain state without causing users to lose money.
Liquidations
In case of liquidations on Lending & Borrowing protocols or Decentralised Perps, MEV bots track the health factors of all open positions to find an opportunity to force-close them and get the liquidation fee. On the one hand, it is malicious since they liquidate a user, but corresponding bots help to keep the protocol healthy and not accrue bad debt.
Malicious Attacks
The most famous example of a malicious MEV attack is sandwiching transactions. Let’s look at several examples of Sandwich MEV Attack examples.
Sandwich swaps
Probably one of the most common types of sandwich attacks. The miner/validator can front-run the victim’s swap by significantly increasing the token’s price, then the user’s transaction moves up the price even higher and the MEV bot back-runs with swapping back.
In this attack, the malicious actor profits from users significantly increasing the price and allowing the attacker to sell higher than buying. Moreover, the victim receives far fewer tokens than they should.
Just-in-time liquidity
This type of MEV attack also occurs on token swaps. But this time, when the attacker sees a large swap going to happen inside the block, they front-run the user’s transaction by adding liquidity into the pool, the user’s swap goes through and the MEV bot back-runs the transaction by withdrawing from the pool and getting the fees as an LP.
In this attack, the malicious actor profits from the fees generated as an LP for that transaction. What is more important here is that the attacker, essentially, steals these fees from other LPs who have been providing liquidity for a longer time.
Stealing vault rewards
This strategy involves the vaults where the rewards are sent in one transaction, i.e. when rewards are not accrued over time, but at a specific time. MEV bots can identify when the vault depositors will get the rewards, front-run this transaction by depositing into the vault, get the rewards, and back-run by withdrawing from the vault.
The profit is similar to the previous attack, the malicious actor steals the rewards from the users who have been investing in the vault for a longer time.
Time Bandit Attack
As the name suggests, the malicious actor manipulates the time between the transaction creation and inclusion in the block. It allows them to create more a favourable condition for the MEV attack.
The profit from Time Bandit Attacks can vary significantly since it can be used in any attack described above to gain more value.
Code Examples
Let’s dive into code to try and understand how to identify MEV attacks. This type of attack wasn’t mentioned above — sandwiching Oracle updates. This particular issue was a solo finding in the Olympus Update contest in 2023.
There is a <code-word>wstETH<code-word> and <code-word>OHM<code-word> pool, when users want to withdraw, the current oracle price is used to calculate the expected <code-word>wstETH<code-word> amount to be received by the user.
You can find the entire <code-word>withdraw()<code-word> function here.
Now let’s dive into the attack.
1. The <code-word>wstETH/OHM<code-word> current price is assumed to be 0.995, cause there are 79.8 <code-word>wstETH<code-word> and 80.2 <code-word>OHM<code-word>. Oracle’s price is 1:1 and it’s going to be updated to 0.995 <code-word>wstETH/OHM<code-word>:
Liquidity in the pool: 80.2 <code-word>wstETH<code-word> and 79.8 <code-word>OHM<code-word>.
Attacker: 20 <code-word>wstETH<code-word>.
2. The attacker swaps 0.2 <code-word>OHM<code-word> to make the liquidity equal:
Liquidity in the pool: 80 <code-word>wstETH<code-word> and 80 <code-word>OHM<code-word>.
Attacker: 20.2 <code-word>wstETH<code-word> and -0.2 <code-word>OHM<code-word>.
3. Attacker deposits their 20 <code-word>wstETH<code-word> into the pool:
Liquidity: 100 <code-word>wstETH<code-word> and 100 <code-word>OHM<code-word> (when you deposit <code-word>wstETH<code-word>, <code-word>OHM<code-word> token gets minted).
Attacker: 0.2 <code-word>wstETH<code-word> and -0.2 <code-word>OHM<code-word>.
4. And now they sell slightly more <code-word>wstETH<code-word> to <code-word>OHM<code-word>:
Liquidity: 100.252 <code-word>wstETH<code-word> and 99.748 <code-word>OHM<code-word>.
Attacker: -0.052 <code-word>wstETH<code-word> and 0.052 <code-word>OHM<code-word>.
Important to note here that all the actions above are done in the same transaction. The Oracle price updates to 0.995 <code-word>OHM<code-word> per <code-word>wstETH<code-word>. By this point, the attacker has already balanced the pool to post-oracle-update condition, thus they can extract the entire <code-word>wstETH<code-word> deposited:
1. Withdraw liquidity:
Liquidity: 80.202 <code-word>wstETH<code-word> and 79.798 <code-word>OHM<code-word>.
Attacker: 19.998 <code-word>wstETH<code-word> and 0.052 <code-word>OHM<code-word>.
2. The profit here is 0.052 <code-word>OHM<code-word> which the attacker sells and ends up with 20.05 <code-word>wstETH<code-word> which is equal to 0.05 <code-word>wstETH<code-word>.
Mitigation
There are several recommendations to avoid MEV attacks:
1. When the MEV attack involves depositing into a vault/pool, then it’s recommended to set a timelock, i.e. don’t allow the attacker to withdraw for 1 week after the deposit.
2. Slippage and deadline controls will allow to mitigate sandwiching swaps and time bandit attacks.
3. Avoid stepwise jumps, i.e. don’t allow an attacker to extract additional value from one transaction, for example, stealing vault rewards.
4. Get another round of audits. MEV attacks are known but in some cases can be too complex for auditors to find them. Therefore, hiring a team of professionals like Shieldify to conduct security research is essential. If you’re interested, please press the “Contact” button in the top-right corner.
Conclusion
As you’ve probably understood, MEV attacks are simply sandwich attacks coded into bots in most cases. Moreover, they can be either good, helping to keep the protocols healthy, or bad, leading to users and protocols losing funds. As security researchers, we have to know and be able to identify all the possible MEV Attack vectors correctly. If there are more interesting types of MEV attacks or their mitigations, post it and tag @ShieldifySec on X.MEV is the abbreviation of Miner or Maximum Extractable Value. Miners/validators can order, prioritize and censor transactions in blocks, moreover, they can insert their transactions. Therefore, they always seek opportunities to manipulate transactions and gain additional value besides the fees for creating blocks.
