IIP Contribution Process

Governance
1

IIP Contribution Process

This document outlines the end to end process for IIP contributors.

Resources

IIP Github Repository
IIP-0 Guidelines
Example IIP

Context

The IIP process is not just about fulfilling Index Coop’s functional duties. A streamlined and accessible IIP process can help cultivate a community which values open collaboration and ensure contributions are recognized and given a clear path to success.

Objectives

  • Make the path for community contribution simple, accessible, and achievable
  • Set clear guidelines for “next steps” at each stage of proposal process
  • Demonstrate contribution efforts are valued and put to good use

Workflow

image
image1262×372 75.4 KB

In the early stages of Index Coop, Snapshot voting may be skipped for proposals which achieve super majority agreement on the forum proposal

Discord & Forum

This is the initial fielding research + discussion on Discord, governance forum, Twitter or any other venue. This is an informal process to gauge community interest in a potential Index Coop improvement.

Here are some questions the contributor might want to answer:

  • Am I able to informally get any traction for this proposal in the Discord?
  • Has this proposal been tried before?
  • How does this proposal get the community closer to achieving its stated goals?
  • What trade-offs are implicit in this improvement’s adoption?

Create an IIP Pull Request

Once a contributor feels they have a rough consensus that their IIP is valuable, original, and achievable they should submit an Index Improvement Proposal according to the IIP-0 guidelines.

Forum

Once an IIP Pull Request has been merged and assigned an IIP number, an IIP Editor will create a corresponding post in the governance forum’s “Proposals” tab. The proposal forum is used as a formal area to debate the merits of each IIP. In the early stages of Index Coop, if a super majority consensus (>90% FOR after 7 days) is achieved for a given IIP in the governance forum poll, that IIP can be moved to the “Approved” state and implementation can begin immediately. If an IIP can not reach super majority consensus in the governance forum, it will be put to a snapshot vote. All Index additions must go through snapshot voting.

An IIP editor will also create a corresponding Discord channel for all proposed IIPs for discussion.

Governance Calls

Governance calls may also be used to debate IIP proposals and to gauge community sentiment on them. The governance calls do not represent a formal venue to measure consensus.

Calling a Vote

If an IIP is contentious, it must be put to a snapshot vote for the community to accept or reject. The IIP author is responsible for deciding a snapshot vote date with the following criteria in mind:

  • The snapshot voting period may not begin until at least 7 days after the IIP status has been moved to “Proposed” state.
  • The IIP has a voting period of 3 days where token holders may vote FOR or AGAINST.

Snapshot Voting

When a snapshot voting date has been decided, an IIP editor will create a snapshot vote page with the following criteria:

  • Minimum Quorum: More than 20% of circulating, non-treasury INDEX must participate for a proposal to Pass. For Index additions, more than 40% of the tokens must participate.
  • Passing Threshold: More than 50% of voting tokens must vote FOR for the IIP to Pass. For Index additions, more than 70% of voting tokens must vote FOR for the IIP to pass.

Post Voting Process

After the snapshot voting period has concluded an IIP Editor will tally votes and update the Github IIP record with the related voting data. If a proposal is passed, the IIP is moved from proposed to approved. If a proposal is rejected the IIP may be moved to rejected or back to WIP to be revised for future consideration.

Implementation

In the early stages of Index Coop, approved IIPs will be executed via multisig where necessary. Otherwise, implementation of the IIP will vary on a case-by-case basis.

5 Likes
2

As we have a significant IIP to add a new index, I think it’s worth adding some more thoughts to this discussion.

For me, adding a new index is a BIG thing. Possibly the biggest decisions we will make. Once added it’s going to be hard to remove an fund from the DeFi ecosystem. Obviously we can modify fees, components and rebalancing, but delisting an fund will send a message to our customers with regard to change and maintaining our products for the long term.

So what do we need to think about?
Market fit
Is there a potential to capture a new customer base?
Potential AUV value
Canabalisation of other INDEXcoop products.
Fee structure.
Reputational risk from our new partners (we are going to be tied to their name and reputation).
Quality and liquidity of the included tokens
How much work will INDEXcoop have to do to market the new fund.
Do we have the technical capacity to include the requested assets.
How will we get liquidity for the secondary market
Will INDEXcoop contribute to any incentives.

Should we have a formal timetable for discussion, vote, implementation?

Should we insist on a minimum of 1 call specifically about the proposal?

3 Likes
3

I’ve been working a lot on my Layer 2 Index pre-proposal during the last few weeks.
However after listening to the community call number 2 (last week), I sounds like most of the concerns are surrounding the DPI product itself.
There seems to be a consensus about it - or at least, the most active/visible contributors seem to share this idea.

And it makes sense : A lot of questions are without answers yet, such as rebalancing or taking advantage of underlying assets.

After going through the different discussions of this forum, I have been converted to think that focusing on DPI might be the best thing to do right now :

  • Combines forces / attention instead of splitting it (useful because there are still not so many users on this forum).
  • Creates guidelines for future indexes : Creating new indexes right now might lead to different methodologies applied, different rebalancing methods used, value accrual mechanisms experimented, etc… which anyone can do without IndexCoop permission. Where IndexCoop can have value is by designing a framework for future indexes, and I don’t think it is at this stage yet.
  • Experimentation / Emergent behavior : As we are in a permissionless and incentives-based environment, we have absolutely no clue of what people will do with $DPI. Imagine Aave or Compound start accepting $DPI for lending / borrowing. If there is a single underlying asset that produces high yields, it will also be visible on the $DPI lending/borrowing rate. Ex: High yield for $REP but $REP not available on Compound and $DPI available on Compound -> People borrow $DPI, redeem them for the underlying assets so they can get their share of the $REP yield (they lend the rest of underlying assets when they can to optimize the whole thing). $DPI rate is going to be the weighted average of underlying assets rate (and if not, arbitrage will be possible - and thus executed). I am making that up but it is just an example of how we might not even need a vault or transparent management of underlying assets in a permissionless and incentives-based world. So many things can (and will) happen. It’s going to be interesting, even with just one index.
  • Marketing : 1 product is always easier to understand for people. Also, #DeFi is enough of a buzzword so people wants exposure to it. This is a bit less true of #NFT, and even less true of #ScalabilityLayer (would be quite niche if fact, despite having a good performance potential). On the longer-run, people will start looking at long-term performance, and we’ll see if $DPI is still the best proposition.
2 Likes
4

These are some things the Set team has also talked about.
Some of the concerns you raised are addressed in IIP-2 which adds IIP requirements for Index proposals.
But I think largely we agree that even more rigor could be applied to Index applications since they are, like you say, so impactful and difficult to reverse.

Here are some other things to consider for Index proposals:

  • What is the go to market strategy?
  • What distribution channels can the index author commit?
5

@dylan Aha, that was the post I was looking to reply to…

I’m not familiar with the whole github / request thing, so I’m still trying to get my head around the process.

I think we should consider a call focused on a single fund application and have the proposer present to us.

A full vote (snapshot based?) may be a good idea (so even if the forum vote has a super majority, I think we should use something based on INDEX holdings.

9

OK, following some of the comments in todays weekly call.

I think that above it the current situation…

I must admit to being guilty on forgetting / omitting some / much of the IIP process. Part of that is laziness on my part, part lack of planning so time-critical actions need to be taken, part is forgetting the system.

So, the question is can we improve the way we agree things? If so how?

I would propose that we need to categorize decisions and apply different criteria to each:

  1. DG2 (product approval) and Expenditure over $XXX - Full IIP, discussion period and then Snapshot.
  2. DG1 (approval for work team assessment), and expenditure between $YYY and XXX (e.g product launch Liquidity mining) - IIP and super majority poll ( Snapshot if contentious)
  3. General proposals between $ZZZ and $YYY (WG creation, targeted liquidity mining (e.g. loopring) / liquidity mining extensions, BD funding) - Proposal without IIP (???)
  4. Decision below $ZZZ - WG leader.
  5. Metagoverance - Always Snapshot (needs to be token holders), but possibly different quorum threshold?

So, any ideas on what $XXX, $YYY and $ZZZ should be?
Any other ways we can build a petter system?

@anon10525910 @dylan @puniaviision @verto0912 @DarkForestCapital @LemonadeAlpha @BigSky7

3 Likes
10

A good start, but I think having too many categories/criteria for each type of vote increases friction/costs to decision making. In general the simpler the better.

Another heuristic is X, Y, Z are exceptions and may be conducted via forum/their own process, everything else done must be done via snapshot.

So the exceptions might be:

  • Setting up Working Groups
  • Decisions within working groups, or working group budgets

On a separate note, I would be in favor of removing quorum entirely, except for DG votes. I have drafted an IIP to that effect that hasn’t seemed urgent. It may be worth revisiting now.

The TL;DR is quorums are used to protect against decision making where not all stakeholders are able to vote. (e.g. they cannot make it to a board meeting because they are outside the country)

Index Coop IIPs are quite different in two ways:

  • All votes are public
  • All votes are run for several days.

Maybe there should still be an established standard of circulating that a vote is happening on the forum before a decision is committed to, because there is so much activity some forum polls may not be receiving enough the attention.

On a final note:
We’re thinking of deprecating the github IIPs repo in favor of hosting IIPs on the gitbook. The current interface on github is the industry standard, but it is likely blocking some contributors since a knowledge of git is required to successfully make a proposal.

3 Likes
11

Really love what you guys are doing! I was doing the data entry bounty (Metagovernance tracker) and a thought just crossed my mind;

  1. I understand indexcoop IIP is quite different where any $INDEX holder can vote on decisions based on the no of $INDEX they own, is it possible for all votes to hold the same weight? (Forgive me if I’m wrong)
  2. For people looking to actively contribute to Indexcoop is it possible to get the necessary training on github new uses so it can be convenient perhaps?