sil3th - Precision Loss Due to Non-Exact Multiples in Division

[sherlock-admin2]

sil3th

medium

Precision Loss Due to Non-Exact Multiples in Division

Summary

When prizePool and currentRoundAgentsAlive are not exact multiples of each other, the division operation will lead to precision loss. Solidity performs integer division by truncating the fractional part, meaning it discards the remainder. This behavior can result in incorrect calculations when the intention is to maintain the fractional part.

Vulnerability Detail

Explained in the POC Below

`pragma solidity ^0.8.0;

contract PrecisionLossExample {
uint256 public prizePool;
uint256 public currentRoundAgentsAlive;
uint256 public totalEscapeValue;

constructor(uint256 _prizePool, uint256 _currentRoundAgentsAlive) {
prizePool = _prizePool;
currentRoundAgentsAlive = _currentRoundAgentsAlive;
totalEscapeValue = prizePool / currentRoundAgentsAlive;
}

function calculateTotalEscapeValue() public view returns (uint256) {
return totalEscapeValue;
}
}

`
In this example, the prizePool is set to 100, and currentRoundAgentsAlive is set to 30. When we deploy the contract and calculate totalEscapeValue, we can observe that precision loss occurs due to integer division:

`// Deployment
PrecisionLossExample example = new PrecisionLossExample(100, 30);

// Retrieve the calculated totalEscapeValue
uint256 result = example.calculateTotalEscapeValue(); // result will be 3
`
In this case, the result of the division is 3, which is the integer part of the result. The fractional part is discarded due to integer division, resulting in precision loss.

Impact

Precision loss can lead to inaccurate calculation of totalEscapeValue.

Code Snippet

https://github.com/sherlock-audit/2023-10-looksrare/blob/86e8a3a6d7880af0dc2ca03bf3eb31bc0a10a552/contracts-infiltration/contracts/Infiltration.sol#L740C31-L740C31

Tool used

Manual Review

Recommendation

Scale Up Values Before Division: Multiply both prizePool and currentRoundAgentsAlive by a common scaling factor before performing the division. This scaling factor should be a power of 10 to ensure precision is maintained.

[nevillehuang]

#17 - An example is given, but impact is not significant enough. Precision used to indicate finding is also incorrect since example does not correctly reflect actual possible precision loss of prizePool (which is 18 decimals since it is native ETH/wETH). So the full impact is not correctly shown. At most valid low, since if you extend to 18 decimals precision, the possible precision loss is actually low.

#124 - Example given have no relation to affected code and hence is not valid.

#19, #142 - While precision loss is possible, both lack an explicit example to show impact of precision loss. Based on sherlocks guidelines, at most valid low

In case of issues related to precision loss, there must be a valid POC/example showing the loss to justify the medium/high severity.