tvdung94 - Dusted Ohm token in balancer supply might be ignored

[sherlock-admin2]

tvdung94

medium

Dusted Ohm token in balancer supply might be ignored

Summary

Dusted Ohm token in balancer supply might be ignored

Vulnerability Detail

To get the amount of reserve tokens in the balancer pool owned by the protocol, first we need to calculate the amount of bpt token owned, and then convert it into an equivalent amount of each token.

The problem arises when we are trying to convert bpt token into dusted ohm in the pool. Resulted ohm balance might be zero if the total amount of ohm in the pool is small enough. This scenario is likely to happen because ohm has much less decimals than the other tokens.

 uint256 balTotalSupply = pool.balancerPool.totalSupply();
        uint256[] memory balances = new uint256[](_vaultTokens.length);
        // Calculate the proportion of the pool balances owned by the polManager
        if (balTotalSupply != 0) {
            // Calculate the amount of OHM in the pool owned by the polManager
            // We have to iterate through the tokens array to find the index of OHM
            uint256 tokenLen = _vaultTokens.length;
            for (uint256 i; i < tokenLen; ) {
                uint256 balance = _vaultBalances[i];

      >>>      uint256 polBalance = (balance * balBalance) / balTotalSupply; //@audit - will return 0 when balance * balBalance < balTotalSupply

                balances[i] = polBalance;

                unchecked {
                    ++i;
                }
            }
        }

From the above code, we can easily see that if (balance * balBalance) < balTotalSupply, resulted polBalance will be 0.

Impact

Dusted Ohm might be treated unfair to other tokens, since it has only 9 decimals while the others have 18

Code Snippet

https://github.com/sherlock-audit/2023-11-olympus/blob/main/bophades/src/modules/SPPLY/submodules/AuraBalancerSupply.sol#L332-L370

Tool used

Manual Review

Recommendation

Consider handling ohm separately from the rest.

[nevillehuang]

Invalid, this finding fails to explain how this is possible to occur, given you are also multiplying balance and balBalance scaled accordingly to the same decimals as balTotalSupply. So this would constitute as insufficient proof based on the following sherlock rule.

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