Seeking Feedback on Bylaws GAP Analysis: A Call to Stewards, Delegates, and Contributors

As part of the RFP by the Meta-Governance working group, Lemma has conducted a GAP analysis as a starting point before commencing with the creation of the first draft of the Bylaws.

Objective:

  1. Identify any gaps, inconsistencies, or outdated provisions that may hinder effective governance.
  2. Enhance clarity within the final bylaws to facilitate better understanding.
  3. Ensure that the bylaws support the dynamic and growing nature of the ENS community.
  4. Ensuring that the community has a voice in the creation of the bylaws and that the final bylaws reflect the values of the ENS community.

How You Can Contribute:

  • Review the Analysis:
    ENS ByLaws GAP Analysis

  • Share Your Insights:
    Provide feedback on any areas where you believe improvements could be made, or if you identify any additional potential gaps.

  • Suggest Revisions:
    If you have specific recommendations or proposed revisions, please outline them clearly and provide context for your suggestions.

We invite all stewards, delegates, and contributors to actively participate in this collaborative effort.

Your input and insights are crucial to ensuring that the governance framework aligns with the evolving needs of the ENS community.

2 Likes

Hi there, Lemma representative!

Re: Governance Process > Passing a Proposal > Phase 2: Draft Proposal — GitHub

  1. Have you considered rethinking the imperative of publishing a project on GitHub? Some proposals do not have any specific execution code due to their non-technical nature. Accordingly, this may mislead contributors into thinking that they cannot submit their project to the DAO if it does not contain code.

30 days would give the proposer sufficient time to write the proposal draft including feedback from the temp check.

How do you justify this number of days? Of course, you can prepare a proposal within 30 days. But it’s far from a fact that you will have time to collect feedback during this time. The ENS Forum and working group calls are not known for high activity, and some delegates do not attend them at all.

Cumulative vote collection for Snapshot Proposal

ENS has a mechanism whereby Steward candidates do not need to have 10,000 votes or one delegate with 10,000 votes to nominate themselves. They can collect them cumulatively - Snapshot. This is a mechanism that is not legally fixed anywhere, but it is certainly useful.

Recently, this mechanism has been used to certify to DAO that candidate service providers have the endorsement to be included on the list. It turns out that any proposer can use this to initiate a vote.

Are you going to put this in the bylaws and make it legal?

1 Like

Thank you for preparing this GAP Analysis for DAO-wide review. I am sharing some excerpts here, which I think are of particular interest to the DAO:

Points of Concern — Excerpts from the Gap Analysis
  • $ENS Governance Token Airdrop: Add additional wording explaining that the airdrops were carried out in the past and are no longer relevant today. New members will know straight away that this is no longer valid.
  • Context for Governance: Instead of saying “off-chain voting”, mention the types of proposals that are voted on here.
  • Onboarding & Participation: “To request access…” Link to a resource that explains in detail what happens after the form is submitted and who evaluates the form.
  • Venues: “Community members must register for an account before sharing or liking posts.” Define different personas in the beginning. This way, no one would get confused on what a community member is, what a governance participant is, etc. This could also include an access-level list for the different personas on different platforms.
  • Getting Work Done: Define what an RFP is. The process is unclear. Add clarification on the process and steps with detailed for Proposal and RFP will be added in the updated Bylaws. Suggestion would be a level/type system that would allow grouping different types of proposals and share best practices / criteria accordingly.
  • The RFP Process: What processes are in place to comply with KYC / AML regulations? (if and when required) How are milestones submitted and tracked and what is the process for milestone assessment before payments are made? KYC requirements before any payments are made will be added in the updated ByLaws as well as a threshold under which KYC is not required. The request for additional funding process will also be defined in more detail and what is required.
  • Passing a Proposal: What prevents someone from submitting an Executable Proposal to the governor contract even if it hasn’t passed the SnapShot vote? What processes are in place to avoid this? Are there processes in place that an authorized person could submit a veto and block the passed proposal from being executed? Main concern here is if KYC and AML checks are not passed or in the rare circumstances where it can damage reputation or is an illegal activity.
  • ENS DAO Constitution: Indicate the type of costs incurred by the foundation each year. In addition, from a transparency point of view, it would be good to regularly draw up a budget estimate and submit a detailed expenditure report so that the community can understand the expenditure. A transparency report can be presented to the DAO on an annual, bi- annual, or quarterly basis.
  • Dissolution of Working Groups: Who oversees freezing the assets? Add who the responsible party would be for returning the funds.
  • Conflicts of interest in election process: Create a resolution process that indicates how a conflict is declared, what is expected when it is declared, whether elected stewards can be part of the decsion making process, whether there are any term limits or re-election periods, etc.
  • Election of Directors: Incorporate the election of directors in the ByLaws. Outline the steps for the election or removal of a director.
  • Veto Right: Introduce a possibility to raise vetoes. At ENS, vetoes could be raised by the foundation.
  • Code of conduct: for council/community members that can be used for non-compliance.
  • Process for alteration of Bylaws, dispute resolution, arbitration, election of a supervisor in the Bylaws.
  1. Defining DAO Roles Beyond ‘Community Members’: To alleviate confusion, I agree that it would be helpful to define distinct personas or actors, rather than simply labeling all participants as ‘Community Members’. This could include creating an access-level list for these personas across various platforms.
  2. Clarification and Structuring of the RFP Process: The RFP process could be better outlined. Currently, I find it difficult to follow and it leaves too much room for interpretation. Additionally, there are no KYC/AML requirements, nor are there best practices established for submitting and tracking milestones. I believe that adding KYC/AML requirements before making payments, along with a threshold below which they are not required, would be beneficial.
  3. Posting and Voting Procedures for ENS Proposals: Recently, a rogue proposal was posted in the ENS snapshot space. According to the Governance Process, “if your proposal is an Executable Proposal, you will now need to submit it to the governor contract for voting onchain.” — Lemma raised an important point by asking what prevents someone from submitting an Executable Proposal to the governor contract even if it hasn’t passed the Snapshot vote. I would advise investigating this issue as a means of forming a preventive measure against governance attacks.
  4. Enhanced Budget Transparency for DAO Expenditures: Increase the transparency of costs incurred by the Foundation by regularly drawing up a budget estimate and submitting a detailed expenditure report. This will enable DAO participants to better understand the expenditures. A transparency report could be presented to the DAO on an annual, bi-annual, or quarterly basis. This report should be created by the role that is responsible for administering the DAO’s governance documentation and processes, and for keeping these materials up to date (to be formed per criteria outlined in the RFP).
  5. Procedures for Dissolution and Freezing of DAO Working Groups: Freezing of funds should be administered by the DAO secretary (imho).
  6. Formalizing Conflict of Interest Protocols in DAO Elections: Thus far, conflicts of interest in election processes have been handled on a ‘de facto’ basis. The DAO has done a stellar job of navigating these ambiguous situations, but to ensure continued effectiveness, it is pertinent that we develop clear documentation to establish a legitimate protocol as a guide for handling future conflicts of interest.
  7. Development of a Code of Conduct for DAO Governance: Code of conduct should be developed that can be used for non-compliance, as well as a process for alteration of Bylaws, dispute resolution, arbitration, and the election of a supervisor in the Bylaws.
  8. Review and Discussion of Veto Powers in DAO Proposals: Finally, the veto right is interesting in theory. Using Optimism as a reference, the Citizens’ House can raise vetoes on certain passed proposals. At ENS, vetoes could be raised by the Foundation. I believe that this is something that should be discussed at greater length by relevant parties.

Please note: these are my professional opinions and do not reflect the overall opinion of the Meta-Governance Working Group.

3 Likes

I’d like to highlight this point a bit. Certainly as @AvsA was saying this is all one big learning exercise and there is no precedent for any of this, however some experience can still be applied.

As far as “money” is concerned the only quality deliverable I’ve seen so far is this. The rest of the documents to my professional eye could use quite a bit of work.

I don’t have all the answers right now, but I think it’s worth highlighting this subject. The point is that the intent for transparency is present, but quality of deliverables prepared don’t really provide much transparency.

So to really embed “accounting” into Bylaws it makes sense to have a proper reporting in the first place, otherwise it will be yet another deliverable which doesn’t make too much sense.

DAO could consider hiring me to oversee bringing all this information “up to code” or some other external party. As I was putting it in my Steward application, there are many aspects of DAO which can be run same way as they are within public corporations - transparency and reporting is one of them.

2 Likes

There is no snapshot vote required before an onchain vote. This was briefly the case in term 1, but we abandoned it when it proved unwieldy and an unwarranted burden on delegates.

I’ve proposed before, and personally support, a new governor module that requires a stake be posted instead of a voting power threshold; the stake would be refunded if the vote passes, and transferred to the DAO wallet or burned if it fails.f

3 Likes

Ah, okay, thank you for providing that insight. This answers @Lemma’s questions regarding Phase 3: Active Proposal — Snapshot / Governance Portal.

This is very interesting! According to @karpatkey’s Dune Dashboard, only 11 delegates are currently able to submit an onchain proposal. Introducing a new governance module that requires a stake, rather than a voting power threshold, could be another way to further democratize the governance process.

This approach also offers protection against governance attacks, as spam proposals would most likely fail. In such cases, the submitter would pay a penalty by having their staked $ENS either burned or returned to the DAO’s wallet.

Interesting idea. I wonder what would be an ideal stake: over a 100 accounts have over 10k ENS and over 900 accounts have over 1k ENS, so a lot of people would become eligible – but it would also represent a large monetary value enough that nobody would want to risk it by putting a proposal without going through the right channels. We would also need to have a robust alert system of new proposals.

1 Like

isn’t it just going to lead a bunch of “rubber stamped” votes?

so if there is vote which is highly contentious, then people will be reluctant to post those

Thank you for your questions!

We believe that GitHub is a good tool for publishing draft proposals as it offers extensive formatting options, the ability to add code, as well as the ability to collaborate on the proposal and review it easily. However, your concerns are very valid. GitHub is too technical for many people, which can be a barrier for them to submit a proposal.

The DAO has to vote and decide whether to post draft proposals directly to the forum instead of going through GitHub. For reference, Optimism already does this.

We would, however, still recommend that proposals to changes to the Constitution remain published on GitHub as it is a good way to track the exact changes proposed.

We hope to change the low level of activity and responsibility with the bylaws. They will include responsibilities for those involved, including delegates, followed by consequences if the responsibilities are not met.

ENS has a mechanism whereby Steward candidates do not need to have 10,000 votes or one delegate with 10,000 votes to nominate themselves. They can collect them cumulatively - Snapshot . This is a mechanism that is not legally fixed anywhere, but it is certainly useful.
Recently, this mechanism has been used to certify to DAO that candidate service providers have the endorsement to be included on the list. It turns out that any proposer can use this to initiate a vote.
Are you going to put this in the bylaws and make it legal?

Thank you for pointing out this mechanism. When we did the GAP analysis, this was not part of the ENS governance documentation. We would need to assess this mechanism first and include it in the GAP analysis. If you have relevant links that explain this mechanism in more detail, please feel free to provide them to us.

3 Likes

Hi @estmcmxci, thank you very much for the points raised.

A part of the bylaws can be used to create a high-level definition of roles and outline what those roles are. In terms of access-level lists, this can be manual or there are various tools that can be used for this. This is definitely worth exploring further separate from the bylaws. If you have a suggestion on the naming of roles - please let us know.

Yes, this is crucial. The RFP process will have similarities to a proposal itself, Including KYC, and milestone tracking. The bylaws would need to include the outline of how the RFP process works, however the exact mechanics of milestone tracking etc. would be separate from the bylaws.

We suggest that there is perhaps a formal post on this exact question and we can include the agreed upon decision in the bylaws. Open to have a discussion on this.

The bylaws should include the frequency as well as a general outline of what is expected in the transparency reports. The format, additional materials and information fall outside the scope of the bylaws and we suggest should rather be included and outlined in a separate document.

Thanks for the above. This makes sense.

Agreed, we hope for feedback after our release of the draft on this note.

Agreed

Agreed that this should be a broader discussion. Similar to Optimism, other DAOs also have councils for emergency actions as well. We can include a section for this in the bylaws, but leave it out until the DAO has had a broader discussion after which this can be added to the bylaws (after approval by DAO vote)

1 Like

Hi @SpikeWatanabe.eth

Thank you for your feedback.

We would like to include in the bylaws the need for transparency reporting and broadly what this means. I.e. frequency of reporting and a general outline of what documents are expected for this report.

We would recommend that he bylaws do not should specify the format, type of information etc.

Rather we suggest that reference can be made to a policy outlining what is required. It would be easier to change this policy as the needs of the DAO changes than to change the bylaws.

We agree with you that transparency reporting is important for the DAO as whole.

The ENS documentation states the following:

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.

That is, in fact, such a mechanism is not legal at the moment. However, if we invent not from the text of the documentation, but from the spirit of the management system in ENS, then we can assume that the fact that 5 delegates with 20k votes are ready to support you and not 1 with 100k does not make your proposal less valuable.

As I mentioned earlier, such a mechanism has already been used in the selection of stewards and service providers. If not for this mechanism, Namespace would not have been able to nominate them because no delegate with more than 10k votes nominated them - Snapshot. This mechanism allowed them to become candidates and present a detailed proposal that the delegates liked, allowing them to eventually become ENS service providers. Therefore, I consider it pivotal to separate this feature into a legal category, so that each proposer knows that they can collect votes to initiate voting cumulatively.

The stumbling block here is that even if such an actor collected a total of 10/100k in this way, they still will not be able to submit a proposal to the DAO, since Snapshot/Tally will not allow them to do this without the required number of delegated votes in the proposer’s wallet. You can achieve Endorsement cumulatively, but not submit the proposal itself.

The obvious solution here would be to choose the person who will submit the proposal if they see that there is a sufficient (10k for social, 100k for executive) number of votes on the nomination proposal. However, in practice this is unlikely to work well. For example, it is impossible to appoint a steward responsible for this, since they do not always have votes, and those who do can lose at any time based on the specifics of the delegation.

Perhaps there is an option to create a multisig with delegated 10/100k votes, the signatures from which will be transferred to the MG stewards from convocation to convocation, and which will not participate in voting, but only initiate them.

@Meta-Gov_Stewards What do you think?

Sure, I will keep this in mind and share any suggestions should I have any.

Understandable.

As mentioned above by nick.eth: “There is no snapshot vote required before an onchain vote.”

Does that satisfy your initial ask?

Yes, please. That’s fine to include the additional materials in a separate document, but let’s do our best to create a robust framework that will serve as a foundation for those documents.

You’ll find plenty of feedback you can incorporate into the first draft re: Conflicts of Interest in the Term 5 Funding Request — Meta-Governance.

Re: Code of Conduct, you are in luck because I’ve prepared one already!

Sounds good.

Thank you for your feedback. The Meta-Governance Working Group will consider it. I will recuse myself from opining on this matter, as my voice does not represent the entire body.

2 Likes

Hi @Lemma — we recently held a discussion re: DAO Funding Request, covering a wide range of governance-related issues such as compensation, budgetary and funding procedures, managing conflicts of interests, and more. I believe this discussion provided a lot of feedback that could be valuable in drafting the bylaws.

I’ve drafted what I consider a summary of the key issues that emerged from that discussion. These can be incorporated into the bylaws discussion. You can view it here: ENS DAO Meta-Governance: Key Bylaws and Discussions - HackMD

1 Like

Hi, thank you very much. We will incorporate this into the draft bylaws.

We could potentially institute longer proposal times or a longer lock up / buffer should anything malicious sneak through

I don’t really understand the rationale on locking up a reward that is retroactively disbursed to a member in which that member is already waiting to see benefit; post-action of their contribution.


I think we should a least be seeing some sort of framework by now …
In lieu of the further back and forth confusion of prioritizing areas off proposal conversation regarding:

Meta-Governance Budget Funding Request
Governance Distribution Program 2.0
Steward Vesting Proposal Temp Check Discussion

I believe we should take a step back for a second. We all need to be under same umbrella here. That means we need to ensure that out umbrella terms are used correctly because quite frankly–we are all from different cultures. Because of that, we are absolutely going to continue to run into to prolonged discussion and fumble over the semantic context of our financial understanding in this organization.

It seems like we are making conversation and then incorporating responses that state a perspective, method or reference to aspects of this organizations financial foundation without wholly and contextually placing technical reference to the root of such.

So I say we define the foundations of ENS’ Finance in clear terms to set precedence on future discussions in hopes that; as members, there shouldn’t be any contextual misunderstandings. This is especially important when monetary distributions, disbursements, payments or any other such transfer of funds from one entity to another.

Essentially, we are all here to assist each other in saving time for each other as well as millions of ENS users, right? We really, don’t have time to wait months for our standardized processes for reference because I can see we are all kinda looking around for a directive or formal reference for guidance on the right way

  • ENS DAO Compensation and Guidelines
    • 1.1. Compensation
      • 1.1.1. Definition and Criteria
      • 1.1.2. Appointment and Budget Allocation
      • 1.1.3. Payment Schedule and Currency
      • 1.1.4. Source of Funds
    • 1.2. Rewards in the ENS Ecosystem
      • 1.2.1. Types of Rewards
        • 1.2.1.1. Bug Bounties
        • 1.2.1.2. Content Creation
        • 1.2.1.3. Community Engagement
        • 1.2.1.4. Development Contributions
        • 1.2.1.5. Translation Contributions
        • 1.2.1.6. Design Contributions
      • 1.2.2. Reward Metrics and Evaluation
      • 1.2.3. Reward Distribution
    • 1.3. Compensation for Services Rendered
      • 1.3.1. Compensation Structure
      • 1.3.2. Approval and Governance
    • 1.4. Payment for Completed Tasks
      • 1.4.1. One-Time Disbursements
      • 1.4.2. Criteria for Payments
      • 1.4.3. Distinction from Disbursements
    • 1.5. Funding Stream for Projects
      • 1.5.1. Definition and Purpose
      • 1.5.2. Management and Governance
      • 1.5.3. Allocation and Evaluation
    • 1.6. Grants for ENS or Ethereum Ecosystem Initiatives
      • 1.6.1. Definition and Purpose
      • 1.6.2. Eligibility and Selection Criteria
    • 1.7. ENS Matching Process
      • 1.7.1. Incentives and Rewards
      • 1.7.2. Distribution Period and Voting Power
    • 1.8. Inertial Delegated Votes (IDVs)
      • 1.8.1. Definition and Features
      • 1.8.2. Benefits and Continuity
    • 1.9. Retroactive Payment Process
      • 1.9.1. Definition and Purpose
      • 1.9.2. Request and Justification
      • 1.9.3. Voting and Disbursement
    • 1.10. Reimbursement for Expenses
      • 1.10.1. Definition and Examples
      • 1.10.2. Reimbursement Process
      • 1.10.3. Reimbursement Policy
    • 1.11. Assigning Roles and Responsibilities
      • 1.11.1. Clear Roles and Responsibilities
      • 1.11.2. Job Titles and Descriptions
      • 1.11.3. Alignment with Goals
    • 1.12. General Provisions
      • 1.12.1. Transparency and Review
      • 1.12.2. Changes to By-Laws
    • 1.13. Distribution of Governance Tokens
      • 1.13.1. Purpose and Criteria
    • 1.14. Incentives for Delegation
      • 1.14.1. Offering Incentives
      • 1.14.2. Criteria for Active Delegates
    • 1.15. Governance Token Vesting
      • 1.15.1. Vesting Period
    • 1.16. Continuity of Policy
      • 1.16.1. Inertial Delegated Votes
    • 1.17. Implementation and Monitoring
      • 1.17.1. Action Plans
      • 1.17.2. Monitoring Progress
      • 1.17.3. Adjustments and Optimization
    • 1.18. Leadership and Governance
      • 1.18.1. Strong Leadership
      • 1.18.2. Effective Governance
      • 1.18.3. Ethical Standards
    • 1.19. Resource Management
      • 1.19.1. Efficient Use of Resources
      • 1.19.2. Sustainability
      • 1.19.3. Innovation and Adaptation
    • 1.20. Conclusion and Future Directions
      • 1.20.1. Reflecting on Achievements
      • 1.20.2. Learning from Experience
      • 1.20.3. Looking Ahead
  • $ENS Token
    • 2.1. Overview
    • 2.2. Tweet History
    • 2.3. Token Characteristics
    • 2.4. Holder Rights
    • 2.5. Token Supply
    • 2.6. Purchase and Contract Address
    • 2.7. ENS DAO Representation
    • 2.8. $ENS Distribution
      • 2.8.1. Allocation
      • 2.8.2. Airdrop
      • 2.8.3. Treasury Distribution
    • 2.9. $ENS Token Launch & Airdrop
      • 2.9.1. Eligibility Criteria
      • 2.9.2. Airdrop Window
      • 2.9.3. Claimed Tokens
      • 2.9.4. Remaining Tokens
    • 2.10. $ENS in the ENS DAO Treasury
      • 2.10.1. Initial Allocation
      • 2.10.2. Treasury Unlocks
      • 2.10.3. Current Balance
      • 2.10.4. Major Transfers
    • 2.11. Minting $ENS
  • ENS DAO Contracts
    • 3.1. Overview
    • 3.2. Important Contracts
    • 3.3. Token Lock Contract
    • 3.4. Delegation and Proposal Submission
    • 3.5. Governor Contract Functionality
    • 3.6. ENS DAO Treasury
      • 3.6.1. Treasury Holdings
      • 3.6.2. Treasury Assets
      • 3.6.3. Sourcing of Assets
  • ENS Foundation
    • 4.1. Overview
    • 4.2. Directors and Supervisor
    • 4.3. Foundation Expenses
    • 4.4. Relationship to the ENS DAO
    • 4.5. Documents
  • ENS DAO Constitution
    • 5.1. Overview
    • 5.2. Ratification and Voting
    • 5.3. Articles of the Constitution
      • 5.3.1. Article 1 – Name ownership
      • 5.3.2. Article 2 – Fees as an incentive
      • 5.3.3. Article 3 – Income usage
      • 5.3.4. Article 4 – Global namespace integration
      • 5.3.5. Article 5 – Amendments by majority vote
  • ENS Endowment
    • 6.1. Background and Goal
    • 6.2. Typical Endowment
    • 6.3. EP 2.2.4: RFP for Endowment Fund Manager
    • 6.4. EP 2.2.5: Selection of Fund Manager
    • 6.5. Endowment Initiation
    • 6.6. Relevant Forum Threads
  • Voting
    • 7.1. Overview
    • 7.2. Token-Weighted Voting
    • 7.3. Social and Executable Proposals
      • 7.3.1. Social Proposals
      • 7.3.2. Executable Proposals
    • 7.4. Steward Elections
    • 7.5. ENS Grants Voting
  • Delegating $ENS
    • 8.1. Overview
    • 8.2. Delegation Process
    • 8.3. Delegate Statements
    • 8.4. Importance of Delegation
    • 8.5. Criteria for a Good Delegate
  • Governance Environments
    • 9.1. Discussion Platforms
    • 9.2. Working Group Meetings
    • 9.3. Twitter Updates
    • 9.4. Voting Platforms
    • 9.5. Delegation Platforms
  • Proposals
    • 10.1. Overview
    • 10.2. Social and Executable Proposal Basics
    • 10.3. Social Proposals
    • 10.4. Executable Proposals
  • Funding Requests
    • 11.1. Overview
    • 11.2. Working Groups
    • 11.3. Executable Proposals

or perhaps something similar to:

which should yeiled content such as a standardization that is not only applicable to ENS DAO Specifically but also has the ability to be used by other organizations as their own standard as well.

for example:

1.2 Compensation

1.2.1 Definition

Compensation refers to the process of regularly scheduled disbursements made in USDC for services which have already been rendered and expected to be rendered within a specified time period pertinent to a specific position. Compensation is subject to DAO approval and is usually associated with ongoing roles or obligations within the DAO, such as those of stewards or service providers.

1.2.2 Structure

The compensation structure in DAOs is designed to promote fairness, transparency, and alignment with the organization’s goals. It is usually determined through a combination of factors such as the individual’s experience, skills, the scope of work, and the overall budget of the DAO. Compensation packages may include a base salary, performance-based incentives, and benefits such as health insurance or access to educational resources.

1.2.3 Approval Process

Compensation in DAOs is subject to approval by the DAO’s governance structure, ensuring transparency and accountability in the allocation of funds. By providing regular compensation, DAOs ensure that contributors are adequately rewarded for their efforts and that the organization can attract and retain talented individuals who are committed to its mission.

1.3 Payment

1.3.1 Definition

Payment refers to a one-time disbursement in United States Dollar-Collateralized (USDC) effectuated in consideration for a completed task. Payments are not subject to continuous disbursement unless expressly provided for in a contingency-based contractual arrangement and must meet clearly1.2.3 Reward Distribution
Rewards are typically expressed in USDC, a stablecoin pegged to the US dollar, to ensure transparency and fairness in their distribution. The amount of each reward is determined based on the pre-established standard metrics set by the ENS DAO.

1.2.3.1 Evaluation Criteria
The specific metrics used to evaluate and determine the value of contributions are established by the ENS DAO. These metrics may include factors such as the impact of the contribution on the ENS ecosystem, the level of effort and expertise required, and the overall quality and uniqueness of the work.

1.2.3.2 Funding Sources
Rewards are funded from various sources within the ENS ecosystem, such as the ENS treasury, community donations, or partnerships with external organizations. This funding ensures that there are sufficient resources available to recognize and incentivize valuable contributions from community members.

1.2.3.3 Governance and Transparency
To maintain transparency and accountability, the ENS DAO typically follows a structured and documented process for evaluating and awarding rewards. This process may involve community input, peer review, and final approval by the DAO’s governance body.

1.3 Compensation

1.3.1 Regular Disbursements
Compensation is the process of regularly scheduled disbursements made in USDC for services that have already been rendered and are expected to be rendered within a specified time period pertinent to a specific position. Compensation is subject to DAO approval and is usually associated with ongoing roles or obligations within the DAO, such as those of stewards or service providers.

1.3.2 Compensation Structure
The compensation structure in DAOs is designed to promote fairness, transparency, and alignment with the organization’s goals. It is usually determined through a combination of factors such as the individual’s experience, skills, the scope of work, and the overall budget of the DAO. Compensation packages may include a base salary, performance-based incentives, and benefits such as health insurance or access to educational resources.

1.3.3 Approval and Governance
Compensation in DAOs is subject to approval by the DAO’s governance structure, ensuring transparency and accountability in the allocation of funds. By providing regular compensation, DAOs ensure that contributors are adequately rewarded for their efforts and that the organization can attract and retain talented individuals who are committed to its mission.

1.4 Payment

1.4.1 One-Time Disbursements
Payment refers to a one-time disbursement in United States Dollar-Collateralized (USDC) effectuated in consideration for a completed task. Payments are not subject to continuous disbursement unless expressly provided for in a contingency-based contractual arrangement and must meet clearly defined requirements.
1.4.2 Criteria for Payments

A disbursement is classified as a payment if it meets specific criteria, such as occurring no more than three times in a calendar quarter or once per month on the same calendar day as the initial disbursement. This ensures that payments are not made too frequently and are consistent with the definition of a one-time payment.

1.4.3 Distinction from Disbursements
The distinction between payments and disbursements is important for ensuring that payments are made in a timely and consistent manner, preventing duplicate payments or overpayments, and accurately tracking and managing financial transactions.

1.5 Funding Streams

1.5.1 Definition and Purpose
A Funding Stream is a pool of funds allocated in USDC for projects endorsed by the DAO. These funds are then distributed among candidates that provide services to the DAO or contribute to the continued development of the ENS ecosystem. The purpose of the Funding Stream is to ensure that there is a sustainable source of funding for projects that are important to the DAO and the ENS ecosystem.

1.5.2 Management and Governance

The Funding Stream is managed by the Meta-Gov Working Group and all funding decisions are made by the DAO community through a governance process. This process ensures that the funds are used in a transparent and accountable manner. The Funding Stream is used to fund a variety of projects, including development, outreach, education, community events, and research and development.

1.5.3 Allocation and Evaluation
The Funding Stream is allocated a specific amount of USDC each year. The DAO community can propose projects to be funded through the Funding Stream. Projects are evaluated by the DAO community and then voted on. The projects that receive the most votes are funded.

1.6 Grant

1.6.1 Definition and Purpose
A Grant is a one-time disbursement in USDC for initiatives that benefit the ENS or Ethereum ecosystem. These one-time grants are used to support projects that are working to improve the ENS or Ethereum ecosystem in some way. Grants are determined by the working groups that distribute them through a program available for submission by any persons or projects.

1.6.2 Eligibility and Selection Criteria
Any person or project can apply for a grant. However, projects that are already receiving funding from other sources may not be eligible. Grants are awarded based on several criteria, including the project’s potential impact, feasibility, and the team’s experience.

etc etc

Interesting idea! Perhaps we can continue to brainstorm this new governor module, at least in the abstract, as a response to @Lemma’s first draft of the bylaws. In effect, we are now discussing not only a revision of the existing bylaws but an addition to them as well.

We need the guidance complete ASAP for reference in upcoming and current discourse.

take note
ENS DAO GOVERNANCE BY-LAWS are subject to, and or explicitly always, or and may be;

  • Ever Evolving
  • Require Continuous Improvement
  • Subject to the addition or omission of policy
  • Should not require on-chain vote unless the measure directly affects the protocol.
  • Changes can be submitted anytime
  • not a permanent directive

Is there an update on this ?