Proposal: Create a throttle on complex Implementation starts

Summary:

Prioritize complex YIP’s and throttle the rate of implementations starting so that the development team have time to get things tight first time. This would be done by Setting an exception of delivery schedule and slowing off chain votes to assign priority. Minor tweaks and emergency changes would be excepted.
.

Abstract:

We have a very active community with many proposals for new pools, strategies and more complex implementations. While some are relatively trivial to implement, others require significant development and testing (e.g. SNX with 12 month vesting).

The proposal is to set a timeframe for implementation of complex YIP’s so that each can be given adequate attention before it is implementated. When new YIPs are agreed, there should be an off chain vote to assign it to the place in the current queue.
.

Motivation:

It’s easy to propose the addition of new tokens, or new strategies to the YFI community. However, development of the final code, testing and debugging prior to implementation takes time and focused attention.

There may be an expectation that YIP’s can be implemented immediately (when there may be external prerequisites) and in YIP number order when some later YIPS may be better done sooner…

This proposal is intended to allow the development team breathing space to focus while allowing YFI governance to prioritise what we want to start implementing next.

For example. we have an agreed pipeline for the following on the 21st of September

  1. YIP AA Create ETH delegated vault (implementation started 1st September)
  2. YIP CC Implement new strategy for YFI vault (due to start on 22nd September)
  3. YIP BB Create SNX delegated vault
  4. YIP DD Create AAVE delegated vault

On the 22nd September this changes to

  1. YIP AA Create ETH delegated vault (implementation started 1st September)
  2. YIP CC Implement new strategy for YFI vault (implementation started 22rd September)
  3. YIP BB Create SNX delegated vault
  4. YIP DD Create AAVE delegated vault

Between the 23rd sept and 12th October, we offchain vote to re prioritise the pipeline which includes the existing pipline and any new YIP’s for implementation. So by the 12th Oct we have a new pipeline:

  1. YIP AA Create ETH delegated vault (implementation started 1st September)
  2. YIP CC Implement new strategy for YFI vault (implementation started 22rd September)
  3. YIP NN Create wBTC delegated vault (due to start on 13th October)
  4. YIP DD Create AAVE delegated vault
  5. YIP BB Create SNX delegated vault (note changed position)

As an option, the development team, could request an early vote to allow starting the next project early (i.e. they have capacity to start the next YIP).

The prioritisation vote may also allow the community to identify redundant / duplicate YIP’s to be downgraded so they can be removed before implementation (I would assume that this would need a further onchain / YIP specific vote to remove the prior YIP approval).

The delay between a YIP approval and the prioritisation to the top of the pipeline also allows the community / developers to consider the implementation of each YIP and feedback to the community during the prioritisation vote so new information can be considered (e.g."YIP QQ will be difficult until this external action has happened).

This proposal covers the scheduling of implementation start dates, it’s accepted that different YIP’s will take different times to be deployed after the start date.
.

Specification:

  • All implementation of this proposal will be off chain.
  • The development team will start work implementing a new complex YIP every 21 days.
  • Prior to starting a new YIP implementation, YFI holder vote offchain to prioritise the approved YIP’s that have not been started yet.
  • Once started, a YIP implementation would be expected to progress to completion.
  • While approved YIPs can be deprioritised based on a offchain vote, this does not remove the approval (which would require a specific onchain vote to de-approve)

Minor change YIPs, off chain YIPs and emergency YIPs would be excluded from the proposed queue system.

Implementation schedule is a suggestion, and can be adjusted based on available development team resource.

For:
Sets expectations for the community in terms of implementation starts and hopefully allows the development team time to focus on agree implementations.
Allows community to prioritise YIP’s that have been approved.
Can also allow for redundant / duplicate YIP’s to be identified for pruning

Against:
Adds complexity to governance.
May delay some projects from implementation compared to a first in first out system.
.

Poll:

a) Set 21 day schedule for starting complex YIP’s with community prioritisation on what is started next.
b) Set a schedule for starting complex YIPs, but a shorter time period (TBA) with community prioritisation on what is started next.
c) Set a schedule for starting complex YIPs, but a longer time period (TBA) with community prioritisation on what is started next.
d) No change to the current practice for scheduling implementation of complex YIP’s

7 Likes

This sounds like a good idea.

I like it. Have good roll over to access other avenues.