Title: Formalising Governance Processes
Related Discussions: [Ideation] Formulating the Proposal Lifecycle
Submission Date: 9 January, 2023
- 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.
The proposal will first run through the proposed governance stages, then suggested proposal categories and templates (including the fast track proposal’s special case).
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.
- 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:
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.
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.
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.
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.
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.
- 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.
- Pros and Cons of This Proposal
- Standardise the governance process so it is clear for all DAO participants.
- Offer a reference point for DAO process disputes.
- Easier onboarding process for new community members.
- Further decentralises the governance process to the community
- Community members need to adapt new proposal process and naming system.
- 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