Enforcing SlingshotV3 requirements - Timeline
- Phase 0:
- đź“ŁÂ Phase 1: Announce upcoming tracking
- Timeline: December
- Include details on what metrics will be tracked, how it will be enforced in the future
- đź“ť Phase 2: Tracking, sharing results with SPs, refining
- Timeline: December - Q1
- Use validation bot to gather metrics
- Retrieval DSR
- Running Booster bitswap
- Using Indexer
- Announce results in Slack, both top performers and violators
- Follow up with violators, remove all bugs related to retrieval software / booster bitswap and indexer
- Conditions for moving to enforcing:
- 👮‍♀️ Phase 3: Enforce booster bitswap & indexer
- Timeline: Q1 (aggressive), Q2 (more likely)
- Out of compliance SPs are suspended for <4 weeks of dealmaking / requirements are met
- i.e., booster bitswap is installed and indexer is used
- 🚔 Phase 4: Enforce retrievals
- Timeline: when errors in requests related to software failures is less than [5%] of all errors
- First, put bottom 10% (by picking a % of DSR as the main metric) of SPs on probation until they fix retrieval issues
- When ready, enforce retrievability at 85% success rate (2 week rolling average)
- Out of compliance
- Violators of retrievability requirement will be suspended from participation for 4 weeks
- During the suspension, SPs do not get new deals but are expected to provide retrievals to rebuild their metrics
- Keep the number of suspension weeks by a few weeks longer than the number of assessment weeks to prevent gaming the system
- Violation is defined as:
- Not maintaining 85% DSR for retrievals OR
- Not running Booster bitswap OR
- Not using Indexer
- Mechanics
- Originally, run the query against Validation bot postgres database 1x week
- Identify a set of “white listed” SPs and plug them into Spade on a weekly basis
- Not expecting to have this process automated so will need to create a manual process of updating a white list of SPs
- Announce SPs considered violators in Slack
- Potentially maintain a dashboard of SPs standings