The Standard

Summary

amountOutMinimum is set to protect the protocol, but not users, and can even be 0. It is vulnerable to MEV sandwich attacks, and users will lose funds on significant slippages.

Vulnerability Details

Key facts:

• Sandwich attacks.

• Description of risks for setting amountOutMinimum to zero on Uniswap.

• In the recent changes, SmartVaultManagerV5::calculateMinimumAmountOut was added, but it only protects the collateralisation of minted EUROs by the user, and does not save funds at all, since it could even return zero:

Attack scenario 1:

• For simple calculations in this example: 1 ETH = 1000 euros, 1 BTC = 10000 euros.

• User deposits 1 ETH.

• User mints 454 EUROs.

• User wants to swap 1 ETH to 0.1 BTC.

  • amountOutMinimum is not zero, but equivalent to 500 euros. Calculations (see SmartVaultManagerV5::calculateMinimumAmountOut):

  • requiredCollateralValue = 454 * 110 / 100 ≈ 500.

  • collateralValueMinusSwapValue = 1000 - 500 = 500.

  • result of calculateMinimumAmountOut = calculator.eurToToken(1000 - 500) = calculator.eurToToken(500) = 0.05 BTC.

• MEV bots manipulate the price in Uniswap.

• Up to half of the user's funds are at risk (min value 0.05 BTC, but the fair swap value is 0.1 BTC).

Attack scenario 2:

• Similar to scenario 1, but a User without minted euros swaps assets.

  • amountOutMinimum = 0.

• MEV bots manipulate the price in Uniswap.

• All of the user's swapped funds are at risk.

Impact

All or some part of user-swapped funds are at risk.

Tools Used

Manual review

Recommended Mitigation

From the Uniswap recommendations:

For a real deployment, this value [amountOutMinimum] should be calculated using our SDK or an onchain price oracle - this helps protect against getting an unusually bad price for a trade due to a front running sandwich or another type of price manipulation

• Calculated using our SDK is not very suitable since we should have protection of debt collateralisation.

• Onchain price oracle is a good variant. amountOutMinimum should be calculated using PriceCalculator minus several percent of allowed slippage. This percent should be much less than collateralRate - 100%. For example, with a collateralRate = 110%, a slippage of 1-2% looks good.

Also, swaps should probably be prohibited when SmartVaultV3.undercollateralised() = true.