Oracle staleness check present
Lombard Finance'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 #
Chainlink BTC/USD heartbeat: 3600s (acceptable for volatile assets). Lombard's own oracle-consuming code paths do not appear to check updatedAt > block.timestamp - maxStaleness explicitly — LBTC minting is Consortium-authorized, not price-oracle gated, so minting does not directly call Chainlink. StakedLBTCOracle uses switchTime-based model without explicit block.timestamp staleness revert for stale ratio data. Downstream consumers (lending markets) are responsible for their own staleness checks. Yellow: Chainlink 3600s heartbeat is acceptable; no explicit staleness revert found in Lombard's own oracle-consuming code paths; StakedLBTCOracle uses time-switching model without staleness revert.
Sources #
- Etherscan
- Lombard StakedLBTCOracle sourceStakedLBTCOracle.sol — switchTime model without staleness revertretrieved 2026-05-05
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 →