IIP-45: Delegation of FLI Parameter Changes

Governance Proposal
1

IIP: 45

Title: Delegation of FLI parameter changes

Status: Proposed

Author: @overanalyser

Created: May 22, 2021

Edited 26 May 2021
Edit changes the proposed process - see reply below for details,=

Simple Summary

To delegate FLI parameter management to a small team of subject matter experts from DeFi Pulse, Set Labs, and the Index Coop community.

Abstract

Identify a small work team representing the methodologist (DeFi Pulse), engineering (Set Labs) and Index Coop contributors who will be given the authority to make changes to FLI product parameters.

In order to maintain complete transparency and accountability to the community, all changes must be posted to the forum 24 hours in advance of the change being made.

The team may make emergency changes (implemented immediately after posting on the forum), in the event of an emergency change, a new IIP will be required to document the emergency and to reaffirm the communities support of the FLI working groups actions.

This delegation of responsibility will expire on the 31st July 2021.

Motivation

There are a number of FLI parameters that can be modified by the manager contract including:

  • Supply cap
  • Max trade size
  • Rebalancing exchange venue
  • Slippage tolerance during rebalances

These parameters allow new FLI products to be introduced to the market in a controlled way, and their behaviour modified as we observe them in action. More details on the strategy behind FLI parameter updates can be found here.

Until now, FLI parameter changes have been controlled by the IIP process. This process has resulted in many IIP’s and it introduces a significant delay between the identification of a need and its actual implementation. Examples include:

  • IIP-20: increase supply cap for ETH2x-FLI from 50,000 to 100,000 units
  • IIP-23: increase supply cap for ETH2x-FLI from 100,000 to 200,000 units
  • IIP-30: increase supply cap for ETH2x-FLI from 200,000 to 400,000 units
  • IIP-37: Tighten window and increase recentering on BTC2-FLI
  • IIP-42: Raise supply cap on ETH2x-FLI from 400,000 to 600,000 units
  • IIP-44: Raise supply cap on BTC2x-FLI from 200,000 to 400,000 units

Because the majority of Coop members do not consider themselves FLI experts, many members defer to the IIP proposer / blindly vote yes. As a result, the current IIP process is effectively one of delegation to subject matter experts but with additional friction.

The motivation is to allow the subject matter experts to manage FLI products in a more frictionless way and to allow more rapid, responsive changes to product parameters.

Specification

The FLI work team will be comprised of individuals within three sub groups:

The process will be:

  1. The FLI work team will discuss and identify parameter change requirements via discord / calls etc.
  2. One member of the FLI work team will post a short description of the reasoning for the change to the forum and state that the FLI work team is in agreement (a poll is not required).
  3. At least 24 hours notice in the forum without any dissent from a FLI team work Team member.
  4. The change can then be made once these criteria are met.

In scope parameters include:

  • Supply cap
  • Max trade size
  • Rebalancing exchange venue
  • Slippage tolerance during rebalances

Out of scope parameters include:

  • Changes to the bot whitelist parameter (e.g. IIP-39)
  • Fees of the product

This delegation will expire on the 31st July 2021.

IIP vote specification:

FOR

  • Create a FLI work team and delegate parameter control to the specified individuals

AGAINST

  • No change; continue managing FLI product parameters via IIP process
19 Likes
2

I’m aware that @MrMadila and @dylan are working on a discussion of how the coop can restructure / delegate responsibilities, so this may be jumping the gun a little and we may need to modify the proposal before the snapshot.

However, I wanted to get this into the system and progressing.

All thoughts and opinions welcomed.

3 Likes
3

Awesome post OA. I think this IIP models many critical features that we should roll forward in future delegations of power:

  1. Decision making powers should be delegated for a finite period. The delegation period shouldn’t be excessive. This ensures the Coop is actively consenting to continued delegated decision making.
  2. The scope of delegated powers and any non-delegated powers is specified clearly.
  3. The delegated team regularly reports on any decision they make.
  4. The final yes/no decision making process is clearly specified. For other working groups, this could be simply the WG leader or WG leader + core have final say.
6 Likes
4

Thanks @dylan, My first draft was greatly improved by @allan.g and @puniaviision 's review.

3 Likes
5

I think it’s important to note that many of the FLI-related pain points we’ve experienced recently (ex. supply caps) could be avoided in the future if these parameter updates are delegated. We can proactively monitor the parameters and react within 24-hours if necessary, which is far more efficient than the 1-2 weeks that it takes today to effectively make a change.

Maintaining transparency and accountability with the community is the top priority, and ensuring seamless user experience with FLI products is right behind it.

4 Likes
6

+1 to everything @dylan said :clap:

and gotta double click on how impactful the expiration date is – it enables us to move quickly, make decisions, and know that we will need to revisit in the near-future based on what we learn.

I love the intent here, and I will flag that perhaps the “community member dissent” line can be sharpened a bit.

  • What specifically will happen if 1 person from that large group dissents?
  • Maybe the “dissent” clause can be closer to, “If there is dissent from a FLI Work Team Member, then…” vs. the broader group (DeFi Pulse, Set employees, Gold/Silver/Bronze)
5 Likes
7

Strong vote yes - great work @overanalyser :rocket:. Streamlining operational decision making is a key capability as Index Coop scales. FLI parameter updates are the perfect example of operational decisions that happen routinely and require high context. These decisions are different from long-term strategic discussions. Delegating authority around operational decisions will free up significant community bandwidth.

Another important point that OA makes is that the majority of the Coop do not consider themselves FLI experts. This is ok! As our organization continues to scale much of the work that occurs in WG groups requires a high amount of context. Our organization is simply growing to big for any individual to have a fully formed opinion on every project or initiative.

We should always strive to improve our understanding of the protocol - but we also need to have the intellectual humility to recognize the true subject matter experts working in a number of verticals ( shout-out @0x_Dev and the entire design crew!) and give them the leeway to effectively make decisions.

3 Likes
8

Agree that this line is likely the last thing that needs to be sharpened before we make this IIP proposed! I think it should be limited to the FLI Work Team/core stakeholders as well.

2 Likes
9

We will discuss in today’s Org call, I’m hoping to have agreed phrasing for the IIP by the end of the meeting.

1 Like
10

OK following the org call:

Initial draft as posted on the 22 May 2021:

  1. The FLI work team will discuss and identify parameter change requirements.
  2. One member of the FLI work team will post a short description of the reasoning for the change to the forum (a poll is not required).
  3. Other members of the FLI work team should comment on the forum post to indicate that they support the change.
  • A minimum of at least 1 individual from each sub group (i.e. Set, DeFi Pulse, Index Coop) must post their support for the change.
  1. At least 24 hours notice in the forum without any dissent from a Coop community member (DeFi Pulse, Set employees, or Gold, Silver, or Bronze Owls from the Index Coop Community)
  2. The change can then be made once these criteria are met.

Revised wording for the IIP:

  1. The FLI work team will discuss and identify parameter change requirements via discord / calls etc.

  2. One member of the FLI work team will post a short description of the reasoning for the change to the forum and state that the FLI work team is in agreement (a poll is not required).

  3. At least 24 hours notice in the forum without any dissent from a FLI team work Team member.

  4. The change can then be made once these criteria are met.

The change is to reduce the friction of the process and to allow the best people to do their jobs with optimistic governance.

4 Likes
11

With the removal of the cap yesterday, it’s a good idea to consider how much time we might have until the cap is reached again. This is solely for ETH2X-FLI here as that’s all I have enough data for.

I took three measures of average daily mint volume to get potential time-frames until we next reach the cap based on how much demand we might see.

Low Demand Medium Demand High Demand
Coins minted per day 8,000 12,000 19,000
Days until cap reached 25 17 11
Date cap reached June 20 June 12 June 6

The estimates are based on 7 day rolling averages taken at April 4th, May 5th and May 18th respectively.

I thought it might be helpful for everyone to be aware of these time horizons while we move forward with a decision (and the processes associated with it).

2 Likes
12

I wonder if we should vote on another increase but delay execution until the cap is reached?

4 Likes
13

Thanks for breaking this down @afromac . As of this moment (12.50pm US EST), there have been ~34,000 units minted sinced we raised the cap yesterday evening (less than 24 hours). If we continue at this rate, we’ll hit the cap by the beginning of next week.

To be fair, there seemed to be pent-up demand for ETH2x-FLI so this mint rate may fall, but either way, I think we need to move forward with voting on this proposal OR draft another IIP to raise the supply cap again in case we can’t get the vote through in enough time to respond to the cap being reached.

2 Likes
14

Certainly should be considered as an option.

15

I’m expecting this IIP to go to Snapshot on Tuesday (Holiday weekend), At current rate, the supply cap will be reached in #10 days,

16

Snapshot vote is now live:

https://snapshot.org/#/index-coop.eth/proposal/QmeBLQBrtAukRwsv8235xc8HA21i3bL7xEThHhcAWNAhSh

3 Likes
17

All,

We are nearing the end of the life of this IIP.

I’ll be drafting a new IIP to extend this. However, I think it would be good to get any feedback on the procedure we have been using to manage the parameters and communicate them to the coop.

So,

  • what has worked?
  • what can we do better?
2 Likes
18

From a community member POV, seems like this has worked great. Having a trusted team of experts make decisions transparently seems to work :+1:

I’d be curious from your insider-POV, did this IIP achieve what you hoped it would? If not, how can it improve?

1 Like
19

Hi Greg, Good question.

Yes, I think it has allows the

Personally, I see the Leveraged Products Pod is working great, they are on top of the products and can adapt the parameters as USDC:ETH liquidity becomes available for rebalances (now uni v3 can be used, soon multiple pools at the same time…).

I think the notification/delay/parameter change process in the IIP works,;it’s visible what we plan to do, and people seem happy to let the team run it.

I can see scope for improvement around the visibility of what was changed / when. Forum posts cross-referencing each other isn’t the best solution. But this is a very minor pain point, and only for those who want to get into the weeds of the parameter history.

Overall, I think the IIP has been successful in reducing governance overhead, and allowing safe expansion of supply caps.

@afromac @emault @tgreco @allan.g What do you guys think?

1 Like
20

Thanks for the vote of confidence, OA.

I would agree with this. From my perspective, we have a good handle on the methodology for assessing risk, and we are able to proceed through the process of updating parameters quickly enough to grow the products and communicate our understanding. We haven’t received any pushback on any updates, but I would be very interested to know what people think about the process so far. What can we improve on from the community’s perspective etc.

I would agree that we could improve visibility around our decision making and provide it in a more digestible format to the community. A serious discussion in pod right now is how we can improve this. A lot of time and work in this early stage was focused on getting up to speed with the task, but now that we have more confidence and experience in the process, I believe we will be able to vastly improve communications around parameter changes, and risk management in general, in the very near future.

I would also add that the system in place works fine for 2 FLI products, but in the very near future where we may have 5-10 products, it could be too inefficient to work at that scale.

Again, this is a major focus in the team right now and we hope to be able to present a massive overhaul to the process in the coming months.

2 Likes