The contract implementation, utilizing ERC20, exhibits unexpected behavior when interfacing with tokens that do not use 18 decimals. This inconsistency results in errors when calling the functions getTokenAmountFromUsd and getUsdValue.
The root of the issue lies in the hardcoding of the PRECISION variable as 1e18, which assumes that the token will have 18 decimals. In the specific case of ERC20 tokens like wrapped Bitcoin (wbtc), which has only 8 decimals, this hardcoding leads to malfunctioning in the mentioned functions (getTokenAmountFromUsd and getUsdValue).
For users interacting with the contract through tokens like wbtc, the discrepancy in decimal handling results in incorrect values being returned, causing financial losses to protocol and/or users. Functions such as mint, liquidate, and checks on the _healthFactor will consequently provide wrong outputs, thereby affecting the usability and integrity of the contract.
Manual Review
The contract should utilize the specific decimals from each token. As the decimals() method is not part of the standard ERC20 interface, the constructor must also be designed to receive the decimal value for each token being used.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.