Welcome to the Euler Governance Forum


This forum is dedicated to discussions on Euler governance. Relevant topics include:

  • Governance proposals
  • Proposal discussions
  • Site feedback
  • Risk assessments

This is not the place for:

  • EUL price discussion
  • Generic Euler discussion
  • Euler support requests
  • Off-topic conversations

If you need technical help, or want a place for more general discussion, visit the official Euler Discord .

Common Questions


Below, we have provided a template on how to structure your Euler proposals in order to offer a more comprehensive & efficient deliberation process.

Governance Process


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 with [RFC] as a prefix in the title of the topic and the title of the proposal, and publishes it on the forum for open community discussion and feedback. The proposal should 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

The previous RFC proposal must be posted again as a comment in the same proposal forum thread, taking into account community feedback. The proposal’s title must be edited to add a numerical sequence and change the “[RFC]” prefix to “[eIP-xx]”, [Grant Proposal-xx], or [General Proposal-xx] depending on the type of the proposal. The proposal category should also be adjusted from “RFC (Request For Comment)” to “Formal Submission”.

Example: (eIP 39 Promote LUSD to Cross Tier - #12 by TokenBrice)

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

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.

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.

Proposal lifecycle

Proposal Categories

The standardized format for the three categories of proposals (eIP, Grants, and General) will be automatically filled in upon creation, streamlining the process. (Please follow the structure)

  • 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 Proposal – Other types of proposals, including marketing and events. General Proposal Template

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 more than 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.

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.

Stay updated by subscribing to the community newsletter and follow the Twitter Page!


A small step for Euler, A big step for defi and web3!