★ Immutable oracle address
stHYPE (Valantis Labs)'s assessment for RD-F-180 — scored not_applicable on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
[★ CRITICAL — NOT_APPLICABLE] No oracle adapter address exists in stHYPE. Confirmed: no oracle state variables, no setOracle function, no oracle adapter in OverseerV1 or stHYPE ABIs. The rebase uses the Hyperliquid L1 precompile (system infrastructure at 0x0800+ range) — not a third-party oracle with a configurable/immutable address. Per PD-023 substrate-generalization: the precompile address is Hyperliquid L1 system infrastructure analogous to Ethereum precompiles (0x01-0x09), not a removable oracle adapter. F180's failure mode (lending cannot reprice when asset depegs because oracle address is immutable) does not apply to this LST: there is no pricing oracle, no lending market, and no oracle address to be immutable.
Sources #
- URLHyperliquid Docs — Interacting with HyperCoreHyperliquid HyperEVM precompile docs — 0x0800+ addresses are Hyperliquid L1 system contracts, not third-party oracle adaptersretrieved 2026-05-17
- OverseerV1 ABI (ValantisLabs/sthype-sdk)overseerV1.json ABI — no oracle address state variable, no setOracle function; l1read() and l1write() return system precompile references, not oracle adaptersretrieved 2026-05-17
- stHYPE Roles and Controls Registryroles-and-controls-registry — no oracle configuration role listed; no setOracle role or oracle-admin role existsretrieved 2026-05-17
Methodology #
Determine whether any collateral oracle address is marked `immutable` in protocol config with no admin-replaceable adapter wrapper, preventing the protocol from repricing when the upstream asset depegs.
See the full factor methodology and distribution across all protocols →