iip | title | status | author | discussions-to | created |
---|---|---|---|---|---|
26 |
Index Improvement Proposals V2 |
Draft |
Dylan (@dylan) |
2021-03-30 |
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
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.
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
-
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.
-
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.
- 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.
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.
Copyright and related rights waived via CC0.