Oracle staleness check present
Kinetiq'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 #
OracleManager implements MAX_ORACLE_STALENESS (3,600s / 1hr, adjustable by MANAGER_ROLE via setMaxOracleStaleness). Data from adapters older than this threshold is skipped with OracleDataStale event. Partial credit: staleness check exists for adapter data input layer. However: (a) applies to validator performance data, not to exchange rate freshness; (b) if all adapters are stale, generatePerformance silently skips — no revert, no protocol pause; (c) StakingAccountant has no independent staleness guard on the rate itself. Yellow: staleness check present but incomplete (no rate-level guard, no auto-pause on full staleness).
Sources #
- GitHubKinetiq OracleManager.solOracleManager.sol: setMaxOracleStaleness(uint256 newStaleness) onlyRole(MANAGER_ROLE); OracleDataStale event; MAX_ORACLE_STALENESS initialized to 3600sretrieved 2026-05-17
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 →