Oracle staleness check present
BENQI's assessment for RD-F-059 — scored red on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
NO on-chain staleness check confirmed in BenqiChainlinkOracle. Snowscan source analysis shows the contract calls `latestRoundData()` and uses the returned price without validating the `updatedAt` timestamp against a maximum staleness threshold. Eight of nine feeds have a 86400s (24hr) heartbeat — during this window, stale prices are accepted silently. The AVAX/USD feed (120s heartbeat) is also unguarded. Dedaub BENQI Ignite audit (March 2023) found a Medium-severity 'No staleness check on Oracle returned values' in the Ignite contract (separate module); marked resolved in Ignite but BenqiChainlinkOracle was not in Dedaub's scope and shows the same pattern. The Chainlink best-practice of checking `updatedAt > block.timestamp - maxStaleness` is absent from this contract.
Sources #
- AuditDedaub BENQI Ignite Audit Report (2023-03-28)Dedaub BENQI Ignite audit M1: No staleness check on Oracle returned values — same pattern identified in Ignite contract (resolved), analogous to BenqiChainlinkOracleretrieved 2026-05-16
- 0xMacro: How To Consume Chainlink Price Feeds SafelyChainlink oracle staleness best practice — updatedAt check requiredretrieved 2026-05-16
- BenqiChainlinkOracle verified source (Snowscan)BenqiChainlinkOracle 0x316aE55EC59e0bEb2121C0e41d4BDef8bF66b32B — latestRoundData() called, no updatedAt validation in getUnderlyingPrice()retrieved 2026-05-16
- Cache oracle_feeds — 24hr heartbeatsrisk-dashboard/.research/protocols/benqi/00-data-cache.json §sources.oracle_feeds — heartbeat_seconds: 86400 for 8/9 feedsretrieved 2026-05-16
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 →