External keeper/relayer not redundant
Jupiter Perpetual Exchange's assessment for RD-F-062 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
Doves oracle primary update path is centralised: the updateWithSigner instruction requires signature from Chaos Labs controlled key. If the Chaos Labs keeper goes offline, Edge/Doves primary oracle goes stale and fallback to Chainlink+Pyth activates. The three-oracle fallback architecture provides oracle-level redundancy, but the primary oracle keeper is a single entity (Chaos Labs). Pyth and Chainlink maintain their own keeper networks. Rated yellow because: (a) single-entity primary keeper is a non-trivial dependency on Chaos Labs operational continuity; (b) fallback exists and is documented; (c) impact of Edge keeper outage is degraded (not halted) oracle quality as long as CL+Pyth remain fresh.
Sources #
- URLChaos Labs Edge Oracle — Keeper ArchitectureChainwire 2024-09-12 — Chaos Labs described as operator of Edge oracle protocol with dedicated keeper for Jupiter Perps price updatesretrieved 2026-05-16
- Doves IDL — updateWithSigner InstructionDoves IDL updateWithSigner instruction — signature-gated price update, Chaos Labs controlled single update path for primary oracleretrieved 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 →