External keeper/relayer not redundant
Babylon Protocol'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 #
Vigilante relayer is the external keeper analog for BTC header relay. Permissionless mitigation: any operator can run a vigilante instance and submit valid BTC headers via MsgInsertHeaders. However no on-chain registry of active vigilante operators found; in practice relayer set is small and operator composition is not publicly enumerated. IBC relayers for BSN coordination are similarly permissionless but unregistered. Gap: cannot confirm multi-party vigilante operation from available public data.
Sources #
- GitHubBabylon Vigilante repositoryVigilante README — permissionless deployment, four components: Submitter, Reporter, BTC Timestamping Monitor, BTC Staking Trackerretrieved 2026-05-04
- Babylon x/btclightclient modulex/btclightclient — accepts MsgInsertHeaders from any sender with valid PoW proofretrieved 2026-05-04
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 →