Meta Governance Proposals - Structuring a Process

Governance Meta-Governance
1

Authors: @oneski22 @Lavi

Summary

We’d like to propose a new process for Meta Governance Proposals (MGPs), that is separate from the IIP process.

We expect more requests to use some of the underlyings in the DPI to come in from a variety of stakeholders, and having a structured process in place that defines how to treat these requests is key for the Index Coop’s meta governance responsibility.

Introduction

With Index Coop’s products growing at a stunning rate, so does the potential influence the Coop has on the protocols for which metagovernance is active. We are already seeing this regularly in our current votes. For example, in the recent Aave votes, IC was in top 4 or even the top 3 in terms of voting power. On Compound votes IC is usually among the top 12, and in the most recent Yearn vote, the over 250 YFI in DPI led to IC being the biggest voter.

Motivation

This strong influence does not remain unnoticed and naturally people start to think of IC when the need for voting power arises. One recent example was IIP-67, where crypto analytics firm Flipside reached out to IC with the request to delegate 1.5M UNI tokens within the DPI contract to Flipside, in a one time delegation act. Flipside needed enough UNI in order for them to create a proposal (minimum UNI required to create a proposal is 2.5M UNI). This use case of the UNI token within DPI has led to some discussions and the vote was contested with only 64.3% voting FOR.

However, we do expect more of these requests coming in and in order for future proposals to have a clear path and to provide some orientation, we’d like to establish a dedicated Meta-Governance Proposal (MGP) track.

What is a Meta-Governance Proposal (MGP)

In order for us to have a common understanding, we first want to define the main points of what differentiates an MGP from an IIP. There are four points that define an MGP:

  1. Tokens under IndexCoop control - An MGP is a proposal that targets the use of the governance powers of tokens that are under the control of the IndexCoop.
  2. External requestor - An MGP is a request that comes to the IndexCoop from a source that is not the relevant underlying protocol. With the intent to use the Index Coop’s meta governance powers in any way other than voting for an existing proposal. (e.g. use AAVE to create a proposal for adding a token onto the Aave market).
  3. Use the tokens to create a proposal - An MGP is different from a normal meta-governance vote, in that it aims to use the underlying tokens to create a proposal, not to vote on a proposal (as that’s done by $INDEX holders).
  4. One-time delegation - An MGC is the request for a one-time delegation of tokens for a short period of time to the requestor’s target, in order for them to create a proposal.

Proposal Creation Process

  1. A forum post is created outlining the Meta Governance Proposal [MGP] to the Index Community. In addition to the full details of the proposal, the proposing party should explain the benefits to the IndexCoop and the underlying protocol.
  2. Should 1% of the circulating supply indicate support of the MGP via publicly verified messages, the MGP will receive a number [MGP-0] and proceed. A wallet can only signal support for one (1) proposal for each protocol at a given time. [Example: if there are 2 Compound proposals, a wallet can only signal support for 1 at a given time]
  3. Once 1% is reached, similar to our product assessment, a group of core IC contributors will assess the proposal and provide their feedback in the forum. We propose that the Meta Governance Committee, the Business Development Working Group, and the relevant protocol ambassador all participate in the assessment and individually add their comments.
  4. The forum post needs to be up for at least 7 days, and the assessment shall be done within the first 4 days. Engagement from the proposing party is highly encouraged.
  5. After the 7-day period, the proposer can call for a Snapshot vote, which goes live for 72 hours.

Quorum Requirements

For an MGP to pass, it needs to fulfill the following quorum requirements:

  • 7.5% of all $INDEX in circulating supply must have participated in the vote
  • 60% of the participating votes must be FOR the MGP

Execution of the Vote

If the MGP passes, delegation occurs either to an Index controlled EOA for direct proposing (dev team does verification of payload and necessary execution) or if the intended act is delegation to an autonomous proposal, delegation to the correct address will be completed by dev team. The resulting metagovernance vote FOR will be issued if applicable, since it is implied by the MGP and since standard quorum-requirements have been reached.

Next Steps

This forum post is intended to spark the discussion on creating a dedicated MGP process. We highly appreciate any feedback and hope to find consensus in order for us to move to an IIP state.

If the community agrees with this approach, we’d like to create an IIP and bring this to a Snapshot vote, voluntarily applying the higher quorum of 7.5%, to ensure that we have support for implementing this.

12 Likes
2

Is it possible to detail who “Core Contributors”, “Metagovernance Committee”, “Business Development Group” and the who the “Protocol Ambassador” to support future discussion.

4 Likes
3

Yup, there are 3 groups of core contributors we are suggesting provide feedback/opinion. Index holders have final say and are fully free to ignore their thoughts.

Meta Gov Committee: the current elected group that decides how coop votes on meta gov when quorum isn’t reached. (look for a forum post soon on metagov committee 2.0)

BDWG: BD working group, we are leaving it open to them to come up with process, same way PWG has a process for providing score/feedback on new products.

Protocol Ambassador: rep from the protocol ambassador program. Currently I believe they are:
@Mringz for Maker
@Matthew_Graham for Aave
@Don-ETH for Compound
@mel.eth for FARM
(Sorry to those I am forgetting please comment below and I will edit this comment)

4 Likes
4

If an MGP does not pass quorum is the vote decided by the metagovernance committee?

Should the coop charge $ for providing such a valuable, potentially make or break, service to others?

3 Likes
5

As proposed no, failure if quorum is failure of the proposal.

As for charging a service , a proposer could include that in their spec, however personally I wouldn’t be thrilled with that concept of bribery for massive votes.

4 Likes
6

Great to have a process being refined and that there is such a need is a reflection of the success so far of the IC!

As pointed out, the IC’s sizeable voting power grabs attention and will grab more. Deploying on behalf of requesters makes me feel anxious in the first instance - because the IC lives in a dark forest of human activity.

So, for me, the process for delegation must be thorough and public, enough to build very high confidence that the proposal clearly matches IC principles and can stand strong in the wider community as a self-evident good. I would like the quorum requirements set high: 10% of circulating Index and 80% of participating votes.

The reason for such high figures, and they should be refined, is to make it necessary to canvas widely for support, to shout and holler on Twitter, to make it necessary for many people to have their attention brought to a proposal. There can be no easy passage to getting the #1 YFI voting position or a top 5 place on an AAVE AIP.

The principles of the Coop are worked on hard and I know people care deeply about them, we turn up week on week and chisel and polish them as we go through tight spot and hard-knock, people care. Delegating the IC’s voting power is a very public act and an ecosystem statement - a chance to promote good values within our industry.

Refining the figures: quorum should be nowhere near single whale, loose-bloc , or easily purchased territory. Some near the apex will already know where they stand.

Regarding payment: While making payment for vote delegation would look odd to many, I do think that proposal guidelines could suggest some flat rate service cost in recognition of engineering and multi-sig time. This could be ring-fenced for later use on internships or engineering grants on GitCoin, or similar.

While this all may seem quite defensive, it is intended to help strengthen the project we have, to keep it valuable for all, and to still allow innovation. I am definitely for structuring a process and support the work @oneski22 and @Lavi are doing.

Disclosure: I am working to complete the IC protocol ambassador tasks for the REN protocol.

6 Likes
7

I think @mrvls_brkfst makes a good point that we should be putting up more barriers to proposing with our meta governance votes. We will be attaching our reputation to anything we propose, and we do not want to become known for supporting unpopular proposals that would have likely never reached the minimum proposition threshold if we had not helped.

One question I would like to pose to everyone is whether we should be proposing at all? I think we can separate “selfish” proposals such as adding DPI to Aave and external requests that have nothing to do with our core business. The former directly benefits the Coop, while the ladder has little benefit and has the potential to cause reputational damage.

I’m not sure if eliminating these kinds of proposals is the right answer, but at the least, we should be making them difficult to pass through our governance process.

9 Likes
8

Personally I would like to see the proposer required to have 1% of INDEX supply through accumulation or delegation (or some other established percentage); I think it’s important to have an established approach, but the first hurdle should be cleared by the proposer, and INDEX is the governance token. As I read this, anyone can propose and I see that being problematic. Essentially, push the path-to-1% responsibility into the lap of the initial proposer.

This is a huge power to be exercising, I don’t think setting a high bar that requires the accumulation of governance power is unreasonable.

6 Likes
9

Thanks for the thoughtful comments and I strongly agree with the sentiment that is being reflected. However, just to be clear, this process would not allow for borrowing “voting power” in the sense of “vote-buying”. The process would merely allow a party to use our tokens in order for them to create a proposal, not to vote on one.
The final vote is still done by $INDEX holders.
Maybe that was clear already and I misunderstood the comments, but I think that’s an important differentiation to highlight.

I think the main driver for people to approach the Coop with such a request, is because the creation of proposals for protocols such as Uni, Compound, or Aave is currently only available to those having millions of $ in tokens (or tokens delegated to them). The threshold for creating a UNI proposal is 2.5M, which currently is almost $70M.
Moreover, as we have seen with IIP-67, the requests come in via IIP due to a lack of an official process, which is the main reason for creating the MGP draft.
So if we add even more friction to the process or have our own threshold for accessing it, we might as well say we don’t do it, which is an option we can consider as well.
I like the idea of adding a small service fee, as this process does require a lot of resources from the Coop.

2 Likes
10

On the topic of “vote buying”, as far as I understand it that’s what project Paladin is offering:
https://www.paladin.vote/

11

Really excited to see so much progress against this since it first came up 2 weeks ago! Thanks @Lavi and @oneski22 for the great work. I’m generally supportive with a few builds below.

As usual - disclosure - I am an exec at Flipside Crypto in addition to a contributor at the coop.

I’m a little confused about what you’re saying here – is this meant to indicate a Snapshot poll? I’m assuming you’re referring to the circulating supply of INDEX but not 100% sure.

I also agree with @mel.eth and @mrvls_brkfst that this is a big power to be exercising and the Coop should be rigorous about ensuring good intent and alignment with the Coop’s values/success, whether that’s purchasing INDEX or something else. Speaking as a Flipside team member – we’re eager to demonstrate that we’re “good actors” and aligned with long-term sustainable growth in the ecosystem. Index could play a role in helping prove it that demonstrates competency for both parties, win win. I do share concerns about paying for delegation as I’d hate to be seen as participating in bribery.

Similar to the Work Team Analysis for new products, it might be helpful for the metagov proposal committee to have a few designated members (we have one each from product, analytics, and BD) and a framework they use to evaluate proposals. Additionally, would be great to have a community call for these proposals as we do for new products!

Lastly – can we clarify the relationship between delegating and voting in the final version of this? Should an endorsement of delegation be read as “Index Coop believes this is worth of community discussion” vs “Index Coop believes this should pass voting”?

4 Likes
12

Please #1 “Index Coop believes this worthy of community discussion”

1 Like
13

I quite like @mrvls_brkfst & @mel.eth comments and the idea presented above by @catjam. I would like to build on this and suggest; rather than Index Coop performing this assessment in-house and incurring the cost of doing so, we build this into the process and have it performed by the applicant.

Then Index Coop can review the assessment when the proposal emerges on the forum. Index Coop avoids the incurring the cost of the work group analysis and the entire community sees the assessment on the governance forum. We can provide an example in our docs for others to reference.

I also like the idea of some minimum INDEX holding and minimum holding duration. Some skin in the game is a good thing and we don’t want any short term gaming. We want long term INDEX holders, to ensure our values are all aligned and having some skin in the game makes sense to me.

4 Likes
14

Carefully! That could be seen as censorship.

15

Hi Everyone

We will be scheduling a community call to continue the discussion on this important topic. Especially in light of the demand we are seeing to use the Coop’s Meta Gov Powers.

Hi @catjam since our voting is off-chain (snapshot) and we want this to take as minimal engineering resources as possible (for now), I was thinking of signed messages such as this one where there is a clear publically verifiable link to an address that holds INDEX (ideally the message would have a reference to a specific time/block). Would love suggestions for other ways of signaling.

Present the highest decision we make is a DG2 vote, which has requirements of 10% circulating supply and 60% approval. Those votes already take a lot of lobbying and require the consent of not just the community but several large whales just to make a quorum. The logic behind the proposed thresholds was to keep it at an obtainable range, while also keeping a high barrier to passing. Would love to hear more thoughts on what a good level should be.

As for ability to purchase: 1% to even force a proposal currently costs ~$1.1M (20%+ slippage) [from 1inch]. To cause quorum (10%) would exceed the supply on DEX markets presently and require an OTC sale.

Screen Shot 2021-08-22 at 10.41.49 PM
Screen Shot 2021-08-22 at 10.41.49 PM1058×732 61 KB

Looking forward to the community call (details will be posted here and on discord), so we can gather more feedback, adapt this proposal, and get it to a formal vote.

5 Likes
16

Thank you @oneski22 , I appreciate fleshing out the details here - numbers can be so familiar to those who work with them that they hardly need mentioning but to those who don’t read them everyday, it’s really illuminating to see them.

And, yes, I recognise that we needed the MGC backstop due to quorum being hard to reach. However, I still feel that a delegation might be more contentious than some of the more admin-like protocol proposals, and could benefit from being differentiated from standard votes.

17

Really solid forward momentum here. Awesome to see the outline of the process take shape. As we refine this process I would love to see deeper economics built into this process. AAVE does a good job of requiring a minimum # of AAVE to propose an AIP. Potentially this would be a good place to start implementing a similar system for IC.

For example, we could set a minimum of 10k INDEX to propose a MGP. This would help drive ecosystem wide adoption of our governance token and also provide important price support.

5 Likes
18

I really like this proposal and I believe it is super important for driving value to the INDEX token by strengthening our governance process and adding a formal process to drive change in other protocols. I would be curious to see if there is any engineering lift to create a minimum amount of INDEX to propose an MGP I think @ncitron can chime in here but I believe that is definitely needed for this sort of process. I also like the fact that we are essentially creating another proposal process that is separate from the IIP process.

Not related to this specific conversation but I would like to see a similar process applied to how we onboard products. Basically separating the product IIP process from the Index Coop protocol IIP process. These sorts of improvements really help us establish an identity as a protocol and a DAO as I strongly believe we need to have a few fundamental value propositions as a protocol and a DAO.

I am starting to see their fundamental value propositions for our DAO/protocol:

  • Meta-governance
  • Product/token creation and support
  • Product/token maintenance
6 Likes
19

We can just have people sign a message from an account that holds the minimum amount of INDEX. It won’t be automated or anything but it works and requires no engineering effort.

However, I do have some concerns around the overall operational/engineering work required in the implementation of an MGP. In order to safely handle these situations, we would want to execute the proposal on the behalf of others rather than freely delegate our votes (to ensure we have full control of what gets executed). We can also use autonomous proposals which serve a similar purpose. The unfortunate part here is that we would want to manually verify the proposal payloads to ensure that there is nothing malicious slipped into it. This in of itself is a time-consuming task that few people in the Coop can accomplish.

3 Likes
20

We are building a very unique organization at Index Coop. As everyone spends more and more time on this project we continue to gain a better understanding of the full scope of the IC value proposition. This is an exciting time - separating some decision making processes from protocol level IIPs will be a big driver for growth.

That list gives a compelling argument for building out non IIP decision making processes. We need to streamline how the DAO makes important decisions on things like product, metagov, fees etc. Each item on that list will require focused teams to execute. These teams will ultimately be responsible for driving revenue to the protocol.

From my perspective this is a good argument for why Index needs to further explore the economics of metagovernance. If the service is valuable for one party but expensive for the other, it seems clears that the party using that service should compensate the protocol.

1 Like