Summary

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.

Vulnerability Details

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).

Impact

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.

Tools Used

Manual Review

Recommendations

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.