Fallback behavior on oracle failure
StakeWise v3's assessment for RD-F-051 — scored red on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
No fallback behavior on oracle failure. KeeperRewards.sol _verifySignatures() reverts if fewer than rewardsMinOracles (6 of 11 per docs) submit valid signatures. KeeperOracles.sol analysis confirms: no secondary oracle path, no last-known-price fallback, no degraded-mode pause. If oracle quorum is not met, updateRewards() call fails; vault state (avgRewardPerSecond) stalls at last valid update. Exit processing (validator approvals) also stalls — requires 8-of-11 signatures. No circuit-breaker pause or graceful degradation is implemented in KeeperRewards or KeeperOracles. StakeWise docs confirm: 'no manual actions involved' (oracles are automated) but provide no fallback description.
Sources #
- GitHubKeeperOracles.sol — stakewise/v3-coreKeeperOracles.sol: _verifySignatures enforces requiredSignatures > 0 and oracle set; insufficient sigs = revert; no fallback pathretrieved 2026-05-16
- KeeperRewards.sol — stakewise/v3-coreKeeperRewards.sol: _verifySignatures rejects if below threshold; no alternative path; no fallback on quorum failureretrieved 2026-05-16
- Oracles | StakeWise DocsStakeWise oracle docs: oracles run automatically; no fallback mechanism describedretrieved 2026-05-16
Methodology #
Identify the declared fallback behavior (pause, secondary source, last-known-price, revert) when the primary oracle reverts or reports a stale value.
See the full factor methodology and distribution across all protocols →