External keeper/relayer not redundant
StakeWise v3'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 #
The Keeper oracle network (11 operators) provides meaningful redundancy for the keeper/relayer function: any 5 nodes can be simultaneously offline without halting reward updates (6-of-11 quorum). Operators are independent entities (P2P, Gnosis, DSRV, Chorus One, Bitfly, Finoa, Telekom, Gateway.fm, Stake.Fish, Senseinode + StakeWise Labs per docs). However, no automated fallback exists if quorum fails; the entire reward-update and exit-processing mechanism halts without degraded-mode operation. Scored yellow: meaningful redundancy via multi-node design, but single-mechanism dependency with no failover if quorum not reached.
Sources #
- URLAnnouncing StakeWise v3 — Mediumv3 launch announcement: oracle operators named — P2P, Gnosis, DSRV, Chorus One, Bitfly, Finoa, Telekom, Gateway.fm, Stake.Fish, Senseinoderetrieved 2026-05-16
- Oracles | StakeWise DocsStakeWise oracle docs: 11 oracle operators, 6-of-11 rewards quorum, 8-of-11 validators quorum; named operators listedretrieved 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 →