[Ideation] Formulating the Proposal Lifecycle

Ideas
1

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
  • [Asset Parameters] ā€“ changes in parameters relating to a specific asset, e.g. borrow/collateral factors, asset tier upgrade/downgrade
  • [Risk] ā€“ changes in risk parameters affecting the protocol/multiple assets
  • [Grant Proposal] ā€“ a request for funding from the DAO
  • [General] ā€“ other types of proposals
  1. 3 types of proposals
  • General protocol improvement proposals [eIPs]which include Risk and Asset parameter updates
  • Grants funding and treasury management proposals [tIPs]
  • General proposals [gIPs]
  1. 2 Types of proposals
  • Euler Protocol improvement proposals [eIP] - everything which involves the core smart contracts of Euler Protocol excluding the Community Treasury - depending on eIPs
  • Euler Social Proposals [sIP] - Proposals donā€™t need a parameter update or of the smart contracts and could be limited to Snapshot voting
Should we update types of Proposals
    1. Yes - Option 1
    1. Yes - Option 2
    1. Yes - Option 3
    1. Yes - I have another option, see my comment
    1. No - Make no Changes
0 voters

Proposal Lifecycle

1600Ɨ498 50.4 KB

[Idea] :arrow_right: [Draft RFC] :arrow_right: [RFC Formalised ] :arrow_right: [7-day Review + voting ] :arrow_right: [Off-chain Poll] :arrow_right: [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

Should the author allowed to edit the RFC after formalising and adding the Poll
  • Yes
  • No
0 voters

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 not likely be successful in token-based voting, which requires a higher financial stake. The community can also identify and filter out such Sybil attacks in the early stages.

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. Such events require a prompt response to be effectively contained.

What elements should be considered as emergencies?

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.
0 voters

Who can propose these emergency proposals?

Euler Labs
  • Yes
  • No
0 voters
  1. Risk management committee/teams authorised by the DAO in the future
  • Yes
  • No
0 voters

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 standard quorum of 10K EUL.
0 voters
2 Likes
2

Hi @0xBaer! First of all, thanks for bringing this issue. Would like to comment some points.

Proposalā€™s types
As I previously pointed out, Im not very fond of the general type. As an alternative, I could suggest the following structure:

  1. Technical ( changes in parameters relating to a specific asset, e.g. borrow/collateral factors, asset tier upgrade/downgrade and changes in risk parameters affecting the protocol/multiple assets)
  2. Financial (request for funding from the DAO in a form of grants, investments, dealing with other DAOā€™s financial like the recent SAFE tokens claim)
  3. Governance (DAO structure, quorum/ threshold parameters, etc)

Phase 0: Ideation .

  • Agree with your vision that ideation should not necessarily be carried out via Forum. Instead, Discord seems to be an appropriate place for brainstrorming. At the same time, I have some doubts that TG channel should be included in the list coz otherwise it would lead to an overwhelming decentralisation (in a pejorative conotation ofc).
  • Unique Ideas can use #idea tag on the forum and have its thread. Omho, by this we count to much on a subjective assessment of an author. A way out could be to entrust a Forum moderator with this task (attributing #idea tag) or attribute this tag automatically to all new threads.
  • Time period. I could suggest also something like: Up to the authorā€™s discretion.

Request for Comment [RFC] finalisation:

  • After gathering sufficient community feedback, the proposalā€™s author formalised the proposal. Just to clarify, does it assume that the author should change the proposal based on the feedback received for his/her RFC? Or the RFC should not be changed (other than gramaticaly) since the very moment an RFC is posted? I would opt for the possibility to change it according to the DAOā€™s feedback.
  • Time period: 7 days. Maybe it is better to include minimum ? Minimum 7 days? As the history has shown, some RFC require more time then other to be properly discussed.

Phase 2: Off-chain voting

  • The Snapshot votes should run for 7 days. In the current settings the Snapshot vote lasts 6 days. Why would u like to prolong it to 7 days? I would suggest the opposite, reducing it to 5 days, coz imho it is an excessive period of time that prolong the whole process.

  • General comments regarding polls . Tbh I do regard polls as a good instrument for temp checking. Imo it discourages meaningful participartion of the community. It is always easier to click yes/no, then to present reasons why I like/ do not like something. On the other hand, polls are valuable instrument for some concrete issues within a proposal, like u did in this proposal.

  • The author of the RFC can move the RFC to snapshot after 24h cool-off period. I would add here given there are no significant changes proposed . So letā€™s assume during the RFC stage an author is not allowed to change the proposal, than after he/she collected all the feedback, the DAO will be able to look at the updated proposal in the eIP section already. Thus I believe that community should have the right to propose some significant changes before proceeding to a vote.

  • I would make the Snaphot creation process more conspicuous. I mean if an author has 500EUL delegated he/she is able to create a vote. However, if an author does not have 500 EUL then a help of someone else is needed. Probably, some of the following could be used : The author of the RFC can move the RFC to snapshot after 24h cool-off period. In case the author does not have 500EUL delegated that are required to create a vote, he/she should ask of the [public delegates](https://app.euler.finance/delegates) to assist in this matter.

Handling Emergencies.

  • What elements should be considered as emergencies? Im not sure we need a formalised list of situations that could be regard as emergencies. I like your general description of an emergency situation and believe that it is enough. From my point of view, a formalised list will prevent DAO form working efficiently with emergencies. What I mean is that FTX collapse and some other emergencies were not predictable at the very beginning. In this regard, a new emergency is still hardly predictable thus is unlikely to be included in the list before it happens.
  • Who can propose these emergency proposals?. I strongly believe that it should be a Council comprised of up to 10 people with the participation of EulerLabs team (as they works day by day with the protocol and know better), Distinguished delegates (if the proposal is approved), some other ideas?
  • as for the steps an emergency should follow I described some ideas in the
    [RFC] Governance Procedure for Extraordinary Situations, so I would better not repeating it here again.

PS. Thanks again for launching this discussion, hope I did bother everybody with too much text.

3

Hello, @0xBaer Thank you for starting this discussion. Iā€™d want to elaborate on a few of the points you made.

Regarding proposal types:

  1. According to my recollection, the general consensus on the last call was that the first point with the 4 proposals and 4 different types of templates is too complicated and introduces a potential problem with some mistakingly confusing the risk and the asset parametar category; however, there is a need to add another category that would clearly separate the proposals that are essential to the protocol from those that are not, thus introducing a general category.

  2. The second point has a clear structure, and as someone who has previously managed many communities, I can understand @Raslambek concerns; nonetheless, it is very clear that all proposals that neither improve the protocol nor request funding from the DAO fall into the general category.

  3. The third point creates confusion and separates general proposals from those that would clearly need to stand out because they involve requesting funding from the DAO.

I think option 2 is best, but I would remove the treasury management part.

Also, I would like to propose a restructuring of the Categories in the following way:

Each category would contain four subcategories:

  1. RFC
  2. Formal submission
  3. Live vote
  4. Voted proposal

Every parent category has subcategories that correspond to different stages of the proposalā€™s lifecycle. This structure was constructed on a test server and may be seen below.

discourse setup
discourse setup570Ɨ785 16.2 KB

1 Like
4

The formalisation of the governance process is very necessary element for clarity and DAO wide spreading.

What I wanna add about types of proposals, Iā€™m more in favor of 2 options but with few changes:
Short abbreviations confuse a little bit.
I would propose:

  1. Changing risk and assets parameter could be called like Risk-Management improvement proposal (rmIP).
  2. Grants funding: grant proposal (grP or grIP). grIP sounds more familiar.
  3. General proposals (treasury management, roadmap, etc): Euler Improvement proposal.

As @Raslambek already raised the question, why should we raise Snapshot voting time? Or the same question is why should we decrease?
We already have some variation of Fast Track. 7 days may definitely increase number of participants, 5 days can harm. Iā€™m more in favor of 7 days.

5

This is one hell of a post 0xBaer, thank you for it. Perhaps consider breaking these up into multiple posts in the future? Forum is bad UI to read 1) all of it and 2) respond to it. Either way good work.

I like Patā€™s proposal system.

I dislike voting twice on the same thing. I think it leads to voter apathy when voters are voting on non-binding votes. The demographic of voters voting on a forum is already so small. We are drafting a constitution here but amendments are only receiving 4 or 5 votes - itā€™s too few to claim legitimate representation.

I propose once the active / recognised delegate proposals are live they act as guardians of the ballot box. Once we reach some sort of consensus here Iā€™ll expand this theory more clearly.

Yeah Iā€™d agree with keeping 7 days. @nikita

While I am all in favour of knowing exactly what does and doesnā€™t constitute an emergency, there should be some sort of 5th category that is totally unforeseen. While the 4 categories provided are of good value, in DeFi things are so complicated that something completely out of the blue can blindside you. Maybe include a 5th emergency type (act of god)?

I agree on those who are able to declare the emergency.

I think perhaps the third option (24hr discord poll) should be open to anyone seeking to declare an emergency.

Generally speaking, Iā€™d say the emergency option requires an entirely different eIP. Thanks 0xBaer but honestly this is just too much stuff in one post. I really appreciate the work youā€™ve done here but engaging in each part meaningfully is complex - please simplify it a bit in the future!

6

I might be missing something, but why is it 7 days? Isnā€™t it 6 days voting time atm?

7

Thank you @Raslambek, @Carebbear,@nikita and @river0x for your comments,

This post clarifies the currently established customs in the DAO, which arenā€™t written anywhere. Depending on community feedback, we can split it into different RFCs or have a consolidated one which would give us clarity in the documentation.

From the Polls above, there is a soft consensus on three proposals, but we couldnā€™t yet decide what those three types will be. If there are no further comments, i will take the liberty to do some ideation and present my biased option in the upcoming RFC.

This post allows RFC authors to edit their proposals and rightfully do so. But the RFC should not be edited if itā€™s finalised and formally submitted as a Poll. This is to avoid a situation where someone votes ā€˜YESā€™ on day 1 of formalisation to fund a project being surprised with a new set of changes to which he might not agree.

That being said the DAO isnā€™t getting that much engagement on polls, people would loose track if here are more rules than necessory. Simplifying this RFC/eIP process is a must IMO.

you are not missing anything, there isnā€™t any documentation which i can find about the length of the snapshot voting period. Most of the proposals are 6 days. The standard length across many DAOs is 7 days, a standardisation of the voting period helps us, meta-governance groups, a lot as we also follow a democratic process before voting on proposals.
opening to discussions

1 Like
8