Oracle staleness check present
stHYPE (Valantis Labs)'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 #
No explicit staleness check on the l1Balance parameter in rebase(). The ABI shows lastRebaseTime() and syncInterval() state variables, suggesting time-based cadence, but no on-chain staleness rejection of the input value is evident from the function signature. Staleness protection relies on keeper reliability, not contract enforcement. Yellow: absence of on-chain staleness check on keeper-submitted balance.
Sources #
- GitHubOverseerV1 ABIoverseerV1.json ABI — lastRebaseTime() and syncInterval() present but no staleness-check function for l1Balance inputretrieved 2026-05-17
- stHYPE Roles and Controls Registryroles-and-controls-registry: REBASER_ROLE is the only address permitted to call rebase; no permissionless pathretrieved 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 →