c4-bot-8 commented 9 months ago

Lines of code

https://github.com/code-423n4/2024-02-althea-liquid-infrastructure/blob/bd6ee47162368e1999a0a5b8b17b701347cf9a7d/liquid-infrastructure/contracts/LiquidInfrastructureERC20.sol#L270-L277

Vulnerability details

Impact

The manner in which entitlement is calculated and then sent over to the holders is incorrect.

Proof of Concept

entitlement is calculated as balance / supply, where balance is IERC20(distributableERC20s[i]).balanceOf(address(this)); and supply is this.totalSupply();. This entitlement is multiplied by the LiquidInfrastructureERC20 balance of the holder and then distributed the respective distributableERC20s to the holder.

Calculating entitlement in this manner is incorrect as more distributableERC20s tokens will be sent to a holder than intended when IERC20(distributableERC20s[i]).balanceOf(address(this)) is much higher than this.totalSupply(). If it's much higher, then the calculated entitlement will no longer represent the fraction of the pool that it is meant to represent. This might not leave enough tokens in the contract for the other holders and cause the transfers of distributableERC20s to revert due to insufficient balance in the contract when it tries to distribute tokens to other holders.

Rewards/entitlement for a holder should be calculated based on the fraction of their balance of the totalSupply. The ratio of balance / supply to calculate the entitlement does not represent the accurate share of the user. Instead, the share or the value to be transferred to the holder should be calculated as follows:

this.balanceOf(recipient) * IERC20(distributableERC20s[i]).balanceOf(address(this)) / this.totalSupply()

This accurately represents a user's share of the pool and how many tokens they need to be distributed.

Tools Used

Manual review

Recommended Mitigation Steps

Perform the calculation as shown in the code snippet above.

Assessed type

Other