Lucene search

K
code423n4Code4renaCODE423N4:2022-12-CAVIAR-FINDINGS-ISSUES-488
HistoryDec 19, 2022 - 12:00 a.m.

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

2022-12-1900:00:00
Code4rena
github.com
7
vulnerability
erc20
decimals
gemini usd
yam-v2
hardcoded
mitigation

Lines of code
<https://github.com/code-423n4/2022-12-caviar/blob/main/src/Pair.sol#L46&gt;
<https://github.com/code-423n4/2022-12-caviar/blob/main/src/Pair.sol#L20&gt;

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&gt;

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&gt;

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.


The text was updated successfully, but these errors were encountered:

πŸ‘Ž 1 Shungy reacted with thumbs down emoji

All reactions

  • πŸ‘Ž 1 reaction