Oracle staleness check present
Morpho V1 (Morpho Blue + MetaMorpho)'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 #
No on-chain staleness check in ChainlinkDataFeedLib. Library comment explicitly states: 'Staleness is not checked because it is assumed that the Chainlink feed keeps its promises on this.' Only answer field from latestRoundData() is used; updatedAt is not validated. Partial mitigation: Chainlink feeds have heartbeat SLAs (ETH/USD 3600s, BTC/USD 3600s).
Detail #
The ChainlinkDataFeedLib calls latestRoundData() and extracts only the answer. The updatedAt timestamp is not compared to block.timestamp - maxStaleness. This is confirmed by multiple web search sources citing the library comment and by source inspection of the deployed oracle contract (0x48F7E36EB6B826B2dF4B2E630B62Cd25e89E40e2). Template: yellow = staleness check present but threshold >3600s (in this case: no threshold at all, but Chainlink SLA provides de-facto staleness bound).
Sources #
- URLmorpho-blue-oracles GitHubWeb search confirming ChainlinkDataFeedLib staleness delegationretrieved 2026-04-27
- Morpho Chainlink Oracle USDC - wstETH — EtherscanChainlinkOracleV2 instance 0x48F7E36EB6B826B2dF4B2E630B62Cd25e89E40e2 — no staleness check in price()retrieved 2026-04-27
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 →