defirisk.co
rubric v1.7.0

Oracle staleness check present

Lido'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 #

Frame-based deadline enforcement exists (StaleReport() reverts late submissions) but there is no consumer-side staleness rejection if reporting simply lags — stETH ratio just doesn't update. No maxStaleness check on oracle output consumption.

Detail #

HashConsensus/BaseOracle: 'if (_getTime() > deadline) revert ProcessingDeadlineMissed(deadline)' — prevents late submissions. However if oracle committee simply doesn't submit (below quorum), there is no on-chain mechanism that rejects use of a stale stETH rate. The stETH ratio remains at the last reported value indefinitely until the next successful oracle report.

Sources #

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 →

rubric_version v1.7.0 protocol lido factor RD-F-059 score yellow collected_at 2026-04-28 13:58:42