Oracle staleness check present
StakeWise v3'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 consumer-side staleness check detected. The PriceFeed adapter wraps getRate() with no `updatedAt` timestamp comparison or maximum-age rejection. OsTokenVaultController does not expose a `lastUpdated` timestamp that the PriceFeed checks. The Keeper enforces a minimum-cadence floor (`rewardsDelay = 43200s`) between updates but there is no maximum-age ceiling that causes the system to reject or flag a stale rate. If the oracle network becomes unresponsive for >12h, PriceFeed continues to return the last-known rate without any staleness signal to downstream consumers (Aave CAPO adapter may implement its own check, but that is external to StakeWise).
Sources #
- GitHubKeeperRewards.sol — stakewise/v3-coreKeeperRewards.sol: rewardsDelay = 43200s enforces minimum update cadence (floor only); no maximum-age staleness rejection on consumer sideretrieved 2026-05-16
- PriceFeed — Etherscan sourcePriceFeed source: latestAnswer() calls getRate() without any staleness/updatedAt checkretrieved 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 →