eIP 45: Formalise Governance Processes

[SuperPat]

2023-01-09T00:00:00Z→2023-01-15T00:00:00Z

Title: Formalising Governance Processes

Author(s): @SuperPat (special thanks to @Carebbear for making the flowcharts)

Related Discussions: [Ideation] Formulating the Proposal Lifecycle

Submission Date: 9 January, 2023

1. Simple Summary:

This proposal aims to formalise the governance processes and forum/proposal set-up to provide a clearer structure to support a more robust DAO.

2. Abstract:

The proposal will first run through the proposed governance stages, then suggested proposal categories and templates (including the fast track proposal’s special case).

3. Motivation:

Currently, the governance process is known to the community as not fully standardised. There is often confusion regarding proposal categories, what information is required to include in the proposal, proposal stages and responsibilities of moving proposals through each stage.

This issue is magnified when onboarding new community members. This proposal seeks to formalise the proposal process with the community, and standardise the proposal templates before updating the information in related docs and guidelines.

4. Specification/Body Text:

4 Proposal Stages

Currently, proposals have to go through “Ideation” → RFC (7 days) → eIP (7 days) → Snapshot (Off-chain, 6 days) → execution. This is six different stages, resulting in a minimum of 4-5 weeks needed for a successful proposal to be implemented, which isn’t adaptive enough to react to the fast-changing environment in DeFi.

This proposal proposes the following changes to be adopted and to shorten the default proposal lifecycle to 14 days:

1. Ideation: The proposer discusses with community members and drafts the RFC proposal formally on the forum, informally in Discord or in private chats. The best place for proposal ideation is Euler Discord’s #Discussion channel under the Governance category.

2. RFC (Request For Comment): The proposer drafts a proposal and publishes it on the forum for open community discussion and feedback. The proposal should include categories in the title, and follow the corresponding template (see the templates below) before publishing under either eIP/Grant Proposal/General Proposal category (see more about these categories below) with the “RFC (Request For Comment)” subcategory tag. This stage shall last for 6 days to ensure there is enough time for the community to give feedback, though it is possible to extend it with community members’ or proposers’ explicit written requirements (as a comment under the proposal). The proposal should include a poll option at the end of the proposal (see examples in the templates below) for the purpose of the community temperature check. Once the temperature check has passed (see more about temperature check below) and the community and proposal initiator have deemed enough feedback is received, it can proceed to the Formal Submission stage.

3. Formal Submission (Rename from eIP stage): Previous RFC proposal will be re-published as a new comment under the same proposal forum thread including changes that incorporates community feedback. The proposer will also need to edit the proposal title to include a sequential number, eg. change the title from “eIP: Promote LUSD to Cross Tier” to “eIP 39: Promote LUSD to Cross Tier”, and change the proposal’s subcategory from “RFC (Request For Comment)” to “Formal Submission”. The formal submission stage will last for 2 days to allow a final review of the proposal and challenges. This period is extendable with the community’s or the proposer’s written request as a forum comment before it’s published on Snapshot for voting. No temperature-checking poll is needed for this stage.

4. Snapshot Off-chain Voting/Live Vote: To publish a proposal on Snapshot, the proposer needs to have a minimum of 500 EUL delegated (self-delegation is possible before the proposal goes live), or a Recognised Delegate can assist in publishing it with advance notice. The proposal subcategory on the forum should be changed from “Formal Submission” to “Live Vote”. A forum comment should be made by the proposer under the proposal thread to announce the Snapshot vote going live with a link to the Snapshot vote attached. The Snapshot vote will last for 6 days, and the vote result will determine whether the proposal will be executed or not.

5. Implementation/Voted Proposal: Successful proposals will be passed on to relevant teams for execution and there will be no further actions required for failed proposals. Once Snapshot voting ends, the proposal subcategory should be changed from “Formal Submission” to “Voted Proposal”. A forum comment should be made by the proposer under the proposal thread to announce the result of the Snapshot vote and whether further actions will be made.

• Note: Fast track proposals will have a different lifecycle, please see the section below

RFC Temperature Checking Polls

An RFC Temperature Checking Poll is a poll inserted at the bottom of RFC proposals to check with the community whether the proposal has enough community interest and support before progressing to the Formal Submission stage.

The poll should always contain 3 single-choice options:

• Yes, in favour of the proposal
• No, against the proposal
• Modify the proposal

To be considered as “passing” the temperature check, the proposal’s poll should pass the following 2 criteria: 1) gain >8 unique voters; 2) have more than 51% of total voters voting in favour of the proposal. Please be mindful that any attempts to game the temperature check will result in the immediate delisting of the proposal from the forum.

An example of RFC Temperature Checking Poll from RFC: Delegate Optimisations in Governance: 2 - Recognised Delegates.

3 Proposal Categories

This proposal proposes 3 proposal categories: eIP (Euler Improvement Proposals), Grants Proposals and General Proposals. Each proposal will have the standardised format proposed below, which will be included in the pinned post for each category on the forum.

• eIP – Changes in risk parameters relating to an asset, eg. borrow/collateral factors, asset tier upgrade/downgrade, or affecting the Euler protocol. eIP Proposal Template
• Grant Proposal – A request for funding from the DAO for an improvement task. Grant Proposal Template
• General – Other types of proposals, including marketing and events. General Proposal Template

Visualisation of new categories on the forum

To signal the proposal type to governance participants, the proposal categories should be included in the proposal title, for example, “eIP 39: Promote LUSD to Cross Tier”, the sequential number can be skipped at the RFC stage.

Example of publishing an eIP proposal in the RFC (Request For Comment) subcategory.

This proposal does not suggest changing the names of previous proposals. lf this proposal passes the new naming system should only apply to future proposals and will not be retroactive.

Fast Track Proposal Process

Fast track proposals, due to their urgent nature, require a lifecycle as short as 24 hours. A fast track proposal does not need to go through the RFC stage, and it will be published on the forum as a live proposal and Snapshot for voting simultaneously. The voting results will be concluded after 24 hours and successful proposals will be passed on to the relevant team for implementation.

The proposal category of a fast track proposal should follow the 3 default categories, with “[Fast track]” included in the proposal title, for example “[Fast track] eIP 31: Move WBTC oracle to an explicit WBTC Chainlink Oracle. Here “[Fast track]” signals the urgent nature of the proposal and the application of 24h proposal lifecycle, while “eIP” means it’s an Euler Improvement Proposal related to protocol/asset parameter changes.

Example of a Fast Track eIP proposal published with “Live vote” subcategories on the forum.

As fast track proposals usually involve high-priority and important updates to the protocol, the ability to propose fast track proposals will be limited to Euler Labs contributors and Recognised Delegates. This will be further decentralised with time.

5. Next steps

After the proposal passes, the relevant section in the Gitbook documentation will be updated. Forum categories will be restructured, with detailed guidance and proposal templates included in the pinged post for each category.

6. Pros and Cons of This Proposal

Pros:

1. Standardise the governance process so it is clear for all DAO participants.
2. Offer a reference point for DAO process disputes.
3. Easier onboarding process for new community members.
4. Further decentralises the governance process to the community

Cons:

1. Community members need to adapt new proposal process and naming system.
2. In the immediate future, it may be confusing for community members to see both the old and new naming systems existing on the forum and Snapshot.

• Yes, in favour of the proposal
• No, against the proposal
• Modify the proposal

[patria]

in favor of anything that will shorten and simplify the process

[knightsemplar]

Great detail as always @SuperPat. This makes things a lot more clear. Thank you.

[Matt_StableLab]

@superpat @carebbear Amazing proposal! it’s great to see Euler taking governance so seriously and making the process clear for all to understand.

We just have a few notes:

1. We recommend keeping the ideation stage in the forums to prevent fragmented discussions.

2. Who are the recognized delegates mentioned that can post the fast-track proposal?

3. We should have proposal stages documented on proposals to keep it clear what stage a [RFC] is in.

• Stage: RFC(Draft) - Community Feedback
• Stage: RFC (Proposed) - 6 day waiting period (no changes allowed here)
• Stage: Formal Submission - 2 day waiting period

4. We recommend a waiting period before resubmitting a failed proposal.

• Thoughts on 10 days?
• Resubmitted proposals should summarise the major changes to the proposal compared to the previous stage.

5. Is there somewhere where the Euler team can keep the community updated on what successful proposals are still in the process of being implemented and the expected time it will take to implement them?

[Raslambek]

Thank u @SuperPat and @Carebbear for bringing this proposal. Decreasing the proposal lifecycle is a huge contribution to the DAO development and I fully support it!
At the same time, may I ask for some clarifications:

To publish a proposal on Snapshot, the proposer needs to have a minimum of 500 EUL delegated (self-delegation is possible before the proposal goes live), or a Recognised Delegate can assist in publishing it with advance notice.

• Why only Recognised Delegate could assist in creating a Snapshot? The DAO has Active Delegates and Public Delegates as well. Imho, the very nature of a public delegate allows him/her to create votes.
• As for the Recognised Delegates, despite Im 100% in favour of launching this programme, atm it is clear that without consent from lemniscap or support of a bigger EUL holder, the RD programme is unlikely to be launched. In this regard, I would rather avoid mentioning RD before it is live.

3 Proposal Categories

As previously, I still have some concerns regarding the General category. Just curious, what category would this proposal be published to?

As fast track proposals usually involve high-priority and important updates to the protocol, the ability to propose fast track proposals will be limited to Euler Labs contributors and Recognised Delegates.

With the RD’s programme is till tbc, only EulerLabs team appear to be able to submit Fast Track proposals. That does not look very decentralised.

Please be mindful that any attempts to game the temperature check will result in the immediate delisting of the proposal from the forum.

Who is going to investigate whether the temperature check is gamified or not? And who is empowered to delist this proposal? What if the opposite side tries to game the temperature check? I mean, if someone does not like a proposal and tries to game it?

Btw, I really liked the system with 24H notice prior the start of the vote. I think it could be incorporated into this proposal.

[jengajojo]

Thank you @SuperPat for building on top of [Ideation] Formulating the Proposal Lifecycle and suggesting to formalize the process with this post.

@SuperPat

To be considered as “passing” the temperature check, the proposal’s poll should pass the following 2 criteria: 1) gain >8 unique voters; 2) have more than 51% of total voters voting in favour of the proposal.

Is it possible to gate this forum to prevent sybil attacks? If not a temporary fix could be hosting polls in discord and allowing members with specific tags to be able to vote.

@Matt_StableLab

1. We should have proposal stages documented on proposals to keep it clear what stage a [RFC] is in.

• Stage: RFC(Draft) - Community Feedback
• Stage: RFC (Proposed) - 6 day waiting period (no changes allowed here)
• Stage: Formal Submission - 2 day waiting period

4. We recommend a waiting period before resubmitting a failed proposal.

I second this suggestion

[Carebbear]

Hey @Matt_StableLab thank you for your comments.

@Matt_StableLab

We recommend keeping the ideation stage in the forums to prevent fragmented discussions.

1. So far, most of the discussions were on Euler Labs discord and this is very hard to change.

@Matt_StableLab

Who are the recognized delegates mentioned that can post the fast-track proposal?

2. Good catch, since the recognized delegates program has not passed. We should address this.

@Matt_StableLab

We should have proposal stages documented on proposals to keep it clear what stage a [RFC] is in.

• Stage: RFC(Draft) - Community Feedback
• Stage: RFC (Proposed) - 6 day waiting period (no changes allowed here)
• Stage: Formal Submission - 2 day waiting period

3. Currently, users have the ability to edit their posts within 24 hours after they have been initially posted. This feature allows users to make corrections or clarifications to their posts within a specific time frame, reducing the need for moderation and allowing for easier adjustments to be made without having to create a new post.

   This ensures that the post will not be updated after that period and simplifies the process. Proposers should have gathered feedback from the community before posting the proposal in the “Idea” category or on Discord in the governance “discussion” channel if they are unsure how the proposal will be received by the community.

@Matt_StableLab

We recommend a waiting period before resubmitting a failed proposal.

4. This makes sense and I think we should.

@Matt_StableLab

Is there somewhere where the Euler team can keep the community updated on what successful proposals are still in the process of being implemented and the expected time it will take to implement them?

5. Also, another great suggestion. What do you think would be best here, DIscord or Forums?

[Carebbear]

Thank you, @Raslambek for your support. Let me address some of your concerns.

@Raslambek

To publish a proposal on Snapshot, the proposer needs to have a minimum of 500 EUL delegated (self-delegation is possible before the proposal goes live), or a Recognised Delegate can assist in publishing it with advance notice.

You are right, anyone who holds 500 EUL can help with the proposal here.

@Raslambek

As previously, I still have some concerns regarding the General category. Just curious, what category would this proposal be published to?

This proposal would fall in that general category.

@Raslambek

With the RD’s programme is till tbc, only EulerLabs team appear to be able to submit Fast Track proposals. That does not look very decentralised.

Since the Recognized Delegates proposal was not approved, we have two options: proceed with only the Euler Labs team proposing the fast-track proposals for now, or remove the fast-track proposal aspect until a version of the Recognized Delegates program is implemented.

@Raslambek

Who is going to investigate whether the temperature check is gamified or not? And who is empowered to delist this proposal? What if the opposite side tries to game the temperature check? I mean, if someone does not like a proposal and tries to game it?

Btw, I really liked the system with 24H notice prior the start of the vote. I think it could be incorporated into this proposal.

As of now, the forum administrators will be responsible for investigating if any vote manipulation occurred and will present their findings to the community.

Additionally, with the current proposal, there is a 48-hour notice before the start of the voting period, with the formal submission stage lasting for 2 days.

[Carebbear]

Title: eIP 45 : Formalising Governance Processes

Author(s): @SuperPat , @Carebbear ,@river0X )

Related Discussions: [Ideation] Formulating the Proposal Lifecycle

Submission Date: 20 January 2023

1. Simple Summary:

This proposal aims to formalise the governance processes and forum/proposal set-up to provide a clearer structure to support a more robust DAO.

2. Abstract:

The proposal will first run through the proposed governance stages, then suggested proposal categories and templates (including the fast-track proposal’s special case).

3. Motivation:

Currently, the governance process is known to the community as not fully standardised. There is often confusion regarding proposal categories, what information is required to include in the proposal, proposal stages and responsibilities of moving proposals through each stage.

This issue is magnified when onboarding new community members. This proposal seeks to formalise the proposal process with the community, and standardise the proposal templates before updating the information in related docs and guidelines.

4. Specification/Body Text:

Proposal Stages

Currently, proposals have to go through “Ideation” → RFC (7 days) → eIP (7 days) → Snapshot (Off-chain, 6 days) → execution. This is six different stages, resulting in a minimum of 4-5 weeks needed for a successful proposal to be implemented, which isn’t adaptive enough to react to the fast-changing environment in DeFi.

This proposal proposes the following changes to be adopted and to shorten the default proposal lifecycle to 14 days:

1. Ideation: The proposer discusses with community members and drafts the RFC proposal formally on the forum, informally in Discord or in private chats. The best place for proposal ideation is Euler Discord’s #Discussion channel under the Governance category.

2. RFC (Request For Comment): The proposer drafts a proposal and publishes it on the forum for open community discussion and feedback. The proposal should include categories in the title, and follow the corresponding template (see the templates below) before publishing under either eIP/Grant Proposal/General Proposal category (see more about these categories below) with the “RFC (Request For Comment)” subcategory tag.

   When creating a proposal, the proposer should specify the start and end date of the proposal using the time and date option. The default duration for this stage is 6 days, but if the proposer feels that they did not receive enough comments or wants to extend the discussion, they may do so by adding a written comment in a reply post to the thread, with a maximum duration of an additional 7 days.

   The proposal should include a poll option at the end of the proposal (see examples in the templates below) for the purpose of the community temperature check. Once the temperature check has passed (see more about temperature check below) and the community and proposal initiator have deemed enough feedback is received, it can proceed to the Formal Submission stage.

3. Formal Submission (Rename from eIP stage): Previous RFC proposal will be re-published as a new comment under the same proposal forum thread including changes that incorporates community feedback. The proposer will also need to edit the proposal title to include a sequential number, eg. change the title from “eIP: Promote LUSD to Cross Tier” to “eIP 39: Promote LUSD to Cross Tier”, and change the proposal’s subcategory from “RFC (Request For Comment)” to “Formal Submission”.

   The formal submission stage will last for 2 days to allow a final review of the proposal and challenges. This period is extendable with the community’s or the proposer’s written request as a forum comment before it’s published on Snapshot for voting. No temperature-checking poll is needed for this stage.

4. Snapshot Off-chain Voting/Live Vote: To submit a proposal on Snapshot, the proposer must have a minimum of 500 EUL delegated to them. This can be achieved through self-delegation, or by reaching out to a delegate who already has that amount delegated to them and asking them to create the proposal on their behalf. The proposal subcategory on the forum should be changed from “Formal Submission” to “Live Vote”. A forum comment should be made by the proposer under the proposal thread to announce the Snapshot vote going live with a link to the Snapshot vote attached. The Snapshot vote will last for 6 days, and the vote result will determine whether the proposal will be executed or not.

5. Implementation/Voted Proposal: Successful proposals will be passed on to relevant teams for execution and there will be no further actions required for failed proposals. Once Snapshot voting ends, the proposal subcategory should be changed from “Formal Submission” to “Voted Proposal”. A forum comment should be made by the proposer under the proposal thread to announce the result of the Snapshot vote and whether further actions will be made.

• A thread will be created in the main eIP category to provide updates on the status of proposals that have passed and are waiting to be implemented.This will improve the visibility and overview of all updates that are yet to be implemented.

• If a proposal does not pass but still receives support from the community, it may be reintroduced no sooner than 10 days after the voting period for the original proposal has ended.

• Note: Fast-track proposals will have a different lifecycle, please see the section below

RFC Temperature Checking Polls

An RFC Temperature Checking Poll is a poll inserted at the bottom of RFC proposals to check with the community whether the proposal has enough community interest and support before progressing to the Formal Submission stage.

The poll should always contain 3 single-choice options:

• Yes, in favor of the proposal
• No, against the proposal
• Modify the proposal

To be considered as “passing” the temperature check, the proposal’s poll should pass the following 2 criteria: 1) gain >8 unique voters; 2) have more than 51% of total voters voting in favour of the proposal. Please be mindful that any attempts to game the temperature check will result in the immediate delisting of the proposal from the forum.

An example of RFC Temperature Checking Poll from RFC: Delegate Optimisations in Governance: 2 - Recognised Delegates.

3 Proposal Categories

This proposal proposes 3 proposal categories: eIP (Euler Improvement Proposals), Grants Proposals and General Proposals. Each proposal will have the standardised format proposed below, which will be included in the pinned post for each category on the forum.

• eIP – Changes in risk parameters relating to an asset, eg. borrow/collateral factors, asset tier upgrade/downgrade, or affecting the Euler protocol. eIP Proposal Template
• Grant Proposal – A request for funding from the DAO for an improvement task. Grant Proposal Template
• General – Other types of proposals, including marketing and events. General Proposal Template

Visualisation of new categories on the forum

To signal the proposal type to governance participants, the proposal categories should be included in the proposal title, for example, “eIP 39: Promote LUSD to Cross Tier”, the sequential number can be skipped at the RFC stage.

Example of publishing an eIP proposal in the RFC (Request For Comment) subcategory.

This proposal does not suggest changing the names of previous proposals. lf this proposal passes, the new naming system should only apply to future proposals and will not be retroactive.

Fast Track Proposal Process

Fast-track proposals, due to their urgent nature, require a lifecycle as short as 24 hours. A fast-track proposal does not need to go through the RFC stage, and it will be published on the forum as a live proposal and Snapshot for voting simultaneously. The voting results will be concluded after 24 hours, and successful proposals will be passed on to the relevant team for implementation.

The proposal category of a fast track proposal should follow the 3 default categories, with “[Fast track]” included in the proposal title, for example “[Fast track] eIP 31: Move WBTC oracle to an explicit WBTC Chainlink Oracle. Here “[Fast track]” signals the urgent nature of the proposal and the application of 24h proposal lifecycle, while “eIP” means it’s an Euler Improvement Proposal related to protocol/asset parameter changes.

Example of a Fast-track eIP proposal published with “Live vote” subcategories on the forum.

Fast-track proposals, which typically involve urgent and significant updates to the protocol, will only be able to be proposed by Euler Labs contributors until a version of the Senior Delegates program is implemented. This will be further decentralised with time.

Next steps

After a proposal is approved, the related documentation in the Gitbook will be updated. The forum categories will be reorganized and guidance will be provided for creating proposals, with templates automatically filling in when creating an RFC.

Pros and Cons of This Proposal

Pros:

1. Standardise the governance process so it is clear for all DAO participants.
2. Offer a reference point for DAO process disputes.
3. Easier onboarding process for new community members.
4. Further decentralises the governance process to the community

Cons:

1. Community members need to adapt new proposal process and naming system.
2. In the immediate future, it may be confusing for community members to see both the old and new naming systems existing on the forum and Snapshot.

Voting

Options are:

YES - implement the changes above
NO - do not implement the changes above

Snapshot

Link

[chainguys]

looks great

Let’s try see if it works