Governance Process
This document is a suggested process for developing and advancing ENS Governance Proposals. It is a living document intended to be owned, modified and enforced by the ENS community.
discuss.ens.domains is a Discourse forum for governance-related discussion. Community members must register for an account before sharing or liking posts. Registering for the forum allows community members to post in the general forum; for access to the working groups, fill out the participant request form.
There are four workstream categories: Meta-Governance, Community, ENS Ecosystem, and Public Goods. Each category has subcategories for each of the steps of the governance process described below.
Snapshot is a simple voting interface that allows users to signal sentiment off-chain. Votes on snapshot are weighted by the number of ENS delegated to the address used to vote.
Tally is a governance portal that allows token holders to delegate their votes, and allows delegates to create and vote on binding proposals.
There are also other governance interfaces that users can use to cast their votes:
*Note: this is not a complete list, and should be updated by the community frequently.
You are probably here because you want the DAO to do something. The primary mechanism by which the DAO gets things done is via "Requests for Proposal" (RFPs). An RFP is a request from the DAO for contributors to offer to do work on its behalf, and receive compensation in return.
Anyone who identifies a need can write an RFP, and if the RFP is passed, anyone can write a proposal in response and be awarded the work. Even if you believe you can do the work yourself, you will still need to pass an RFP in order to be awarded the work (and corresponding compensation) by the DAO.
RFPs vary in detail and complexity. An RFP for improving the DAO's documentation may only be a paragraph or two long, and proposals for it will be equally short. At the other extreme, an RFP for managing the DAO's funds may be lengthy, and a successful proposal could be multiple pages justifying the proposer's ability to take on the job.
RFPs all follow this process:
-
Write a draft RFP (template here) and post it as a discussion thread in the appropriate working group on the DAO forum. At a minimum, RFPs must:
a. Explain the need for the RFP and describe the work to be done - the scope of work and deliverables.
b. Specify the requirements for a winning bid - criteria for selection.
c. Provide a timeline for submissions and completion of the work.
d. Nominate a party who will select a winning bid and approve & disburse compensation (the RFP manager). Normally this will be the working group who adopts the RFP.
e. Specify a maximum budget for the RFP.
-
Incorporate feedback from DAO participants into your draft. When you believe it is ready, tag the stewards of the working group and request they consider adopting it.
-
If the stewards agree to adopt your RFP, they will decide if it can be paid out of WG funds, or if it needs a DAO wide vote.
a. If the RFP can be paid out of WG funds, they will set a submission period and post it as an active RFP.
b. Otherwise, the stewards will create an executable proposal (or, they may ask you to do this) asking the DAO as a whole to approve the RFP. The proposal should contain the RFP. The executable component should specify approvals from the DAO funds to the RFP manager in the amount of the maximum budget for the proposal.
-
Once the RFP is approved - either by the WG or by a DAO-wide vote - the submission period begins. You or a WG steward should create a post on the DAO forum for proposals, and anyone can submit a proposal to this thread.
-
Once the submission period is concluded, the RFP manager selects a winning bid. Normally the manager will be the stewards of the working group who has adopted your RFP.
-
The author of the winning proposal commences the work. As they meet milestones specified in the RFP and their proposal, they can request compensation from the RFP manager, who disburses it from the allocated funds.
There are three main types of governance proposals you can make:
- Executable Proposal: This is a proposal for a series of smart contract operations to be executed by accounts the DAO controls. These can include transfers of tokens as well as arbitrary smart contract calls. Examples of this include allocating funding to a workstream multisig wallet, or upgrading an ENS core contract. Executable proposals have a quorum requirement of 1% and require a minimum approval of 50% to pass.
- Social Proposal: This is a proposal that asks for the agreement of the DAO on something that cannot be enforced onchain. Examples of this include a proposal to change the royalty percentage for the ENS secondary market on OpenSea, or a petition to the root keyholders. Social proposals have a quorum requirement of 1% and require a minimum approval of 50% to pass.
- Constitutional Amendment: This is a social proposal that asks the DAO to amend the constitution. Your draft proposal should include a diff showing the exact changes you propose to make to the constitution. Rules for amending the constitution are set in the constitution itself, and currently require a quorum of 1% and a minimum approval of two thirds to pass.
The purpose of the Temperature Check is to determine if there is sufficient will to make changes to the status quo.
To create a Temperature Check, ask a general, non-biased question to the community on discuss.ens.domains about a potential change (example: “Should ENS decrease registration costs for 3-letter domains?”). Forum posts should be in the "DAO-wide -> Temperature Check" category.
Temperature checks are informal and optional; it's up to you to use the feedback to decide if you want to proceed further with your proposal.
The purpose of the Draft Proposal is to establish formal discussion around a potential proposal.
To create a Draft Proposal, create a new governance proposal in the governance-docs repository on GitHub. Start by copying the template for an executable proposal, social proposal, or constitutional amendment, as appropriate. Once you have written your proposal, create a Draft Pull Request for it. Start a new post in the DAO-wide -> Draft Proposals" category with a link to the PR for discussion.
Reach out to your network to build support for the proposal. Discuss the proposal and solicit delegates to provide feedback on it. Be willing to respond to questions on the Draft Proposal topic and in comments on the pull request. Share your viewpoint, although try to remain as impartial as possible.
If your proposal is an executable proposal, you will need to specify the actions your proposal will take while it is in draft stage. You may wish to wait until the proposal is stable before doing this. The executable proposal template explains how to do this.
If your proposal is a constitutional amendment, you will need to produce a diff showing the exact changes you are proposing to make. The easiest way to do this is to go to the constitution, click "Edit on GitHub", then click the pencil icon to edit the document in a fork. You can then create a pull request via the GitHub UI and include this in your proposal. You should do this in a separate branch to your draft proposal; while the proposal will be merged as soon as it goes to a vote, the amendment will only be merged if the proposal passes.
Once you are confident the proposal is in a stable state, you can proceed to phase 3.
Use GitHub to flag your PR as Ready for Review. A contributor will:
- Merge your PR if it meets the requirements.
- Assign your proposal a proposal number in the form EP###.
- Schedule the proposal for a snapshot vote.
If your proposal is a Social Proposal or a Constitutional Amendment, that's it! If the snapshot vote passes, the proposal is passed and you are done.
If your proposal is an Executable Proposal, you will now need to submit it to the governor contract for voting onchain.
To enact an Executable Proposal:
- Ensure at least 100k ENS is delegated to your address in order to submit a proposal, or find a delegate who has enough delegated ENS to meet the proposal threshold to propose on your behalf.
- Call the propose() function of the ENS governor (at governor.ensdao.eth) to deploy your proposal.
Once the propose() function has been called, a seven day voting period is started. Ongoing discussion can take place on your proposal post. If the proposal passes successfully, a two day timelock will follow before the proposed code is executed.
ENS: An ERC-20 token that designates the weight of a user’s voting rights. The more ENS a user has in their wallet, the more weight their delegation or vote on a proposal holds.
Delegation: ENS holders cannot vote or create proposals until they delegate their voting rights to an address. Delegation can be given to one address at a time, including the holder’s own address. Note that delegation does not lock tokens; it simply adds votes to the chosen delegation address.
Executable Proposal: An executable proposal is a type of proposal that is executed by the governance contract through timelock. It can replace the governance contract, transfer tokens from the community treasury, or perform an almost infinite range of other on-chain actions. In order to create a proposal, an address must have at least 0.1% (100k ENS) of all ENS delegated to their address. Proposals are stored in the “proposals” mapping of the Governor smart contract. All proposals are subject to a 7-day voting period.
Quorum: In order for a vote to pass, a certain percentage of ENS tokens must vote in the affirmative. The current quorum requirements are:
- Executable Proposals: 1%
- Social Proposals: 1%
- Constitutional Amendments: 1%
The purpose of this quorum is to ensure that the only measures that pass have adequate voter participation.
Voting on Executable Proposals: Users can vote for or against single proposals once they have voting rights delegated to their address. Votes can be cast while a proposal is in the “Active” state. Votes can be submitted immediately using “castVote” or submitted later with “castVoteBySig” (For more info on castVoteBySig and offline signatures, see EIP-712). If the majority of votes (and a 1% quorum of ENS) vote for a proposal, the proposal may be queued in the Timelock.
Voting Period: Proposals on Snapshot have a 5 day voting period. Once an executable proposal has been put forward, ENS community members will have a seven day period (the Voting Period) to cast their votes.
Timelock: All governance actions are delayed for a minimum of 2 days by the timelock contract before they can be executed.
