Core Contracts

Summary

Protocol can set any decimals for DeToken Rtoken within StabilityPool contract by having the functions which calculates decimals for exchange between them. Meanwhile this feature doesn't work if protocol set decimals which is not equal to the one which those tokens have.

Vulnerability Details

Meanwhile such feature was invented to set decimals which is not correlate to the one tokens have the function to "translate" tokens' decimals to the one we set works incorect way.

The issue arise because it tooks rcvUSDAmount which scaled by it own decimals (like any other token). And if it's decimals vary from the one we set in contsructor using "flexible decimals feature" we will always got incorect result.

consider an example
Rtoken have 6 decimals
DeToken have 18
Those decimals should be set in contructor

Meanwhile actual tokens decimals of Rtoken, let's say, equal to 8 (the decimals defined in it's erc20 implementation)

then we have following result:
SF = 10e30
return = (lets take 1 token of Rtoken for simplicity) 1e8 x 10e30/1e18 = 1e20, which is obviously wrong.

Impact

reserve miscalculation across StabilityPool contract and unfair reward calculation

Tools Used

manual review

Recommendations

change the logic, to ensure you past already adjusted by decimals amount of DeCRVUSD/ Rtoken to function