IIP-92 Meta Governance Committee 2.0 & Election Process

IIP: [92]
Title: MetaGovernance Committee 2.0 - Election Structure
Status: proposed
Author: Lavi (@lavi), David (@oneski22)
Discussions to: IIP-51 & IIP-91 (old)
Created: October 8th, 2021

Simple Summary

Re-authorize the Meta Governance Committee and transition into a long term structure with regular elections to easily allow for the cycling of members.

Members serve 1,200,000 block (~6 month) terms, with a 3-consecutive term limit elected via ranked-choice voting using Snapshot (voting with $INDEX tokens).

Recall election can be triggered by signaling with 5% of the circulating INDEX supply, standard IIP quorum will apply on the recall.


We propose to change the MGC terms from three months to 1,200,000 blocks, which is roughly six months, and that anyone can nominate new MGC members. Seats open up in a staggered approach, i.e. on a quarterly basis (every quarter either 2 or 3 seats open up). A single term is set to last 1,200,000 blocks (with max 3 consecutive terms), meaning that each seat goes up for election roughly every six months.

Elections take place via multichoice voting on Snapshot before the previous term ends. This limits the time a member can consecutively be on the MGC to a max of roughly 18 months.


Members of the Meta-Governance Committee (MGC) were elected for 3 months, as agreed in IIP-51. The first term ends on October 9th, 202. This proposal is a means to specify the structure for MGC elections going forward, which are going to take place on a recurring basis.

We propose to establish a standard process to elect new committee members, which can easily be repeated for future elections. Further, this proposal also covers the transition phase by proposing term length and Penn Blockchain Club as a new member.



This IIP will solve two things. First, proposing a new structure for how members of the MGC will be elected going forward. And secondly, proposing the transition process, which inherently is an election of the members for the MGC for the next immediate term, starting on October 8th.

Nomination of MGC Members

  • 1 week prior to the next election, a forum post will go up calling for candidates. Any candidate can nominate themselves (internal or external)
  • All candidates are encouraged to attend a community call to introduce themselves and explain why they should represent the coop
  • For this first iteration, the nominations are done by the current MGC (see below). However, starting one month after implementation of this IIP, nominations are open to anyone
  • A candidate can only serve max 3 consecutive terms, after which they have to take a break of at least three cycles (600,000 blocks or roughly 3 months)

Election of MGC Members

  • All nominated candidates will appear on a Snapshot vote, using ranked-choice voting (example here). The winning candidate will serve a full 1,000,000 block term, unless removed via recall or resigned. The snapshot vote will start on the Monday before the term is set to expire and run for 72 hours.
  • If a committee member does not fully complete their term (either by recall or resignation), their seat will go up for a special election alongside the next regular election. The winner will serve the remainder of the allocated term, and it will count towards the 3-consecutive term limit.

Transition Process

We recommend not to replace the whole MGC at once, and that previous members do the on-boarding of new members.

Therefore, we propose to use a staggered approach, that is electing a full MGC via this IIP, and explicitly setting the length of their terms to create a 1,200,000 block turnover cycle.

The interim proposed members and their term lengths are as follows:

  • Seat 1 → @Lavi: 2nd term expires on Block 14300000 (~February 28, 2022)
  • Seat 2 → @ncitron: 2nd term expires on Block 14300000 (~February 28, 2022)
  • Seat 3 → @kiba: 2nd term expires on Block 14300000 (~February 28, 2022)
  • Seat 4 → Penn Blockchain, trial-term expires on Block 13720000 (~November 31st, 2021)
  • Seat 5 → @oneski22 , term expires on Block 13720000 (~November 31st, 2021),

This means that David’s seat, as well as Penn Blockchain’s seat, will be open for voting at the end of October/beginning of November. Since Penn Blockchain only just joined, they will be re-nominated automatically. However, they still need to be confirmed through a vote. The person/group winning seat 4 and 5 will serve 1,200,000 blocks, which is until block 14730000 (early May).

In January, 3 seats will be up for vote. Same as above, the elected group will serve 1.2M blocks, which is until block 15320000 (early August). This way we ensure that votes are held quarterly, and that either 2 or 3 seats are open for election.


As defined in IIP-51, MGC members will be rewarded with a monthly stipend of $1,500 to compensate for time and attention to Meta Governance votes. Consequently, we request to continue the funding of $7,500 per month for all five members, until revoked or changed via IIP otherwise.

For reference: 32 Meta-Gov votes went live since the inception of IIP-51 on July 8th.


Looking at @kiba, @ncitron and @Lavi, their second term will end on January 31st. They can nominate themselves again. However, since this will be the third term in a row, they have to take a break of at least three votes, before being eligible for nominations again.

Looking at Penn Blockchain, their term will end in ~187,700 blocks (in 24 days). Since this is an exception, and they are directly replacing Cedrick, they will automatically be nominated again. If they win the multi-choice Snapshot vote, they will serve another 1,200,000 block term (which will then officially count as their first term). At the same time, David’s seat will also be open for new nominations.



Move to staggered approach and quarterly MGC election, as proposed above and add Penn Blockchain to MGC as new member.


Do not move to a staggered approach and use 3-month terms with internal elections, i.e. effectively no change to current status


Thanks a lot to @pujimak_in, @Dmitriy_Berenzon and @mel.eth for your kind feedback on the previously proposed MGC election process. Especially the high overhead, which the old proposal might have caused, was a concern that we have discussed before and was now adjusted accordingly. To better reflect the changes and move forward we decided to create a new post.

In summary, the following changes were implemented to the proposal:

  • 6 month terms (instead of 5)
  • quarterly elections (not monthly)
  • 2 or 3 seats open per election (instead of just one)
  • slightly adjusted blocks for transition process
  • dates added to better reflect term length

Please let us know, if the adjusted version reflects the improvements you proposed.


Putting on the ol’ curiosity cap :billed_cap:

Looking back at IIP-51

How have our relationships with Aave, Compound, etc… changed because of voting on every proposal?

How has trust & rapport been developed because of voting on every proposal*?


im not sure if any of the issues have been resolved on the other platforms or not, but from where I found the problem was discobot was freely being controlled on demand… The first 8nstance was with Aave where I went to vote and noticed that the Trust voting % had a 20% decrease. But the worst part of it was I then sent a notice to the gov board to notify and 5 mins after sending it, Discobot deleted the communications then blocked me from communicating on the platform… The second time was on Curve gov when it did the same thing and then blocked me on Curve.

I haven’t been able to have a direct communication with a human admin so I can’t confirm of the issues have been corrected or not…

When I noticed there were other issues on multiole platforms I notified the community that the virtual guv concept had it outlined that no moderators or admins can act as a delegate or have any way to access the voting keys because they are required to be completely different servers… There is always supposed to be 3 admins of any type system interacring so that there is a redundancy oversight and always two alternative humans that have admin access to the platforms. But even more so, in the event of an issue, it takes a member to flag or report an issue, but no single human can ban or block, it requires two admins and after the member is notified and able to respond. Somehow Discobot was coded to control this security issue…

After the issues I proposed that there should be 2 admins with an additional 2 rotational intermediaries so that the intermediaries can be new to community and get a variety of experience on the different platforms to learn how they all connect… But also because since they are randomly selected from a different platform, to be assigned to another, it prevents the platform they are going to from blocking them from access… Also since they are supposed to be acting as an internal reviewer, they can verify ledgers and verify gov voting system is accurate by contacring delegates and such to get direct human feedback from emailing so that the communications can verify that the right parties are using the platforms.

These guidelines were in the concept and were a requirement for other protocols to implement and include if those platforms were going to connect to Aave. When it was diacovered this had not been set forth, I notified Aave but continued to be blocked by discobot…

This is an issue that has to be corrwcted because the platforms have to be secure before we can take it to the next phase. I’ve put together an optional way of doing it so that the entire process can function as Blind Admins for platforms they are not directly involved with… That way the platforms have a universal secured access and then moderators can function within platforms better suited for audience they mesh better with. But it is required that all moderators interacting with forums and community boards are to be verified as human by other protocols and refferal provided by known entities, then a moderator is provided a password and moderator account by the platform that they cant have any control over so that admins and reviewers can review their various communications and interactions to see if there is an issue…

Perhaps these issues have been corrwcted, but wanted to provide some input so that the community can take into account that marketing a flashy website is great, but if the platform isn’t secure, then the platform won’t have any members to look at the site or uae it…


I will vote against it, because the calendar served me well in my life. To look up, which block is now and estimated when on the calendar is counterproductive. My calender shows year, month, day, but not block number.

Especially funny is to mention 1 week and blocknumber at the same time. Reminds me on a joke: some engineers use strange speed units like Angstrom/week - well USA still doesn’t realize that the metric system is superior over the imperial system.

Others would be fine.


That’s a great question and I’m not sure if I got the right answer. However, I think it has increased the contact to other protocols quite a bit, especially to core-contributors like Gauntlet or Getty, whenever there was a proposal on Compound or Aave that came from them or if we had any questions.
Maybe it’s not directly related to increased voting frequency, but generally the voting power that has contributed to strengthen the partnership with Fei, for instance.
And I do hope that it generally added to IC’s reputation as good DeFi stewards or citizens (not sure how to name it), as with any voting power it’s a privilege, and not using it could be seen as negligent. Admittedly we also haven’t been very vocal about it and haven’t requested any feedback yet, so this answer basically just resembles my gut feeling. Hope this answers some of it nonetheless.


Mostly copying over from the old thread:

I know it seems odd, but I strongly subscribe to the idea that we need to use ETH blocks for dates. Our organization lives on the Ethereum blockchain and blocks are the fundamental unit of time on blockchains. This standard is starting to be built into recent IIPs: the recent OTC sale’s voting rights unlock at a given block, DATA’s offboard options are tied to specific block deadlines, etc. Given this group works with on-chain actions, defining terms by specific blocks will reduce any possible confusion over who has what authority to take what action at a given time.

Etherscan provides great tools to help add specific block times to calendars. Post merge, we will have much more certainty of block production speed (seconds_per_slot is a variable that will be explicitly defined in the specification, currently 12 seconds, compared to the variability of today’s PoW chain).


Calling for Snapshot vote to go live tomorrow @sixtykeys, @Mringz, thank you!


This proposal is set to go live today at 1800 UTC, with voting ending on October 15th, 2021.
@Lavi @oneski22

Snapshot here


Confirming that this proposal has passed with 215.28k INDEX voting FOR (100%).
Snapshot here

cc: @mel.eth

1 Like

After running 2 separate elections using Ranked choice voting, GovNest has assessed that this voting system is not ideal for any election that requires more than 2 candidates. Therefore, moving forward, we shall use the Weighted voting system for all future elections.