Establishing Governance Process v0

🗳 Governance temp check
1

Summary

This proposal provides guidelines for submitting, voting on, and executing proposals at Mangrove DAO. It aims to streamline the governance process, ensuring clarity and consistency in decision-making within the DAO.

Rationale

Establishing a well-defined governance process is essential for Mangrove DAO’s success. A clear framework ensures trust and legitimacy, as participants understand how decisions are made. It facilitates active engagement by providing clear guidelines on how to participate. Moreover, defining the current process allows for future improvements, ensuring the DAO remains adaptable and responsive to evolving needs.

Specification

1. Scope of General Governance

As established in MIP-1, Mangrove DAO’s general governance focuses on setting high-level goals and strategies. The execution of approved strategies and associated operational management decisions are delegated to the Councils. Mangrove DAO’s governance encompasses:

  • Voting on strategic proposals initiated by councils or the community.
  • Electing and funding councils.
  • Authorizing special operations, such as exceptional spending beyond approved council budgets.
  • Metagovernance: updating governance parameters.

2. Discussions

The Mangrove DAO forum’s general category is a space for open discussions on governance-related topics.

For more focused proposal development, participants should use the temp check category. This section is designed to gauge stakeholder sentiment and foster informal debate around specific ideas that may lead to formal proposals. Posts in this category should be structured as follows:

  • Header: Includes the title, authors, and date of the post, and specifies the type as either ‘protocol’ or ‘ecosystem’.
  • Body:
    • Summary: A concise overview of the post’s content.
    • Rationale: The reasoning behind the idea or question.
    • Specification: Detailed description of the proposal or idea.
    • Disclaimer (optional): Any necessary legal or contextual disclaimers related to the post.
    • Next Steps (optional): Suggested actions or considerations following the discussion.

3. Proposals

Proposals are formalized and posted by Councils in the proposals category of the Mangrove DAO forum. These proposals may originate from community-submitted ideas discussed in the temp check category or from the Councils themselves.

The structure of proposals mirrors that of the discussions in section 3.2, with the addition of a unique identifier. Proposals should include:

  • Header: A unique ID constructed as ‘MIP’ followed by a chronological number (e.g., MIP1, MIP2), title, authors, date, and type (protocol or ecosystem).
  • Body: As outlined in section 3.2, including summary, rationale, specification, and optional disclaimer and next steps.

Proposals must be submitted on the forum for comments and deliberation at least 5 days before any voting occurs. This period is crucial for participatory deliberation, allowing proposals to be refined and improved based on community feedback. Authors are required to make all edits visible, either through tracked changes or by adding subsequent posts, ensuring that any modifications to the original proposal are easily identifiable.

4. Voting

Voting is conducted on Snapshot. Only council members can initiate votes. The following groups each represent one third of the total voting power in general governance:

  • MGV Token Holders: Their voting weight is proportional to the number of held or vested tokens compared to the total circulating supply of MGVs.
  • Builders Group: The voting power of Builders is based on an activity score reflecting their period of contribution and full-time engagement. Quadratic voting is applied to balance voting power discrepancies within the group.
  • Pods Group: Comprising teams of strategists and developers, Pods initially have equal voting influence. Eventually, their voting power will be proportional to the economic value they generate for the protocol.

Key voting parameters:

  • Proposals must be posted in the proposals category of the Mangrove DAO forum at least 5 days before voting on Snapshot.
  • The voting duration should be a minimum of 5 days, include one weekend day, and not exceed 7 days.
  • A quorum of 5% is required, calculated based on thrice the circulating supply of MGV tokens to equally empower Builders and Pods alongside MGV holders.
  • Delegation is available to voters in every group.

5. Execution

Councils are responsible for implementing governance decisions. The Protocol Council handles ‘protocol’ type proposals, while the Ecosystem Council manages ‘ecosystem’ proposals. On-chain executable proposals are processed by the relevant Council’s multisig.

6. Changes to Governance Process

This governance process is subject to evolution. Any modifications require general governance approval.

7 Likes
2

Thanks @phil for creating this proposal !

Defining a clear governance framework is highly important and requires to consider many potential future scenarios to make sure it’s included & that the governance will remain clear & easy to follow what happened in the past.

I also believe having a hierarchy of topics is important as not all proposals can have the same impact on the protocol, so not all votes should have the same parameters (I’ll propose & explain an alternative at the end of this comment).

From my understanding the 3 proposals posted are all temp checks, so the mention to MIP-1 is a bit confusing.

As mentioned on the model v0 post, I recognize that this pre proposal step (Temp Checks) would help having the final proposal reflecting the snapshot and overall clarify the governance, but I’m concerned that the amount of steps might reduce efficiency by requiring a long delay from posting a temp check to executing the vote if approved.

If this TC step is kept in the process, the status of the proposal should also be mentioned in the title imo. By including the type as well, we could imagine something like “METC” or just “ETC” for Mangrove Ecosystem Temp Check as it’s a bit long and “MPTC” for Mangrove Protocol Temp Check.

For example, the title of this post could be METC - Establishing Governance Process v0, which also highlights why the post doesn’t have a number.

To prevent cases like proposals with twice the same chronological number, several DAOs are posting the proposals as “MIP-XX” and authors/moderators can update with the right number once submitted to vote.

I suggest adding/update the following mentions in TC/Proposals body:

  • Update “Summary”: One liner explaining the proposal idea
  • Add “Context”: Contextual info for submitting this proposal
  • Update “Specifications”: Includes technical implementations if any
  • Add “Voting Options”: Clearly define choices proposed (Yes/No/Abstain or Option 1,2,3/No/Abstain depending on the proposal)
  • Add “Poll”: Submit a poll to gauge the community sentiment before the vote

I shared my thoughts about this on the model v0 post too, but it seems restrictive to rely on councils only to move from TC to final proposal on the forum.

It makes sense to rely on councils to submit the proposals on Snapshot, but there is also the possibility to add a minimum amount of tokens held/delegated to be able to submit a proposal, enabling important contributors holders to do it as well.

What’s the proposed duration for the temp checks ? This would help clarify the total duration required to execute an action.

For example if TC can be moved to MIP after 5 days as well, the max duration would be 5 + 5 + 7 = 17 days before being able to execute any proposal, which seems too long.

If the goal is to have most of the discussions/changes in temp checks, why not add 3 days duration there and reduce the governance forum duration to 1 day with a poll which confirms the final version, which reduces the total to 11 days.

Agree with including one weekend day, but defining clear governance guidelines shouldn’t include variable voting duration which can be confusing/create conflicts on a proposal validity imo (unless if the framework includes several categories with specific parameters)

5% quorum is usually easy to reach by a few voters so seems very low to decide on any protocol decision imo. If the unique proposal category model is retained, I’d suggest increasing the quorum to 15-20% which is closer to the norm. A voting differential could also be added in the key parameters.

Alternative multi-categories framework

As mentioned above, following this post with an alternative design for governance proposals, which includes several categories and associated parameters for each.

Outside of bringing clarity on the DAO actions, it also allows to not require the same governance involvement depending on the risks for the protocol. A similar framework was initially proposed on APWine Finance, and Implemented on Paladin, Mimo Labs, Kuma Protocol and Spiral DAO.

This framework includes up to 4 categories:

  • Integration Request (MIR)
  • Governance Management (MGM)
  • Improvement Protocol (MIP)
  • Emergency Protocol (MEP)

Context for of each category can be found below

Integration Request - IR

  • Scope: Includes Whitelisting of assets/protocols, gauges & marketing partnerships
  • Voting period: 3 days
  • Admin rights: Here it would depend on topic to define which council
  • Quorum: 10%
  • Voting differential: TBD if added

Governance Management - GM

  • Scope: Anthing related to ressources so committee fundings, expenses, treasury management, incentives programs and other topics (i.e branding)
  • Voting period: 5 days
  • Admin rights: Here would be Ecosystem Council
  • Quorum: 15%
  • Voting differential: TBD if added

Improvement protocol - IP

  • Scope: Any topic critical or high importance for the protocol (Signers elections, changes in contracts, new dapp, protocol fees update, governance framework update etc)
  • Voting period: 7 days
  • Admin rights: Here it would be Protocol Council
  • Quorum: 20%
  • Voting differential: TBD if added

Emergency Protocol - EP

  • Scope: Circumstances the council can take immediate actions to protect users funds/protocol and publish a post mortem on the forum explaining the non voted tx & proposing the next steps to get back to normal
  • Voting period: 1 day
  • Admin rights: Here would be associated council depending on issue
  • Quorum: 5%
  • Voting differential: None

Considering the mangrove governance is expected to have a reduced amount of proposals compared to others projects thanks to the councils very large scopes, not all of these categories might be required.

  • Mangrove Integration Request - MIR: While this one might be needed in the future, the associated topics are often linked to the tokenomics (not live yet) and/or an important demand of integration (i.e assets listings, protocols whitelists, gauges) which is not the case yet.

  • Mangrove Emergency Protocol - MEP: Considering councils scope will be large enough to potentially cover potential issues, the emergency protocol will most likely be implied so the category is not required.

I believe we could start with two categories and potentially add MIR at a later stage:

  • Mangrove Governance Management - MGM: This one is important to follow treasury management over time imo, so I think it would be a great addition.

  • Mangrove Improvement Protocol - MIP: This one already exists but should be refocused about the topics that can have high/critical impact on the protocol.

Implementation:

  • Forum: Create each category (potentially with sub-categories Approved/Denied)
  • Snapshot: Publish all proposals in the same space, or create sub-spaces for each category

Pros:

  • Implements a hierarchy in topics importance for governance proposals
  • Add a clear classification of previous proposals by category

Cons:

  • Snapshot doesn’t enable to follow a percentage of supply, so it’s required to track & update the right quorum when it changes before a proposal (Also the case with a single category btw)
  • More complex framework which can lead to errors if not understood / aware
Consider multi-categories proposals framework ?
  • Yes
  • No
  • Abstain
0 voters
3 Likes
3

Thank you, @philh, for the insightful proposal outlining Mangrove DAO’s governance processes.

Clear processes are essential, yet I anticipate a learning and adaptation phase to validate and refine them. As the governance model becomes operational and we gather data, these processes will naturally evolve.

Effective communication guidelines are crucial to ensure forum posts contain all the necessary information for informed decision-making. I propose we take it further with template documents for members to download and use, encouraging adherence to our recommended structure.

Regarding the Temp Check

I concur with @Dydymoon on the importance of a clear title indicator. The adoption of “Mangrove Temp Check (MTC)” or “Mangrove Request For Comment (MRFC)” would enhance clarity and forum navigation.

For Proposals

@Dydymoon’s suggestions are also relevant:

  • Assign Improvement Proposal numbers closer to final submission to maintain sequential order.
  • Include either Context or Rationale for depth.
  • Voting Options could offer more nuanced choices than simple yes/no.
  • Forum Polls might be valuable, though their impact should be carefully considered due to potential manipulation.

It’s important to remember that most decisions will be managed by the council, not through snapshots, except for sensitive or controversial ones. The councils offer expertise and strategic oversight, ensuring efficient progress.

Further with regards to governance timelines:

We shouldn’t rush decisions of exceptional nature. Community engagement is key, and we need to allow ample time for this, especially considering that not all members can dedicate full-time attention to Mangrove. A 17-day governance process seems like an absolute minimum for thorough deliberation.

In this context, @Dydymoon’s multi-category classification framework makes sense and could be adapted to our unique needs, with different timelines for various types of decisions and calibrated thresholds based on Mangrove-specific data.

I support establishing a token threshold for direct community proposals. It would serve as an accountability measure for the council and empower community members, whilst ensuring that proposals reflect a substantial portion of our ecosystem. We should refine these thresholds as we learn more about our circulating and active voting power.

Thanks to everyone involved in shaping this proposal. I look forward to seeing how these ideas positively influence our DAO’s evolution.

4 Likes
4

If this TC step is kept in the process, the status of the proposal should also be mentioned in the title imo. By including the type as well, we could imagine something like “METC” or just “ETC” for Mangrove Ecosystem Temp Check as it’s a bit long and “MPTC” for Mangrove Protocol Temp Check.

For example, the title of this post could be METC - Establishing Governance Process v0, which also highlights why the post doesn’t have a number.

Interesting! Initially, I wanted to have this category as open and welcoming as possible, so that any sort of idea could be shared. But it’s true that calling it ‘temp check’ makes it formal, and there’s already a ‘General’ category. Participants will likely post topics in ‘temp check’ only as a preparation step to a vote. So I agree that we can make that obvious in the title as well.

I’d rather stay clear of obscure acronyms though. We might just use [DRAFT] or [RFP]. Same result, less friction. :+1:

To prevent cases like proposals with twice the same chronological number, several DAOs are posting the proposals as “MIP-XX” and authors/moderators can update with the right number once submitted to vote.

As of now, only the Ecosystem Council can add a new topic in the Proposals category, so there’s no such risk. Temp check category is opened to anyone, but there’s no need for a chronological number here.

I suggest adding/update the following mentions in TC/Proposals body:
(…)

I kept it short in order to avoid over-engineering the governance process, especially at the beginning. I’d like to keep the template as simple as possible and to let people use their judgement when using it, rather than being formal and bureaucratic. Over time, we can add more details brought about by our experiments. With that in mind, let me review your suggestions:

  • “One liner” instead of “concise”: over-specification IMHO
  • “Context”: very hard to distinguish from “Rationale”, and a good rationale needs context. In practice, people mix both — so again, it sounds like unnecessary formalism to me
  • “Specifications”: at this stage, the gov process is offchain only, so no technical implementation to be voted and deployed as a result
  • “Voting options”: I agree that sometimes, the way the question is asked is as important as the question itself. Not always though. I’d rather let people decide and let everyone sees it on Snapshot, but we could suggest to mention it in the specification or as an optional item indeed. I’ll update accordingly :+1:
  • add “Poll”: polls should be optional IMO. But indeed, we could have it mentioned in Discussions section, when an idea is gaining traction but its proponents feel that they need an additional reality check. I will add the mention! :+1:

I shared my thoughts about this on the model v0 post too 1, but it seems restrictive to rely on councils only to move from TC to final proposal on the forum.

It makes sense to rely on councils to submit the proposals on Snapshot, but there is also the possibility to add a minimum amount of tokens held/delegated to be able to submit a proposal, enabling important contributors holders to do it as well.

Agree. See also a related discussion here.

I’ll update the proposal to include the possibility for token holders to submit a proposal on Snapshot without depending on the Ecosystem Council (provided that there’s enough support in delegated tokens). :+1:

What’s the proposed duration for the temp checks ? This would help clarify the total duration required to execute an action.

Agree with including one weekend day, but defining clear governance guidelines shouldn’t include variable voting duration which can be confusing/create conflicts on a proposal validity imo

There have been multiple offline conversations following the posting of this draft. I’d like to reiterate the proposition to have temp checks recommended but optional (periodic council elections do not need a temp check, for instance). However, as you point it out, it can happen that most of the deliberation is done on the temp check and that the proposal is then posted without requiring more discussion.

Again, I’d like to be as flexible as possible and provide guiding recommendations rather than rigid rules, especially at the beginning. I don’t think there’s any upside in strictly enforcing fixed delays. It might be too short or too long, depending on the circumstances.

I’d go for recommending at least 5 days of deliberation before a proposal is brought to vote, regardless of where it is done (temp checks or proposals categories), and 5 days for voting, as a minimum and default period. It’s not in the interest of anyone to drag proposals for ever, so I trust that the whole process would be generally swift, unless there are actual reasons to slow it down.

5% quorum is usually easy to reach by a few voters so seems very low to decide on any protocol decision imo. If the unique proposal category model is retained, I’d suggest increasing the quorum to 15-20% which is closer to the norm. A voting differential could also be added in the key parameters.

Great suggestions. I’ll amend the proposal to take them into account.

NB: My experience is that even 5% quorum is not always easily reached, we must have different DAOs in mind. But with our multi-stakeholder governance, it should be much easier to reach this minimal participation.

BTW @Dydymoon if you have data regarding minimum voting quorums and proposal support from small and large DeFi DAOs, it would be great to have a look :slight_smile:

As mentioned above, following this post with an alternative design for governance proposals, which includes several categories and associated parameters for each.

I understand the value of sophisticated rules and categorization, but I’d rather go for a leaner approach.

There are already many new governance features in our DAO that people need to learn about. I tried to remove everything that is not absolutely needed at launch, in order to reduce the cognitive effort for everyone. This is why I didn’t include the requirement of a super-majority for meta-governance decisions, for instance, even though it was in our working documents.

That is to say that I’m not opposed to your suggestion, but I’d rather have it discussed after we have a chance to experiment the process and learn some lessons. Let’s see in one or two councils’ mandates what sort of proposals we actually vote, and what can be done to make the process more efficient. Some vote categories might not be needed at all, actually (like Emergency, which is likely to be handled directly by the Protocol Council).

2 Likes