IIP-45: Delegation of FLI Parameter Changes

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.


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.

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


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.


+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)

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 @DevOnDeFi and the entire design crew!) and give them the leeway to effectively make decisions.


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.


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

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.


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).


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


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.


Certainly should be considered as an option.

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,

Snapshot vote is now live:




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.


  • what has worked?
  • what can we do better?

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

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

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.


I agree completely that the pod structure and delegated decision-making authority have been successful thus far, and I also agree that we need to improve transparency / accountability efforts with the community now that we have our bearings!

As @afromac mentioned, we’ve already begun strategizing how to share out the tools, techniques, and metrics that we’re collating and creating so that the community can understand what we’re working on and how we’re working. In accordance with the Coop’s way of working, we want to maximize the visibility that the community has into our processes so that they can understand, support, and challenge us as needed. This is the biggest area of improvement for the pod from my point of view and it’s a logical iteration for the next quarterly(ish) commission!