Oracle staleness check present
Liquid Collective (LsETH)'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 #
Partial staleness protection. Oracle.1.sol implements an epoch-sequence check (if (_report.epoch < lastReportedEpochValue) reverts with EpochTooOld) preventing submission of reports from prior epochs. This is an epoch-monotonicity guard, not a wall-clock staleness check. There is no updatedAt > block.timestamp - maxStaleness style guard. If Oracle Operators stop reporting, River continues using the last accepted conversion rate indefinitely with no on-chain alert or automatic halt. The 24-hour reporting cadence is an off-chain convention, not an enforced on-chain freshness bound.
Sources #
- GitHubLiquid Collective Oracle.1.sol sourceOracle.1.sol reportConsensusLayerData() — epoch comparison guard (EpochTooOld); no block.timestamp staleness checkretrieved 2026-05-17
- Liquid Collective Architecture DocsOracle reports every 24 hours; cadence is operational convention not on-chain enforcedretrieved 2026-05-17
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 →