Slippage value is hardcoded in TokenisableRange.sol

[code423n4]

Lines of code

https://github.com/code-423n4/2023-08-goodentry/blob/71c0c0eca8af957202ccdbf5ce2f2a514ffe2e24/contracts/TokenisableRange.sol#L258 https://github.com/code-423n4/2023-08-goodentry/blob/71c0c0eca8af957202ccdbf5ce2f2a514ffe2e24/contracts/TokenisableRange.sol#L259

Vulnerability details

Impact

The value of minimum amount for add liquidity by POS_MGR is hardcoded to 95 %. using hardcoded value as slippage does not protect from frontrunning since its always calculating the minimum amount as a 95%. hardcoded value allows malicious keepers to run sandwich attack.

Proof of Concept

Below is code of TokenisableRange.sol.deposit(), as you can see amount0Min value and amount1Min value is hardcoded to 95% of n0 amount and n1 amount.

(uint128 newLiquidity, uint256 added0, uint256 added1) = POS_MGR.increaseLiquidity(
  INonfungiblePositionManager.IncreaseLiquidityParams({
    tokenId: tokenId,
    amount0Desired: n0,
    amount1Desired: n1,
    amount0Min: n0 * 95 / 100,
    amount1Min: n1 * 95 / 100,
    deadline: block.timestamp
  })
);

There is possibility that user, always, loss 5% of fund in addLiquidity process.

Tools Used

Manually

Recommended Mitigation Steps

The minAmount should come either from the parameter from user.

Assessed type

Uniswap

[c4-pre-sort]

141345 marked the issue as duplicate of #105

[c4-judge]

gzeon-c4 marked the issue as unsatisfactory: Overinflated severity