The code assumes Chainlink decimals = 8 without checking. Should query actual decimals from the feed. Uses a fixed normalization formula that doesn't work for all tokens like usdc and wbtc.
WBTC (Wrapped Bitcoin)
Token Decimals: 8
Chainlink Feed Decimals: 8
Current Code Calculation
This calculation is incorrect for WBTC . The code assumes it needs to normalize to 8 decimals, but WBTC is already at 8 decimals. Results in prices being divided by too large a factor.
USDC (USD Coin)
Token Decimals: 6
Chainlink Feed Decimals: 8
Current Code Calculation
Similar to WBTC, Over-adjusts the decimals. Creates significant precision loss
Precision loss for tokens like wbtc and usdc
Foundry
Get actual decimals from both token and feed and Normalize prices to same decimal basis.
}
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
GMX github documentation: “Prices stored within the Oracle contract represent the price of one unit of the token using a value with 30 decimals of precision. Representing the prices in this way allows for conversions between token amounts and fiat values to be simplified, e.g. to calculate the fiat value of a given number of tokens the calculation would just be: token amount * oracle price, to calculate the token amount for a fiat value it would be: fiat value / oracle price.” Sponsor confirmed the keeper does the same, so price decimals change in function of the token, to be sure the above rule is true. Example for USDC (6 decimals): Prices will have 24 decimals → 1e6 * 1e24 = 1e30. Just a reminder for some submissions: shortToken == collateralTokens, so the decimals is 1e24 for shortToken prices.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.