Establishing Governance Process v0

[Dydymoon]

@philh

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.

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

@philh

2. Discussions

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

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.

@philh

3. Proposals

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

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

@philh

Proposals are formalized and posted by Councils in the proposals category of the Mangrove DAO forum.

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.

@philh

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:

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.

@philh

Key voting parameters:

• Proposals must be posted in the proposals category of the Mangrove DAO forum at least 5 days before voting on Snapshot.

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.

@philh

The voting duration should be a minimum of 5 days, include one weekend day, and not exceed 7 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)

@philh

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.

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