code-423n4 / 2024-03-revert-lend-findings

13 stars 10 forks source link

Hardcoded slippage value #512

Closed c4-bot-4 closed 8 months ago

c4-bot-4 commented 8 months ago

Lines of code

https://github.com/code-423n4/2024-03-revert-lend/blob/main/src/transformers/AutoCompound.sol#L165 https://github.com/code-423n4/2024-03-revert-lend/blob/main/src/transformers/V3Utils.sol#L159-L160 https://github.com/code-423n4/2024-03-revert-lend/blob/main/src/transformers/V3Utils.sol#L206-L207 https://github.com/code-423n4/2024-03-revert-lend/blob/main/src/transformers/AutoRange.sol#L206-L207

Vulnerability details

Description

In AutoCompound.sol exactly in the execute() function the project is hardcoding the value of the slippage when calling nonfungiblePositionManager.increaseLiquidity(INonfungiblePositionManager.IncreaseLiquidityParams(params.tokenId, state.maxAddAmount0, state.maxAddAmount1, 0, 0, block.timestamp));

Proof of Concept

The IncreaseLiquidityParams struct is the one that holds all the details of this call. struct IncreaseLiquidityParams { uint256 tokenId; uint256 amount0Desired; uint256 amount1Desired; uint256 amount0Min; uint256 amount1Min; uint256 deadline; } You can see that amount0Min and amount1Min are responsible for checking the slippage value however the project is hardcoding it to 0 right now. This means that users are accepting 0 tokens in return in high volatility market conditions. The project is also using the same method in other contracts such as V3Utils.sol and AutoRange.sol

Tools Used

Manual Analysis

Recommended Mitigation Steps

I recommend the project to allow setting the value in the function parameter as its the most efficient and simple way.

Assessed type

Uniswap

c4-pre-sort commented 8 months ago

0xEVom marked the issue as sufficient quality report

c4-pre-sort commented 8 months ago

0xEVom marked the issue as duplicate of #198

c4-judge commented 8 months ago

jhsagd76 marked the issue as unsatisfactory: Out of scope