External keeper/relayer not redundant
OpenEden's assessment for RD-F-062 — scored green on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
No external keeper/relayer dependency identified. Vault epoch updates (updateEpoch calls) originate from operator EOA or admin addresses directly — not Gelato, Chainlink Automation, or any third-party keeper service. Centralized operator model; not a keeper dependency. The operator is permissioned (RWA model), so single-operator reliance is a governance risk (assessed separately), not a keeper-redundancy risk under F062.
Sources #
- InternalOpenEden protocol profile §7Profile §7: no keeper service dependency documented; operator EOA 0xdBC3C410... identified as interacting with vault stateretrieved 2026-05-16
- TBILL Vault Proxy — Etherscan tx historyTBILL Vault 0xdd50C053... transaction history: updateEpoch calls originate from operator addresses; no Gelato/Chainlink Automation contracts in call chainretrieved 2026-05-16
Methodology #
Determine whether the protocol depends on a single keeper or relayer (Gelato, Chainlink Automation, custom) with no redundancy or failover.
See the full factor methodology and distribution across all protocols →