External keeper/relayer not redundant
Superstate'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 NAV Calculation Agent (NAV Fund Services, off-chain) functions as the sole data pusher to the SuperstateOracle. Only the Ownable2Step owner can call addCheckpoint() — single keeper, no Gelato/Chainlink Automation redundancy. Pyth feeds: Pyth publisher network provides some redundancy (multiple publishers per feed) but Superstate has no direct control. No keeper redundancy documented for the on-chain checkpoint submission. Yellow: single keeper (NAV Fund Services) with no fallback; protocol would halt on keeper failure for the 5-day checkpoint window.
Sources #
- EtherscanSuperstateOracle readContract — EtherscanSuperstateOracle 0xe4fa682f... readContract — owner = 0x4B1df64357a5D484563c9b7c16a80eD8B8fB1395; addCheckpoint() is onlyOwner; no keeper registry in ABIretrieved 2026-05-16
- Superstate Documentation (full LLM text)docs.superstate.com/llms-full.txt — 'NAV Calculation Agent whenever a new Net Asset Value per Share is calculated' as oracle update trigger; single off-chain entityretrieved 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 →