Chainlink aggregator min/max bound misconfig
GMX v2 (GMX Synthetics)'s assessment for RD-F-060 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
Chainlink on-chain AggregatorV3 feeds are used as deviation-reference guards, not primary prices. GMX Oracle.sol reads the feed answer value but does not enforce minAnswer/maxAnswer bounds at the GMX layer. For well-established Arbitrum feeds (ETH/USD 0x639Fe6ab55C921f74e7fac1ee960C0B6293ba612, BTC/USD 0x6ce185860a4963106506C203335A2910413708e9) bounds are typically not at Chainlink defaults, but this has not been verified on-chain in this assessment. Scored yellow — reference use limits but does not eliminate misconfig risk.
Detail #
Data cache oracle_feeds[] provides feed addresses. ChainlinkPriceFeedProvider.sol reads latestRoundData() answer only. Oracle.sol uses the answer for deviation check — no explicit minAnswer/maxAnswer guard at the GMX contract level. Chainlink aggregator bounds are internal to the feed and not enforced by GMX. Template: yellow = potential misconfig risk not verified.
Sources #
- EtherscanChainlink ETH/USD — ArbiscanChainlink ETH/USD Arbitrum feed 0x639Fe6ab55C921f74e7fac1ee960C0B6293ba612retrieved 2026-05-05
- ChainlinkPriceFeedProvider.solChainlinkPriceFeedProvider.sol — reads answer only from latestRoundData()retrieved 2026-05-05
Methodology #
Determine whether the Chainlink aggregator's `minAnswer` and `maxAnswer` circuit-breaker bounds are misconfigured (too wide or too narrow) for the asset class.
See the full factor methodology and distribution across all protocols →