Precision loss in calculation of entitlement

[c4-bot-9]

Lines of code

https://github.com/code-423n4/2024-02-althea-liquid-infrastructure/blob/main/liquid-infrastructure/contracts/LiquidInfrastructureERC20.sol#L275-L276 https://github.com/code-423n4/2024-02-althea-liquid-infrastructure/blob/main/liquid-infrastructure/contracts/LiquidInfrastructureERC20.sol#L222-L223

Vulnerability details

Impact

Calculation of erc20EntitlementPerUnit doesn't consider adding scaling factor before division and similarly while calculating entitlement scaling factor not included in multiplication which will result in precision loss.

Proof of Concept

Here In erc20EntitlementPerUnit while calculating entitlement uint256 entitlement = balance / supply; suppose distributableERC20s[i] is USDC having 6 decimal precision and total supply having 18 decimal presion then on calculating uint256 entitlement = 1e6/(10001e18) (say) entitlement = 0 and similarly here entitlement on calculation of ```uint256 entitlement = erc20EntitlementPerUnit[j] this.balanceOf(recipient); ``` no division with scaling factor will result in inconsistency.

Tools Used

Manual

Recommended Mitigation Steps

consider including scaling factor uint256 entitlement = (balance * scaling_factor) / supply;

uint256 entitlement = (erc20EntitlementPerUnit[j] * this.balanceOf(recipient))/ scaling_factor;

Assessed type

Math

[c4-pre-sort]

0xRobocop marked the issue as sufficient quality report

[c4-pre-sort]

0xRobocop marked the issue as primary issue

[0xRobocop]

Somewhat flagged by bot:

https://github.com/code-423n4/2024-02-althea-liquid-infrastructure/blob/main/bot-report.md#l-07-loss-of-precision

[ChristianBorst]

I think this is a duplicate of the bot findings. This would introduce the possibility of miscalculations for tokens with very low per-wei value and high revenue in the protocol, but I highly doubt those would be involved with LiquidInfrastructure. We may take this approach, but I think a better solution would involve normalizing to the smallest holding.

[c4-sponsor]

ChristianBorst (sponsor) acknowledged

[c4-sponsor]

ChristianBorst (sponsor) confirmed

[c4-judge]

0xA5DF marked the issue as unsatisfactory: Out of scope

[c4-judge]

0xA5DF removed the grade

[c4-judge]

0xA5DF marked the issue as satisfactory

[0xA5DF]

On a second note, while the bot did detect the issue it has addressed only part of the issue. If the protocol would have only the bot report and implement the mitigation mentioned there we'd still be dealing with loss of value when the precision loss is significant (e.g. 1.99 rounded down to 1).

Therefore, this is a valid issue on its own.

[c4-judge]

0xA5DF marked issue #724 as primary and marked this issue as a duplicate of 724

[c4-judge]

0xA5DF marked the issue as unsatisfactory: Out of scope

[c4-judge]

0xA5DF marked the issue as unsatisfactory: Out of scope