External keeper/relayer not redundant
Liquid Collective (LsETH)'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 #
Oracle reporting is not keeper/relayer-based. Oracle Operators directly call reportConsensusLayerData() — they are permissioned enterprise entities (Coinbase Cloud, Figment, Staked, Blockdaemon), not Gelato/Chainlink Automation bots. No IKeeperRegistrar or IAutomation interface found in Oracle.1.sol. Individual operator failure does not halt protocol (only quorum matters); multiple enterprise entities provide redundancy. No single keeper/relayer with no failover.
Sources #
- GitHubLiquid Collective Oracle.1.sol sourceOracle.1.sol — no keeper/relayer interface; direct operator calls to reportConsensusLayerData()retrieved 2026-05-17
- Liquid Collective Roles & Staking Infrastructure DocsOracle Operators are infrastructure providers (Coinbase Cloud, Figment, Staked, Blockdaemon) reporting Beacon dataretrieved 2026-05-17
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 →