Summary

The DSCEngine miscalculates the USD value of tokens with other than 18 decimals.

Note: I have submitted this issue once before, but it did not appear in my list of reports. If you see duplicates of this, please ignore them.

Vulnerability Details

The DSCEngine contract calculates the USD value of the underlying collateral in getUsdValue:

As PRECISION is hardcoded to 1e18, this method assumes that the token has 18 decimals. If it does not however, as is the case with WBTC with 8 decimals which this system is explicity supposed to work with, the method will return the wrong USD value:

• When the token has less than 18 decimals, the returned value is too low

• When the token has more than 18 decimals, the returned value is too high

Proof of Concept

Assume a token TOKEN has 8 decimals and 1 TOKEN = $1000. Chainlink oracles always return their response with 8 decimals (for non-ETH pairs). Thus the calculation for 1 TOKEN would be:

which is significantly below the intended result of 1000e18 = 1e21.

On the other hand, assuming TOKEN has 20 decimals, the calculation would be:

which in this case is significantly above the intended result of 1000e18 = 1e21.

Impact

When the decimals are less than 18, the contract calculates the value of the collateral as way too low, meaning users cannot mint the appropriate amount of DSC.

When the decimals are above 18, the contract calculates the value of the collateral as way too high, meaning users can mint too much DSC, which could lead to a depeg and loss of funds through selling of the cheaply accquired DSC on secondary markets.

Severity

I have selected High for this issue since it affects the explicit use-case of WETH/WBTC as collateral (where it would brick the contract to some degree), and since it has the potential for loss of funds for other collateral tokens with more than 18 decimals.

Tools Used

None

Recommendations

Adapt PRECISION based on the decimals of the given token:

This should be done in both getUsdValue and getTokenAmountFromUsd.