Euler Governance Process v0
Authors: @Matt_StableLab , @Bobbay_StableLab
“Euler Governance Flow” is an all-in-one document for contributing to Euler DAO. This document will continuously be updated by Euler DAO contributors.
This document aims to provide an overview of the different roles and responsibilities, flows, and pathways for various stakeholders to participate in Euler DAO.
Contents
-
Governance Roles
- Active Delegates
- Delegates
- Delegators
- Contributors
-
Rules and Values
- Code of Conduct
- Enforcement
-
Governance Processes
-
Proposals
- Types of Proposals
- Proposal Timelines
-
Voting
- Proposal Voting
- Quorum
-
Working Groups
-
Funding
-
-
Changes to Governance
Governance Roles
There are four key roles in Euler DAO:
- Active Delegates
- Delegates
- Delegators
- Contributors
Active Delegates
Active delegates are those delegates who satisfy the following criteria:
- Greater than 600 EUL voting power
- A minimum voting participation rate of 60% in any given month
- Provide a rationale for their votes with their vote
Active delegates will be listed first on the Euler delegate dashboard to showcase active delegates. Active delegates have no other responsibilities alongside this role. Active delegates are currently not compensated for their contributions.
The “Active delegate” section of the delegate dashboard is a work in progress.
Delegates
Delegates are non-active voting members who have received voting power through the community or self-delegation. They have not met the requirements to become an active delegate. Similarly to active delegates, they are also not compensated for their contributions.
Anyone can become a delegate by:
- Creating an account on the Euler forum.
- Completing the following application.
Delegators
Delegators are community members who hold EUL but have entrusted their voting power to another person. The person they delegated their voting power to is considered a delegate and may also be an active delegate as per the thresholds above.
Contributors
Contributors are community members who participate in and dedicate their time to Euler DAO.
Rules and Values
Code of Conduct
No documented code of conduct for Euler governance as of yet.
Enforcement
Proposals that do not adhere to the proper format or timeline may be removed from Snapshot until they are amended or the appropriate amount of time has elapsed.
Governance Processes
The processes described in this section are an overview of the official ways to participate in EulerDAO, documenting the various paths for the lifecycle of a EUL holder, contributor, or curious individual.
Most governance discussions occur on the official Euler Forum and in the Euler Discord.
Proposals
There are three types of proposals, and two different timelines proposals can follow.
Types of Proposals
Euler Improvement Proposal (eIP)
Changes in risk parameters relating to an asset, e.g. borrow/collateral factors, asset tier upgrade/downgrade, or affecting the Euler protocol.
The template eIP proposals should follow can be seen here.
Grant Proposals
A request for funding from the DAO for an improvement task.
The template grant proposals should follow can be seen here.
General Proposals
Other types of proposals, including marketing and events.
The general template proposals should follow can be seen here.
Proposal Timelines
Normal Proposal Timeline
Ideation:
The first step of creating a proposal is to discuss the topic informally in discord or private chats. The best place for proposal ideation is the #Discussion channel under the governance category on Discord.
Request For Comment (RFC):
After informal discussion, the proposer should publish a formal draft of the proposal on the forum under the category for the appropriate proposal type and [RFC] Request For Comment category.
The proposal title and topic title should include the prefix [RFC] and should follow the template corresponding to the proposal type. The proposer also should specify the start and end date of the proposal using the calendar option on discourse.
Image: Example of an eIP in RFC stage with correct title, categories selected, and date range.
The default duration for RFCs is 6 days. Still, if the proposer feels that they did not receive enough comments or wants to extend the discussion, they may add a 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 to serve as a community temperature check.
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:
-
gain >8 unique voters
-
have more than 51% of total voters voting in favor
Image: Example of Temperature check poll.
Once the temperature check has passed, it can proceed to the Formal Submission stage. (Please be mindful that any attempts to game the temperature check will result in the immediate delisting of the proposal from the forum.)
If there are any major proposal changes, another temperature check should be initiated.
Formal submission Stage:
The RFC proposal will be re-published as a new comment under the same forum thread with changes that reflect community feedback. The propooser will also change the proposal’s category to “Formal Submission”
The proposer will change the topic title and the new comment’s proposal title to include
- the prefix corresponding to the proposal type (eIP/grants/general)
- a sequential number, e.g. change the title from “[RFC]: Promote LUSD to Cross Tier” to “eIP 39: Promote LUSD to Cross Tier”
- Proposers should check the latest proposals to ensure they are attaching the correct sequential number to the proposal
Image: Example of an eIP in formal submission stage with the correct topic title, original proposal title with RFC prefix, new comment proposal title with eIP prefix, correct sequential eIP number, and correct categories selected.
This stage will last 2 days to allow a final review of the proposal. 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.
Off-Chain Voting on Snapshot
After the formal submission period ends, the proposal can be moved to off-chain voting on Snapshot.
To submit a proposal on Snapshot, the proposer must have a minimum of 500 EUL delegated to them, including self-delegation.
Those who do not have the required delegation can reach out to larger delegates on discord and ask them to post the proposal on their behalf.
The proposal forum thread should then be changed to include
- The category changed from “Formal Submission” to “Live Vote”.
- A forum comment by the proposer to announce the Snapshot vote going live with a link to the Snapshot vote attached.
Image: Example of an eIP in live vote stage with the correct categories selected and new comment announcing the live vote on snapshot.
The Snapshot vote will last for 6 days, and the vote result will determine whether the proposal will be executed or not.
Post Vote
Once voting ends on snapshot, the forum proposal thread should be changed to:
- The proposal subcategory should be changed from “Formal Submission” to “Voted Proposal”.
- A forum comment should be made by the proposer under the thread to announce the result of the Snapshot vote and whether further actions will be made.
Successful Proposals:
Will be implemented by relevant Euler Labs teams. A thread will be created in the main eIP category to provide updates on the status of proposals that have passed and those waiting to be implemented.
Failed Proposals:
There will be no further actions required for failed proposals.
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.
Fast Track Proposal Timeline
Fast-track proposals are urgent proposals that require a shorter lifecycle.
A fast-track proposal:
- Lasts 24 hours
- Does not go through the RFC stage
- Will be published on the forum as a live proposal and Snapshot for voting simultaneously.
- Voting results will be concluded after 24 hours (even though the snapshot proposal will stay open for 6 days)
- Can only be proposed by Euler Labs contributors until a version of the Senior Delegates program is implemented.
Image: Example of a fast-track eIP with correct title and categories selected.
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.
Voting
Proposal Voting
To vote EUL holders must delegate their $EUL to either themselves or a delegate. A guide to how to delegate your EUL can be found here.
Voters can see which proposals are live and vote on them on Snapshot.
Voting power is equal to the amount of EUL a voter is delegated.
Currently, Euler is in phase 1 of their governance launch. In this phase, votes will only occur on Snapshot. In later phases of Euler governance, passed Snapshot proposals will then move to on-chain voting using Tally. These on-chain votes will allow some successful proposals to be executed automatically (phase 2). Eventually, all changes to the protocol will be out of the hand of the Euler Labs team, and changes will be automatically executed on passed on-chain votes via Tally (phase 3).
Please refer to the official documentation to learn more about voting processes and the phases of Euler governance.
Quorum
The Euler quorum on Snapshot is 10,000 EUL votes. Each Proposal has to reach the minimum quorum, even if it has a majority, for it to be considered a passed proposal.
Changes to the quorum requirements must be amended by the community through an eIP, such as what happened when the quorum was increased through eIP 19.
Working Groups
Currently, there are no working groups in Euler.
Funding
Euler grants program encourages developers to build on top of Euler protocol and help integrate it into the wider DeFi ecosystem. A portion of the Euler Treasury is allocated to the grants program to fund a culture of community-driven development, where individuals can make improvements to the Euler Protocol.
Grant proposals should be posted on the forum using the grants template under the grants category. Here it will follow the normal proposal timeline mentioned above. If the grant proposal makes it through the entire proposal cycle and receives the necessary votes on snapshot, it will be funded by the Euler treasury.
Changes to Governance
Any changes to the Euler Governance Process must be ratified by the community through a general proposal.