Oracle staleness check present
GMX v2 (GMX Synthetics)'s assessment for RD-F-059 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
Mixed staleness posture. Oracle.sol checks `validatedPrice.timestamp + maxPriceAge < Chain.currentTimestamp()` for GmOracleProvider (Data Streams) prices — this is a proper staleness check on the DON-signed timestamp. However, ChainlinkPriceFeedProvider (used as deviation reference) does NOT check updatedAt from latestRoundData() — it explicitly uses current block.timestamp. This means the reference price used in the circuit breaker could be stale. Data cache shows some feeds have 86400s heartbeat (BTC, ETH, USDC, AVAX) — potentially stale for up to 24h in the deviation reference.
Detail #
Oracle.sol: `maxPriceAge` check on GmOracleProvider timestamps — confirmed present. ChainlinkPriceFeedProvider.sol source comment: 'the timestamp returned is based on the current blockchain timestamp this is because Chainlink on-chain price feeds have a lower update frequency'. No updatedAt comparison to block.timestamp - maxStaleness in ChainlinkPriceFeedProvider. Template: yellow = staleness check present but with gaps (reference feed has no staleness check).
Sources #
- GitHub
- ChainlinkPriceFeedProvider.solChainlinkPriceFeedProvider.sol — no staleness check on updatedAt, uses block.timestampretrieved 2026-05-05
Methodology #
Determine whether the protocol rejects oracle reads older than a declared maximum age (i.e., checks `updatedAt > block.timestamp - maxStaleness`).
See the full factor methodology and distribution across all protocols →