Fallback behavior on oracle failure
Superstate's assessment for RD-F-051 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
No automatic fallback oracle on any chain. SuperstateOracle has CHECKPOINT_EXPIRATION_PERIOD = 430,080s (5 days) — data expires without new checkpoint. RedemptionIdle has maximumOracleDelay (staleness gate) that reverts on stale data — protective but halts operations, no fallback to secondary source. Pyth Solana: Pyth native confidence interval but no protocol-side fallback. Superstate docs: 'No explicit fallback mechanisms are documented.' Fallback classification: revert/halt rather than secondary-source. Yellow: no secondary oracle source, primary failure causes operational halt.
Sources #
- EtherscanSuperstateOracle readContract — EtherscanSuperstateOracle 0xe4fa682f... readContract: CHECKPOINT_EXPIRATION_PERIOD = 0x0206978081 (430080 seconds ≈ 5 days); no fallback oracle address state variable visibleretrieved 2026-05-16
- 0xMacro superstate-4 Audit Report0xMacro superstate-4 L-2: missing validation for maximumOracleDelay > 0 at subscribe time — fixed; confirms staleness-check mechanism but no fallback pathretrieved 2026-05-16
- Superstate Documentation (full LLM text)docs.superstate.com/llms-full.txt — explicit: 'No explicit fallback mechanisms are documented. The content does not outline staleness thresholds... or automatic fallback mechanisms if primary oracles fail.'retrieved 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 →