Core Contracts

Summary

when depositing rToken or withdrawing deToken, the contract calculates the amount user would get for the corresponding token. but the flaw in the logic does not account if the decimals is different

Vulnerability Details

StabilityPool.sol#L54-L56

the code intended to allow the rToken / deToken to have flexible decimal, thus they implement the scaling factor to calculate the amount of exchange from rToken-deToken:

StabilityPool.sol#L186-L204

but one of this function would be broken if the decimals is not 18.

1) if one of the token decimal is 18, and the other is 6, then one of the function would revert because of overflow

2) if two token decimals is not 18, let say 6 for both token, then the scalingFactor would result in 10**18 which is different

Impact

the above function always result in DoS, as the example above, the first one because overflow. the second one because the token amount is bigger than what it supposed to be, potentially makes the tx revert if user/pool does not have the amount or if the amount suffice then it would became loss for user or pool because the amount transferred should not that huge.

Tools Used

manual review

Recommendations

derive the decimals straight from the rToken and deToken contract, and work the scaling by checking what contract have bigger decimal than other before deducting it and then multiply it with the corresponding token.

consider to not use addition when doing the exponent, you can use multiplication for more readability.