Oracle staleness check present
Rocket Pool'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 #
Neither RocketTokenRETH.sol (consumer of rETH:ETH rate) nor any known consumer contract checks 'updatedAt > block.timestamp - maxStaleness' before using oracle values. RocketNetworkBalances.sol enforces minimum time BETWEEN submissions (95% of configured interval) but does NOT reject reads if the last update is old. Consumers use the last stored value unconditionally — if oDAO goes offline for days, the protocol silently uses a stale price without reverting. RocketNetworkPrices.sol imposes no staleness guard on RPL price reads either. This is the only red factor in Cat 3.
Sources #
- GitHubRocketNetworkBalances.sol sourceRocketNetworkBalances.sol: submission frequency enforced (95% of interval) but this is not a consumer-side staleness checkretrieved 2026-05-04
- RocketNetworkPrices.sol sourceRocketNetworkPrices.sol: no staleness check on price reads; only prevents future-block submissionsretrieved 2026-05-04
- RocketTokenRETH.sol sourceRocketTokenRETH.sol getEthValue(): no updatedAt check before reading totalETHBalance; no maxStaleness parameterretrieved 2026-05-04
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 →