mel0ndev
commented
1 year ago hi there! please check https://github.com/VMEX-finance/vmex/blob/master/packages/contracts/contracts/protocol/oracles/BalancerOracle.sol#L127C3-L127C3 where we scale the reserves before computing.
If there is anything else, please provide a POC showing a price error so we can take a look as testing on our end did not reveal that to be the case.
Github username: @@rodiontr Submission hash (on-chain): 0x842cc2919c63ac3c2aee9d18536c4808c6514c654014184f227a7641031ec1e4 Severity: high severity
Description: Description\
In BalancerOracle.sol, there is an internal function computeFairReserves() that returns fair reserve amounts given spot reserves, weights, and fair prices. The decimals of token A, however, can be smaller than decimals of the token B
Attack Scenario
Some tokens that have different decimals such as USDC (6 decimals) (or WBTC, USDT etc.) and ETH (18 decimals) should be calculated properly but in BalancerOracle they are left with their base decimals. This will lead to getting incorrect prices and will affect different important functions of the protocol and potentially lead to a loss of money for users
Attachments
https://github.com/VMEX-finance/vmex/blob/master/packages/contracts/contracts/protocol/oracles/BalancerOracle.sol#L88
Recommendation:
Change the following line above on:
uint r0 = BNum.bdiv(resA * 10**(decimals of tokenB) , resB);
The contract uses BNum.sol library that prevents from division rounding errors in this case but it doesn't protect from incorrect prices if not adjusted properly. Although, BNum library is outdated so consider using another one