[Ideation] Formulating the Proposal Lifecycle

Status
forum discussion
Tags
Ops
Date
Outcome
Accepted
Person
DAO
Euler
Title: [Ideation] Formulating the Proposal Lifecycle
# Author(s): [0xBaer for DAOstewards]
# Related Discussions: [N/A]
# Submission Date: [N/A]
Simple Summary: An Ideation thread on updating the current governance process and introducing a proposal lifecycle
Abstract.
The Euler DAO is looking to update its governance process and introduce a proposal lifecycle to ensure that proposals move smoothly from ideation to implementation in a trustless manner. And to allow the DAO to respond to emergencies without violating established governance processes or compromising decentralisation.
Motivation:
The Euler DAO is currently in a phase of development and is exploring its governance processes. Community members have been actively participating in discussions and decision-making regarding proposals. While there have been efforts to improve the execution of Euler governance through eIP 32 and the recent RFC for recognised delegates, the DAO still needs an explicit system for the lifecycle of proposals and a method for responding to emergencies. DAO has seen Many proposals moving through the forums needing to follow established guidelines adequately.
This ideation thread aims to determine the best way for a proposal to move from an idea to a formal proposal and an eIP, and to add checks and balances to the system to allow the DAO to quickly respond to emergencies without compromising decentralisation. This proposal combines information from various eIPs, forum posts, and documentation in one place and makes necessary changes.
This initiative strives to be the ideal example of an eIP following the designated lifecycle.
The community can contribute to the Potential RFC once this ideation thread gathers feedback [here].
# Specification:
Setting the stage
The Euler  DAO governance process takes place in the governance forum at https://forum.euler.finance.
Proposals are formally ratified through the Euler Improvement Proposal (eIPs). There are no requirements for participating in the Euler DAO discussion. Anyone can sign up for the Governance forum or Discord and engage in the conversation.
Euler DAO Governance Proposals [EGPs]
EGPs are standardised Proposals related to the DAO where any DAO member can participate in discussions, and the EUL token holders can vote.
Currently, The DAO has Euler Improvement Proposals (eIPs), which would facilitate protocol updates, Risk management of assets, and social proposals.
This Proposal also wants to establish different types of Proposals to distinguish between Executable on-chain proposals and Social proposals like treasury management, Grants or general DAO-level proposals that don't have a clear on-chain implication.
Feasible  Options
  1. 4 Types of proposals, as suggested by @superpat
    1. [Asset Parameters] – changes in parameters relating to a specific asset, e.g. borrow/collateral factors, asset tier upgrade/downgrade
    2. [Risk] – changes in risk parameters affecting the protocol/multiple assets
    3. [Grant Proposal] – a request for funding from the DAO
    4. [General] – other types of proposals
  1. 3 types of proposals
    1. General protocol improvement proposals [eIPs]which include Risk and Asset parameter updates
    2. Grants funding and treasury management proposals [tIPs]
    3. General proposals [gIPs]
  1. 2 Types of proposals
    1. Euler Protocol improvement proposals [eIP] - everything which involves the core smart contracts of Euler Protocol excluding the Community Treasury - depending on eIPs
    2. Euler Social Proposals [sIP] - Proposals don't need a parameter update or of the smart contracts and could be limited to Snapshot voting
Poll
Should we update the types of  Proposals
  1. Yes - Option 1
  1. Yes - Option 2
  1. Yes - Option 3
  1. Yes - I have another option and will comment on it
  1. No - Make no Changes to the types
Proposal Lifecycle
notion image
[Idea] ➡️ [Draft RFC] ➡️ [RFC Formalised ] ➡️ [7-day Review + voting ] ➡️ [Off-chain Poll] ➡️ [Accepted/Rejected]
Phase 0: Ideation
The Purpose of this phase is to gather a community sentiment on the idea of the author, Unique Ideas can use #idea tag on the forum and have its thread. Phase 0 proposals are generally ideated in informal settings like Discord chat or telegram group. This phase could include gathering community support on the specifications of a potential RFC with multiple in-text polls.
Time period: Open
Phase 1: Request for Comment
During this phase, proposal authors,e could ask for official community sentiment by formulating the Idea in a Request for Comment (RFC). RFC should follow the prescribed template [link to template].
During the draft stage of the RFC, the author shall include community feedback and update the proposal accordingly.
The purpose of the Draft RFC status is to gather adequate feedback and support to attain soft consensus, allowing us to proceed confidently with a formal proposal without the risk of it being immediately rejected.
Request for Comment [RFC] finalisation:
After gathering sufficient community feedback, the proposal's author formalised the proposal and did a temp check. The temp check of the finalised RFC should last seven days, and the author cannot make any changes other than minor grammatical corrections.
Time period:  7 days
Phase 2: Off-chain voting
After completing Phase 1, the author can move an  RFC to eIP, and a community moderator will assign the eIP a number. The author of the RFC can move the RFC to snapshot after 24h cool-off period.
The Snapshot votes should run for 7 days with the previously defined voting option in the eIP.  Authors can add ‘Abstain’ as an option for voters who want to abstain from voting but don't want to be penalised for abstaining.
Snapshot Parameters
Proposal Threshold: 500 EUL is needed to create a proposal
Voting Period: 7 days
Quorum: 10K EUL has to participate
The proposal is a collection of previous eIPs like eIP 19, eIP 23, and already established guidelines like 7-day cooling off period for an RFC
Poll
Should the author allowed to edit the RFC after formalising and adding the Poll
Yes
No
Q: Should the poll be open to every forum member? isn't this opening us Sybil attacks?
N: I believe the forum poll should be open to everyone, as anyone can participate in governance discussions. It is possible that an attacker could create multiple accounts in the forum to vote on their own proposal, known as a Sybil attack. However, the proposal would likely be unsuccessful in token-based voting, which requires a higher financial stake. The community can also identify and filter out such Sybil attacks early.
Handling Emergencies.
According to the lifecycle mentioned earlier, a proposal needs a minimum of 15 days to move from Phase 1 to implementation; This 15-day period will cripple the DAO to react during times of emergency eg: eIP#36, eIP #31.
Even though both eIP36 and eIP31 were emergency proposals, eIP 31 was for updating wBTC price fees, and eIP36 was to fix a minor bug in one of the smart contracts.  This raises the question of what should be considered emergency proposals and who should be proposing these proposals.
What is an emergency?
An emergency is an event that requires immediate attention from the DAO to prevent the loss of funds or a catastrophic impact on the Euler protocol. So as you know, such events require a prompt response to be effectively contained.
What elements should be should be considered an emergency
# Poll
  1. Minor bugs that could affect the protocol if not fixed but can be addressed through the 15-day process.
  1. Critical bugs which could impact the protocol if not fixed
  1. Blacklisting an asset as a reaction to sudden market changes
  1. Reducing parameters of an asset due to potential Oracle attack or liquidity shock.
Who can propose these emergency proposals?
  1. Euler Labs
  1. Risk management committee/teams authorised by the DAO in the future
How to react to emergency
  1. Allow the proposer to submit an eIP by bypassing Phase 0 and Phase 1 but with 24hr cool-off period and a reduced snapshot voting frame.
  1. Allow the proposer to submit an eIP directly to snapshot with a 48hr voting period by bypassing the forum
  1. Allow the proposer to submit eIP to the forum with a 24hr poll, a quorum of 20 votes, and a reduced snapshot voting period with a normal quorum of 10K EUL.

[Ideation] Formulating the Proposal Lifecycle

Status
forum discussion
Tags
Ops
Date
Outcome
Accepted
Person
DAO
Euler
Title: [Ideation] Formulating the Proposal Lifecycle
# Author(s): [0xBaer for DAOstewards]
# Related Discussions: [N/A]
# Submission Date: [N/A]
Simple Summary: An Ideation thread on updating the current governance process and introducing a proposal lifecycle
Abstract.
The Euler DAO is looking to update its governance process and introduce a proposal lifecycle to ensure that proposals move smoothly from ideation to implementation in a trustless manner. And to allow the DAO to respond to emergencies without violating established governance processes or compromising decentralisation.
Motivation:
The Euler DAO is currently in a phase of development and is exploring its governance processes. Community members have been actively participating in discussions and decision-making regarding proposals. While there have been efforts to improve the execution of Euler governance through eIP 32 and the recent RFC for recognised delegates, the DAO still needs an explicit system for the lifecycle of proposals and a method for responding to emergencies. DAO has seen Many proposals moving through the forums needing to follow established guidelines adequately.
This ideation thread aims to determine the best way for a proposal to move from an idea to a formal proposal and an eIP, and to add checks and balances to the system to allow the DAO to quickly respond to emergencies without compromising decentralisation. This proposal combines information from various eIPs, forum posts, and documentation in one place and makes necessary changes.
This initiative strives to be the ideal example of an eIP following the designated lifecycle.
The community can contribute to the Potential RFC once this ideation thread gathers feedback [here].
# Specification:
Setting the stage
The Euler  DAO governance process takes place in the governance forum at https://forum.euler.finance.
Proposals are formally ratified through the Euler Improvement Proposal (eIPs). There are no requirements for participating in the Euler DAO discussion. Anyone can sign up for the Governance forum or Discord and engage in the conversation.
Euler DAO Governance Proposals [EGPs]
EGPs are standardised Proposals related to the DAO where any DAO member can participate in discussions, and the EUL token holders can vote.
Currently, The DAO has Euler Improvement Proposals (eIPs), which would facilitate protocol updates, Risk management of assets, and social proposals.
This Proposal also wants to establish different types of Proposals to distinguish between Executable on-chain proposals and Social proposals like treasury management, Grants or general DAO-level proposals that don't have a clear on-chain implication.
Feasible  Options
  1. 4 Types of proposals, as suggested by @superpat
    1. [Asset Parameters] – changes in parameters relating to a specific asset, e.g. borrow/collateral factors, asset tier upgrade/downgrade
    2. [Risk] – changes in risk parameters affecting the protocol/multiple assets
    3. [Grant Proposal] – a request for funding from the DAO
    4. [General] – other types of proposals
  1. 3 types of proposals
    1. General protocol improvement proposals [eIPs]which include Risk and Asset parameter updates
    2. Grants funding and treasury management proposals [tIPs]
    3. General proposals [gIPs]
  1. 2 Types of proposals
    1. Euler Protocol improvement proposals [eIP] - everything which involves the core smart contracts of Euler Protocol excluding the Community Treasury - depending on eIPs
    2. Euler Social Proposals [sIP] - Proposals don't need a parameter update or of the smart contracts and could be limited to Snapshot voting
Poll
Should we update the types of  Proposals
  1. Yes - Option 1
  1. Yes - Option 2
  1. Yes - Option 3
  1. Yes - I have another option and will comment on it
  1. No - Make no Changes to the types
Proposal Lifecycle
notion image
[Idea] ➡️ [Draft RFC] ➡️ [RFC Formalised ] ➡️ [7-day Review + voting ] ➡️ [Off-chain Poll] ➡️ [Accepted/Rejected]
Phase 0: Ideation
The Purpose of this phase is to gather a community sentiment on the idea of the author, Unique Ideas can use #idea tag on the forum and have its thread. Phase 0 proposals are generally ideated in informal settings like Discord chat or telegram group. This phase could include gathering community support on the specifications of a potential RFC with multiple in-text polls.
Time period: Open
Phase 1: Request for Comment
During this phase, proposal authors,e could ask for official community sentiment by formulating the Idea in a Request for Comment (RFC). RFC should follow the prescribed template [link to template].
During the draft stage of the RFC, the author shall include community feedback and update the proposal accordingly.
The purpose of the Draft RFC status is to gather adequate feedback and support to attain soft consensus, allowing us to proceed confidently with a formal proposal without the risk of it being immediately rejected.
Request for Comment [RFC] finalisation:
After gathering sufficient community feedback, the proposal's author formalised the proposal and did a temp check. The temp check of the finalised RFC should last seven days, and the author cannot make any changes other than minor grammatical corrections.
Time period:  7 days
Phase 2: Off-chain voting
After completing Phase 1, the author can move an  RFC to eIP, and a community moderator will assign the eIP a number. The author of the RFC can move the RFC to snapshot after 24h cool-off period.
The Snapshot votes should run for 7 days with the previously defined voting option in the eIP.  Authors can add ‘Abstain’ as an option for voters who want to abstain from voting but don't want to be penalised for abstaining.
Snapshot Parameters
Proposal Threshold: 500 EUL is needed to create a proposal
Voting Period: 7 days
Quorum: 10K EUL has to participate
The proposal is a collection of previous eIPs like eIP 19, eIP 23, and already established guidelines like 7-day cooling off period for an RFC
Poll
Should the author allowed to edit the RFC after formalising and adding the Poll
Yes
No
Q: Should the poll be open to every forum member? isn't this opening us Sybil attacks?
N: I believe the forum poll should be open to everyone, as anyone can participate in governance discussions. It is possible that an attacker could create multiple accounts in the forum to vote on their own proposal, known as a Sybil attack. However, the proposal would likely be unsuccessful in token-based voting, which requires a higher financial stake. The community can also identify and filter out such Sybil attacks early.
Handling Emergencies.
According to the lifecycle mentioned earlier, a proposal needs a minimum of 15 days to move from Phase 1 to implementation; This 15-day period will cripple the DAO to react during times of emergency eg: eIP#36, eIP #31.
Even though both eIP36 and eIP31 were emergency proposals, eIP 31 was for updating wBTC price fees, and eIP36 was to fix a minor bug in one of the smart contracts.  This raises the question of what should be considered emergency proposals and who should be proposing these proposals.
What is an emergency?
An emergency is an event that requires immediate attention from the DAO to prevent the loss of funds or a catastrophic impact on the Euler protocol. So as you know, such events require a prompt response to be effectively contained.
What elements should be should be considered an emergency
# Poll
  1. Minor bugs that could affect the protocol if not fixed but can be addressed through the 15-day process.
  1. Critical bugs which could impact the protocol if not fixed
  1. Blacklisting an asset as a reaction to sudden market changes
  1. Reducing parameters of an asset due to potential Oracle attack or liquidity shock.
Who can propose these emergency proposals?
  1. Euler Labs
  1. Risk management committee/teams authorised by the DAO in the future
How to react to emergency
  1. Allow the proposer to submit an eIP by bypassing Phase 0 and Phase 1 but with 24hr cool-off period and a reduced snapshot voting frame.
  1. Allow the proposer to submit an eIP directly to snapshot with a 48hr voting period by bypassing the forum
  1. Allow the proposer to submit eIP to the forum with a 24hr poll, a quorum of 20 votes, and a reduced snapshot voting period with a normal quorum of 10K EUL.