Open hats-bug-reporter[bot] opened 1 year ago
You can not even mitigate this by increasing decimals inside asset mappings. For example, using decimals 10 (12 + 18) for velo lp share token decimals instead of 10 18 since asset mappings query ERC20 only to fetch decimals function getDecimals(address asset) external view
function getDecimals(address asset) external view
returns (
uint256
){
return IERC20Detailed(asset).decimals();
}
note: after discussion with @ksyao2002 , it turns out 1 Velo USDC-DAI LP share is worth 2m only :) didn't consider that possibility mostly false positive
Github username: @abhishekvispute Submission hash (on-chain): 0xc472cabb8cc02749192f09fb251a5c9314699a66054d6fd1fd5a4225e4781919 Severity: high severity
Description: Description\ VMEX has a dedicated contract called VMEXOracle.sol, serving as an entry point for all Oracle prices. Throughout the lending pool code, VMEX makes an assumption that all prices returned from VMEX oracle are of the same denomination (same decimals). It could be in ETH with 18 decimals or it could be in USD with 8 decimals. But for a given network price has to be the same no of decimals for all assets.
For example
VMEX also comments in their VMEX oracle that asset price should always have 18 decimals if using ETH and 8 decimals if using USD.
https://github.com/VMEX-finance/vmex/blob/128929d56c71860dc8e683dd8a075f3e4eca9c90/packages/contracts/contracts/protocol/oracles/VMEXOracle.sol#L181
However, the problem is Velodrome oracle returns the price in 18 decimals even if it's using USD. Hence exponentially overvaluing Velo LP shares.
POC
Fork Optimsim (For USDC-DAI Stable Pool)
Attack Scenario\
Recommendation\ Consider downscaling VELO LP shares price to match base currency decimals