ERC20 TOKENS WITH DIFFERENT DECIMALS THAN 18 MAY BREAK THE LOGIC AND PROVIDE UNEXPECTED RESULTS

[code423n4]

Lines of code

https://github.com/code-423n4/2022-12-caviar/blob/main/src/LpToken.sol#L13
https://github.com/code-423n4/2022-12-caviar/blob/main/src/Pair.sol#L46
https://github.com/code-423n4/2022-12-caviar/blob/main/src/Pair.sol#L20

Vulnerability details

Impact

Note: Though it is mentioned that Rebase/fee-on-transfer tokens are not expected, however there exist other ERC20 tokens having different decimals than 18

Contracts LpToken and Pair performs calculations by using hardcoded value of decimals 18 (1e18) for ERC20 tokens. This could break the logic and would provide unexpected results throughout the contract on using ERC20 tokens with different decimals than 18. Example of such a token is  Gemini USD only have 2 decimals, YAM-V2 has 24 decimals.

Hardcoded decimal value of 18 being used:

https://github.com/code-423n4/2022-12-caviar/blob/main/src/Pair.sol

20: uint256 public constant ONE = 1e18;
46: ERC20(string.concat(nftName, " fractional token"), string.concat("f", nftSymbol), 18)

https://github.com/code-423n4/2022-12-caviar/blob/main/src/LpToken.sol#L13

13: ERC20(string.concat(pairSymbol, " LP token"), string.concat("LP-", pairSymbol), 18)

Recommended Mitigation Steps

It is recommended to add support for different number of decimals than 18 by dynamically checking decimals() for the tokens that are part of the rewards calculations. Alternatively if such a support is not needed, new require statements should be added to addPool that will be checking that the number of decimals for all ERC20 tokens is 18.

[iFrostizz]

The 18 decimals token mentioned is the LP token.
There is no evidence of issues regarding tokens using another amount of decimals, as the LP tokens value is arbitrary.

[c4-judge]

berndartmueller marked the issue as duplicate of #53

[c4-judge]

berndartmueller marked the issue as satisfactory

[C4-Staff]

CloudEllie marked the issue as duplicate of #141