Make the following changes to the Index Improvement Proposal Process:
Move hosting of IIPs to the indexcoop gitbook
Change IIP quorum requirements
Remove the governance forum supermajority vote as a valid IIP passing threshold
Change waiting period before an IIP can be called to vote on
Add a second class of fast-track IIPs with reduced requirements
Abstract
If accepted, this proposal will make several changes to the Index Improvement Proposal process.
1. Move hosting of IIPs to the indexcoop gitbook found here.
The current Github repo will be updated with a deprecation message and a link to the indexcoop gitbook.
The indexcoop gitbook will be the source of truth regarding the statuses of all IIPs.
2. Reiterate and solidify quorum requirements for IIPs
The passing thresholds for Decision Gate 2 votes are:
10% or more of circulating tokens must participate
60% or more must vote FOR
The passing threshold for all other IIPs (including meta-governance votes) are:
5% or more circulating tokens must participate
50% or more must vote FOR
3. Remove the governance forum super majority as approval pathway for IIPs.
In the early days of the Coop, we viewed a supermajority polling as a tool to quickly gauge buy-in while allowing the Coop to remain nimble. This has led to some confusion about the IIP process:
Is the poll attached to a given IIP a temperature check, or an actual IIP passing vote?
Which IIPs can be passed by supermajority forum poll? Should product addition and certain INDEX expenditures always be put to snapshot?
Removing the option to pass IIPs via governance forum poll will greatly reduce ambiguity in the IIP process.
4. Change waiting period before an IIP can be called to vote on.
Currently, a vote can only be called on an IIP after spending a minimum of 7 days in “proposed” state.
The “proposed” state implies the IIPs parameters have been finalized.
This IIP would change the waiting period before a vote can be called to 2 days (48 hours) minimum in “proposed” state.
5. Add a second class of fast-track IIPs with reduced requirements.
Any IIP can now include an “option to extend” clause.
This signals that a similar IIP with minor changes may be proposed in the near future
(e.g. DPI Liquidity Mining extensions in IIPs 11, 12, 14 and 19).
Such a future IIP must reference the IIP it is extending.
The future IIP will have no minimum wait period in “proposed” state before a vote can be called.
All other standard IIP rules still apply.
Motivation
The original Index Improvement Proposal program was created just days after the Index Coop was launched. Since then, we’ve created and voted on more than 20 IIPs and have a much better understanding of the needs of the Coop. This IIP suggests improvements to the IIP process to better serve Index Coop’s needs.
Some of the problems we’ve identified with the current IIP process:
The IIP process primarily lives on Github. A working knowledge of git is required to create a proposal. This is a significant barrier to entry for non-technical contributors, of which we have many.
The waiting period before an IIP vote can be called feels long and is not always obeyed.
There are a certain class of proposals (mainly the Liquidity Extension IIPs) where the current IIP process seems unnecessarily laborious.
Multiple approval tracks for IIPs add ambiguity around whether a given IIP has met criteria to be approved.
The IIP process is successful insofar as it helps us better run the Index Coop and gather consensus. The hope behind this IIP is that by agreeing to reduced requirements for the IIP process, we can get higher compliance with the remaining requirements that are critical to reaching consensus. By removing the more ambiguous parts of the IIP process, it should be clearer to all Coop members whether or not an IIP has passed or not.
Voting
FOR - Update the Index Improvement Proposal process according to the changes described above.
AGAINST - DO NOT update the Index Improvement Proposal process according to the changes described above.
I like the proposal. I think it’s critical from an organizational perspective that we have clear rules in place, especially for critical items like votes, and that we then actually follow them consistently. I think what you described probably brings the voting structure more in line with what is desired in practice.
It will be useful to have the voting rules, written as clearly as possible (e.g., noting where no quorum is needed, passing thresholds) on the gitbook so that newcomers coming to participate are fully aware.
These are much needed improvements! Adding a second class of fast-tracked IIPs will significantly help us speed up some of our more routine decision making processes. The faster we can make high quality decisions as a community the better.
Once this is approved we should further explore breaking IIPs into several different classes based on the nature of the proposal. While some IIPs have broad community impact and need extensive debate, others are more routine in nature.
At first blush, #1, 3, 4 seems like no-brainer, small tweaks to simplify and speed up decision making.
However, “#2 Remove quorum requirements” gives me pause.
Without having done actual analysis, it seems like quorum requirements are easily surpassed when there is enough enthusiasm and support/detraction for a given vote.
I don’t quite understand what problem(s) #2 is intended to solve.
Can you share for Index Governance & Meta-Governance separately:
What problem are you intending to solve by removing quorum requirements?
What do you believe the consequences to be of removing the quorum requirements?
Curious to learn where that suggestion is coming from!
I believe that the quorum requirement provides a valuable way for us to assess the enthusiasm for proposals. If the community is un-enthusiastic about a proposal this can be expressed in two ways, either we vote no or we abstain from voting. This provides a great way to screen proposals and ensure that a minimum level of engagement is reached.
At the end of the day - if our community is not excited about the products we are launching we cannot expect the end consumer to be excited about the products either. The best indices are the indices that our community is rushing to buy and rushing to LP.
Thank you @dylan for the proposal. Looks really well thought out. I have a few takeouts/thoughts on this, mostly on the quorum & waiting periods points raised. I totally agree we should have a separate fast track IIP process:
Some type of quorum exists in almost all voting based systems, for the reason that abstention is also a way to express opinion.
Removing quorum for all IIP’s imo does not foster inclusivity, and it could open up attack vectors on IIP’s but especially in meta-governance proposals, as indices like DPI gain size in the space.
For fast track initiatives, we do have the supermajority forum vote rule which is not great in terms of sybil resistance, but really efficient for quick things.
My thinking around solutions for this, would be:
1- Create the proposed fast track IIP with a lower current quorum rule for a restricted type of voting proposals, that involve routine operational decisions, with a cap on $ value that is subject to low quorum threshold.
2- Further cement the role of IIP champion/proposer (I can think of how EIP’s have champions in the Ethereum governance model), and make sure they have the role of gauging community support & reception for a certain proposal, before it goes to voting, and they would be the main point of contact for questions/details.
3- Keep current quorum rules for proposals above the $ threshold defined in #1, new products as well as meta-governance proposals, with maybe a longer voting period for more exposure vs INDEX holders.
Thanks for pulling this together Dylan it’s a really valuable update to the way we approach improvements.
A couple of thoughts:
Initially I thought having quorum protected us from malicious or just plain bad proposals going through, but actually removing the quorum requirements does the same but with the added effect that large voters can’t afford to ignore what’s going on lest something pass that is not in their interest. In that way the nature of the setup should actually increase voter engagement
Having said that, I think removing quorum for meta-gov is risky. We are acting as a guardian of the votes within DPI (and soon enough MVI). I would rather we not vote at all than risk having something slip through with a small number of votes and potentially represent a bad choice.
*Both of the above points assume that larger token holders are more informed, this may not be the case but the incentives are there for it to hold true
Fast tracking through the forum isn’t explicitly mentioned in your post (which is fine, it’s about IIPs) but it’s probably worth incorporating here or in a separate post as we are doing a lot of it recently.
In summary support 1, 3 and 4, don’t think 2 makes sense for meta-gov.
@DarkForestCapital@snasps@anon10525910 how would you feel about lowering quorum for meta-governance? Trying to understand if 15% has some scientific significance or if it’s arbitrary.
Also, kinda feel that removing quorum for meta-governance is a bandaid, not a solution. Hopefully, we can have a solution via delegation or a meta-governance committee that gets elected via snapshot for 3-month term and can then vote on meta-governance.
I would support removing quorum on everything that is not meta-governance, DG1 & 2 votes and major changes related to our products (changing fees, for example).
My 2 cents on this is I have seen anecdotally the number 15% a lot in DAO’s since participation (not quorum) is usually kind of lower that IRL elections (Where turnout tends to hover between 40-60%)
No strong feelings on this one, but I would argue that going too low/no quorum could incentivise potential bad actors to try to pass bad decisions on other protocols. The bar needs to be high enough so this type of attack on the Coop would not be economically feasible.
Regarding other types of decisions:
DG1&2, Fees: I think that as @BigSky7 pointed out, strong community support for new products/changes to existing products is kind of an early temperature check for the wider community’s excitement for those. Quorum is a way to make sure we do not proceed with plans that have less overall community excitement.
Spending: I think that there should be a quorum on budgets & spending decisions (over a certain $ threshold) to ensure token holders at large feel they are being consulted on big financial decisions regarding the Coop.
Fast track: We should have a lower quorum requirements for more routine decisions & spending decisions under a certain $ threshold.
Thanks all for all the responses. I’m going to update the proposal with the following changes:
Mostly keep quorum requirements where they are:
DG2 → 10% tokens in circulation participating, 60% voting FOR
All other votes → 5% tokens in circulation participating, 50% voting FOR
Proposed waiting period before a vote can be called changed from 7 days → 48 hours
Remove the governance forum supermajority (>90%) vote as a passing threshold for IIPs.
With the reduced requirements above, all IIPs should be easily voted on via snapshot
@snasps Regarding spending:
By removing the forum proposal super majority pathway for IIPs, all spending from the community treasury will in some way be subject to INDEX token holders.
There are two main ways community INDEX tokens are spent:
Directly via IIP. Examples include the DPI KuCoin market making loan, and any funding for liquidity mining contracts.
Via a working group funded by the Treasury Committee. The Treasury Committee itself is funded via an IIP.