The Standard

The Standard
DeFiHardhat
20,000 USDC
View results
Submission Details
Severity: low
Valid

distributeAssets costInEuros should be roundedUp to benefit the protocol; The operation has a division before multiplication which ensures a precision loss of 2 units instead of 1 unit

Summary & Vulnerability Details

On LiquidationPool, the function distributeAssets(), will distribute the liquidated assets to stakers.
A calculation on the costInEuros to be payed by the staker for the assets is done.

        uint256 costInEuros = _portion * 10 ** (18 - asset.token.dec) * uint256(assetPriceUsd) / uint256(priceEurUsd) * _hundredPC / _collateralRate;

If we simplify the calculation, we have:

        costInEuros = portion * assetPriceUsd / priceEurUsd * _hundredPC / _collateralRate

We two divisions, one of the divisions before a multiplication, which will result in a precision loss of 2 units instead of the inevitable 1 unit.

Also, the costInEuros represents a price that the user will have to pay for assets being liquidated, and since we are having a loss in precision, the user will pay 2 units less than what he should. For prevention the precision loss should benefit the protocol and the cost be rounded up.

The new calculation should look like this:

        costInEuros = portion * assetPriceUsd * _hundredPC / priceEurUsd / _collateralRate

A question that could be raised is if the multiplications will overflow and revert. If we look at the decimals of the variables we have -> 18 * 8 * 6 / 8 / 6; In the multiplication we will reach 32 decimals (18 + 8 + 6) on the calculation. An overflow of a uint256 will happen if it reaches a value > ~10e77. The calculation can handle portions of numbers with ~ 45 zeros, not counting the decimals. Realistically an overflow will never happen for this calculation.

Impact

The staker will get an added discount of 2 decimals on top of the discount of the collateral rate. The impact could be exacerbated by stacking on a massive amount of accounts, all of them getting an added 2 decimal discount. It is unclear how this could be realistically exploited to affect the protocol, but we have previously seen how a rounding to the wrong direction could have disastrous impact on protocols, and it is good practice to always round to the benefit the protocol.

Tools Used

Manual Review & Hardhat unit tests

Recommendations

Round up on the divisions to get the costInEuros

Updates

Lead Judging Commences

hrishibhat Lead Judge over 1 year ago
Submission Judgement Published
Validated
Assigned finding tags:

precision

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.