IIP-92: Meta-Governance Committee 2.0

[oneski22]

IIP: 92
Title: MetaGovernance Committee 2.0 - Election Structure
Status: proposed
Author: Lavi (@Lavi , David (@oneski22 )

Discussions to: IIP-51

Created: 27th September 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,000,000 block (~5 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.

Abstract

We propose to change the MGC terms from three to 1,000,000 block five months, and that anyone can nominate new MGC members. Seats open up in a staggered approach, i.e. on a monthly basis. A single term is set to last 1,000,000 blocks (with max 3 consecutive terms), meaning that each seat goes up for election roughly every five 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 15 months.

Motivation

Members of the Meta-Governance Committee (MGC) were elected for 3 months, as agreed in IIP-51. The first term ends on October 8th, 2021. 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.

Specification

Overview

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,000,000 block turnover cycle.

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

• @Lavi, Term expires on Block 14330000
• @ncitron , Term expires on Block 14130000
• @Kiba, Term expires on Block 13930000
• Penn Blockchain (@yuan-han-li), Term expires on Block 13730000 (replacing Cedric)
• @oneski22, Term expires on Block 13530000

Budget

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.

Example

Looking at Noah for instance, his term will end in ~800,000 blocks (4 months) after implementation of this proposal. He can be nominated or nominate himself, to serve another term. If he wins the multi-choice Snapshot vote, he will serve another 1,000,000 term. However, since this will be his third term in a row, he has to take a break of at least three votes, before being eligible for nominations again.

Voting

FOR

Move to staggered approach and monthly MGC election (one seat only, unless exception), as proposed above and add Penn Blockchain club to MGC as new member for (at least) 2 months.

AGAINST

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

[pujimak_in]

I’m in agreement FOR this staggered approach.

Though my only concerned is for the long term of doing monthly election for MGC… could it create a fatigue within the forum community?

As there will be months where would be off peak (in terms of activities & participation) compared to other months and vice versa… For example every end and beginning of a quarter… the forum will be buzzing with WG proposals and budgeting etc (then voting etc). Then during the off months (middle of the quarter)… relatively not as “busy”… of course relative terms… but yeah.

Perhaps just throwing this out, another suggestion is that doing elections in the middle of each quarter. But also staggered… ie. 2 for this coming… and 3 for the next… or something along those line. Probably needs to flash out more. But thats my thoughts and suggestion on this.

[mel.eth]

@mel.eth

Just dropping a note in here, as I’d like to see an amendment in the next 3-month renewal round.

There is some discussion in the original post about how the Ambassadors feed into the MGCs decision making process, and it’s mentioned briefly here, but this IIP in my opinion fails to do a few things:

1. Establish some philosophical guidelines on how the community feels the MGC should vote. I’d be happy even if it were stated that the MGC had a mandate to “vote in-line with the sustainability of The Coop and ecosystem overall”. Literally anything more substantial than 5 people having unlimited discretion for a 3-month period. I do like that there will be a post-mortem statement for contentious votes.
2. Establish why it’s important that The Coop participate in every vote. Failure to meet quorum seems absolutely fine to me from a metagov standpoint, and we could have achieved a less centralized result here by just eliminating quorum. Even a contributor sentiment poll would be preferable in my opinion.
3. Establish how incentivizing participation for participation’s sake is worth The Coop paying $7,500 a month for - and conversely failing to address compensation for Ambassadors who do the work of gathering the info.
4. Finally, I would like to see one of the 5 votes be left open, to be filled by the relevant Ambassador; or at least have that Ambassador’s input be incorporated in a more formalized way.

My main issue with this initiative is that governance is the most powerful tool that tokens confer, and we’re centralizing the bulk of it without an adequate explanation of why or any meaningful guardrails around that whatsoever. DAOs are considering paying large sums of money to gain governance power and we’re acting pretty cavalier about it here. Not looking to change an already passed IIP (and I’m annoyed with myself that I didn’t raise these points at a more appropriate time), but I do think it’s worth giving this more thought when looking to renew this in three months time.

I don’t have much to add to my late comments on IIP-51 but I’ll try and be a bit more explicit in what I’m looking to have answered. While I find the implementation of the renewed initiative a bit odd, at least until I can get Ethereum block numbers to show up on my Google calendar, my main concerns here are around:

1. Why is it important that IC vote in every metagov vote?
2. Why is it important to have a quorum on metagov votes? Has a reduction or removal of quorum been considered?
3. Monthly elections and rewards for the MGC will become more formalized with the passing of this IIP and equate to approximately 1 FT non-tech-contributor reward package . . . is it worth it?
4. How do ambassadors inform the process and should we formalize that initiative within this one?
5. Are representatives free to vote their own interests, or is there an expectation by the community that they will put personal interests aside and vote in favor of Coop sustainability, should those two things be at odds? If the latter, should that be made explicit? Should COI disclosure requirements for MGC voters be established?

I realize I’m asking a lot. The work on this proposal, the efforts by the MCG, and any forthcoming responses are all super appreciated. Thank you.

[oneski22]

@mel.eth

at least until I can get Ethereum block numbers to show up on my Google calendar

A little hack to add approx ETH blocks to your calendar: Ethereum Blocks #13530000 | Etherscan

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

@mel.eth

Are representatives free to vote their own interests, or is there an expectation by the community that they will put personal interests aside and vote in favor of Coop sustainability, should those two things be at odds? If the latter, should that be made explicit? Should COI disclosure requirements for MGC voters be established?

I am a strong believer in completing some form of COI disclosure (see mine here, if folks need a template TrotNixonLine - COI Disclosure. However the community will vote and decide on their representatives if they elect ones who do not disclose, that is their decision.

@mel.eth

• Why is it important that IC vote in every metagov vote?
• Why is it important to have a quorum on metagov votes? Has a reduction or removal of quorum been considered?

As for the importance of metagov, I think it is one of the key-value props of the Index Token. Our power is large, and not voting can cause protocols to miss quorum on their respective votes, especially as our vote holdings grow. It is essential for us to be good crypto citizens and the MGC helps facilitate that.

[mel.eth]

Noting that I had a conversation with @oneski22 outside the forum and got great clarity here. I’m going to port some of my learnings here.

@mel.eth

Why is it important that IC vote in every metagov vote?

There are things that matter greatly from a protocol-operations perspective that might not matter to INDEX holders when it comes to the DPI constituent protocols. For example, there may be proposals that are critical to Aave operations and ensuring that Index Coop is a reliable participant in governance goes a long way toward building lasting relationships with our meta-governance partners.

@mel.eth

How do ambassadors inform the process and should we formalize that initiative within this one?

This is being formalized through the pending GOWG.

Otherwise noting that I will have a bias toward voting for individuals that elect to post COIDs, but understand that it may not be practical as a requirement, as may be the case with delegation to blockchain clubs. I appreciate you taking the time @oneski22; I will be voting FOR on this one.

[oneski22]

Calling for an IIP number and a vote on Wednesday @mel.eth @sixtykeys @Mringz cc: @Lavi

[sixtykeys]

Hey David, an IIP number (92) has been assigned, I will update this post with the snapshot link as soon as the proposal is queued.

cc: @mel.eth @Mringz

[Dmitriy_Berenzon]

Thanks for writing this up David!

I’d echo @pujimak_in’s concerns around “voting fatigue” → if everybody is constantly lobbying and voting then nobody is actually adding value.

I agree that 3 months was absolutely too short - it usually takes people 3 months to even figure out their job.

While ~5 months is better, I worry that it doesn’t result in long-term thinking since people tend to optimize towards short-term gains and decisions that will get them re-elected in the next cycle. I would propose 6-month terms with max 4 consecutive terms for a total of max 2 years for each person in the role.

Also, because of the 5-month terms starting at different times, it sounds like there will be 5 elections at different times every year, which feels like a lot of overhead. One rough analogy is that general elections occur at general intervals and have candidates running for multiple offices on the ballot.

One way to address this is to have semi-annual elections for a max 2 new members per election to ensure there is enough overlap for knowledge transfer.

[sixtykeys]

This IIP has been queued for snapshot with voting to begin on Wednesday, 6th October 1800UTC.
Snapshot here

[Lavi]

IIP-92 is temporarily called off.
We’re working to answer feedback and implementing it accordingly. To ensure enough time is provided we postpone the vote to Monday. Thanks @sixtykeys

[Lavi]

FYI: A new forum post was created to reflect the adjusted IIP. Let’s move the discussion over.