Proposal draft: 5 projects to improve governance + time-based compensation

Hello Nouns & community,

We are looking for potential committee members who can help us work on this proposal further and who would like to be involved in managing us and our output over time. Let us know if you are interested!!

TL;DR

  • Nouns governance needs more work in order to accelerate proposal velocity and enable a thriving building ecosystem for Nouns DAO
  • We want to work full-time on Nouns; in this proposal we’re hoping to tackle important governance problems, using time-based compensation

  • We are asking to be managed by a committee of 3 or 5 Nowners, for a period of 3 months, with monthly payments
    We are looking for nowners/nounders/sub-dao members to join this committee. Reply below if you would be interested!

  • We will work with feedback from the DAO in milestones of: prioritization, design, coding, and deployment

More on the governance problems, and proposal structure below

We’d really appreciate your take on:

  • Who do you think should be on the committee? Are you interested?
  • Would you like to try this funding approach?
  • Do you agree with our pricing model?
  • Any problems you’d like to add / remove / adjust?

Curious for more background? see our previous governance brainstorm.

Funding: time-based rather than project-based

Project-based pricing is hard for both the proposers and the DAO, because of all the details that aren’t fully fleshed out at the proposal stage. Moreover, for us on the proposer side the cost of generating a highly detailed and accurate estimation is great, leaving us with a lot of upfront investment, with the high risk of our proposals never passing, or simply taking a very long time to iron out.

We believe time-based compensation is a great solution the DAO should try out with us. Together we can mitigate risks for both sides, and reduce the “cost of doing business”.

  • Our risk is mitigated since we get paid for our time spent in all the pre-building prep work: prioritizing sub-projects, designing solutions in high detail, getting technical design feedback, etc.
  • DAO risk is mitigated by releasing funds over time rather than all at once, with a committee that can stop the funding and fire us at any time

Basic mechanics

  • By approving this proposal, the DAO decides to:
    • Appoint a committee of 3 or 5 Nowners, with the responsibility of managing a budget and the team
    • The budget would be held in a multisig wallet managed by the committee
    • The committee can easily decide when to pay, and when to stop the project, fire us, and refund the DAO
    • At the beginning of each month, funds will be paid out:
      • To Verbs: the sum of 2 developer salaries detailed below
      • To committee members:
        • We believe it’s sensible to compensate committee members for their time since we expect them to be involved in execution details, from prioritization to design and code reviews
        • We are awaiting to find our committee members and discuss this in more details with them

As you will see below, we’re hoping to have the opportunity to build solutions that would improve the DAO’s ability to execute ongoing payment models, including proposals such as this one.

Pricing: bottom-up open calculation

We’re hoping this proposal can contribute to how proposals are priced. We’ve therefore created a step-by-step calculator for how we arrived at the compensation we’re asking for. Please look at the calculator and let us know what you think!

Specific compensation numbers

(Note: these are based on the factors outlined in the calculator above. Compensation is always a sensitive topic, especially within a DAO. We are open to negotiating these factors, but we think it’d be most effective to do so with a committee and not the whole DAO)

  • Verbs
    • @verb-db (David): $48K / mo
      • David is fluent in cryptography, and has a deep understanding of how Ethereum and Bitcoin work
    • @verb-e (Elad): $62K / mo
      • Elad understands Ethereum well, and has practical experience in Solidity development
    • Total:
      • $110K / mo
      • 32.35294 ETH / mo (ETH priced at $3,400)
  • Committee
    • Awaiting specific committee members and discussion with them

Working collaboratively

We plan to work closely with the committee and the DAO at large, asking for your attention when it matters, mostly for important milestones. Our key expectation is for the committee to be engaged in details such as:

  • Prioritization: choosing the next sub-project we should tackle
  • Tech Design: we will start each project with detailed design, as well as a deployment plan, and share the important details in clear writing
  • Code: all code will be open sourced, and we’re hoping developers in the Nouns community beyond the committee will choose to review as well

Problems we’d like to tackle

This is just our initial suggestion. We’re hoping to improve this list over time with our learnings from deep-diving and from feedback, and potentially update priorities in coordination with the committee.

1. Enable proposal amendments

Amendments are a key solution in allowing proposals to error-correct thanks to community feedback. At the moment the lack of this feature has led to proposals 3 and 4 having off-chain amendment commitments, while the DAO would prefer the entire agreed-upon proposal to be recorded on-chain.

While it’s key that contributors work hard to get and process feedback from the community prior to proposing on-chain, some last-minute discoveries are inevitable, and the DAO’s contracts should support these instances, in the spirit of continuous learning.

Basic mechanics:

  • Who can amend:
    • The Noun(s) who submitted the proposal
    • The contributors behind the proposal, via an amendment delegation granted to them by the proposal submitters
  • When is it possible to amend:
    • While the proposal is Pending
    • If it’s Active with no votes yet
    • If it’s Active, with some votes, and all voters agree to amend
  • What changes upon amendment:
    • The proposal’s timer (startBlock & endBlock) is reset
    • The proposal’s markdown content can be updated
      • A technical approach can be to store diffs on-chain (including their timestamp) in order to minimize gas cost
    • The proposed transactions can be updated
    • All its voting data is reset, e.g. vote counts, whether it was vetoed, etc.

2. Support an Ongoing Payments proposal type for servers and salaries

We’re assuming the Nouns DAO has interest in:

  1. Retaining talented contributors who need steady income
  2. Funding server & maintenance costs for services the DAO chose to build and deploy

We think the current proposal structure isn’t ideal for these use cases, because everything must be decided in advance, without the flexibility of adjustments over time.

Suggested solution: proposals that permit ongoing payments, codenamed “Subscription Proposals”. Subscription Proposals (SPs) features:

  • Committee: each SP will include specific Nouns the DAO designates as its managers. The committee has powers such as:
    • Budget adjustments, with a certain cap. Above the cap they would need to create a new proposal with an updated budget that would replace the existing one
    • Pause payments
    • Extend the expiration date of the SP, with some cap, e.g. two months
  • Payout Cycle: e.g. 2 weeks, once a month
  • Payout Budget: how much is paid out each cycle
  • Expiration Date: when the subscription expires, e.g. after one year
  • Recipient: the wallet to which the subscription is paid

The DAO might want to change the members of the committee:

  • The first version could only include a feature of the DAO cancelling the subscription proposal, and having to create a new one with a new committee
  • An improved version would of course include functions that allow the DAO to hire and fire committee members while keeping the SP active
    • The simplest approach is probably to use the proposals mechanism, such that proposals can support transactions that update the committee members of a SP

3. Support partial delegation to enable sub-DAO representatives

:tophat: Hat tip to kenny-studiodao for this idea!

Say SharkDAO wants to delegate their 4 votes to 4 different Ethereum accounts, such that they could have more people holding official roles in various systems:

  • Discord and Discourse
  • Voting on proposals
    • Here it can get really interesting, as it allows SharkDAO to experiment with representative democracy, i.e. allowing Sharks to have multiple voices in the Nouns DAO

Currently delegation is all-or-nothing. We believe changing the Nouns DAO governance contracts to support partial delegation is a cost-effective change.

4. Proposal content should be compressed, to minimize gas cost

Today the proposal markdown content is saved as plaintext, which results in high gas costs when uploading proposals.

Content compression will make gas costs much lower, which would further reduce friction around creating proposals.

5. Add “Proposal Retrospectives (Retros)” to improve DAO-wide learning

We think it’s important to close the loop on things we try. Adding retrospective votes on-chain adds an important new moment in which the DAO comes together to reflect and synthesize learnings.

How it could work

  • Each proposal can have an optional retrospective configuration
    • We might want to allow proposals to have multiple retrospectives with different dates, especially for projects that can take a very long time
  • A key point here is that the retrospective is configured during the proposal drafting phase – so we can all get aligned on what’s important to retro before execution begins
  • A retrospective would consist of the following:
    • Retro Date: how many days after the proposal was executed do we expect the retrospective to begin?
    • Duration: it would have similar states and time durations like proposals, e.g. a couple of days to deliberate, a few days to vote, etc.
    • Questions: a collection of questions the DAO can vote on
      • The simplest approach would be Yes/No/Abstain questions
      • A more robust approach would be questions with N options, similar to online surveys
      • Each question has some text description and labels for the answers
  • Quorum: we don’t think a quorum is needed as long as these votes don’t control funds; if in future the DAO would like to tie these votes to funds, we would need to reconsider
  • UX:
    • We would need to add retrospectives as a feature to the proposals UI on the Nouns website, so Nouns can easily interact with them
    • We’d probably want everyone to have reminders of upcoming retrospectives, e.g. in their calendars

Example based on the Verbs’ automation prop (Prop 4):

  • Retro Date: we would set it for 30 days after the prop was executed
  • Questions:
    • Did the proposer deliver on what they promised?
      • Yes
      • No
      • Abstain
    • How would you feel if you lost access to these automations?
      • Very disappointed
      • Somewhat disappointed
      • Not disappointed
      • N/A (Abstain)
    • In hindsight, would you vote for it?
      • Yes
      • No
      • Abstain

Thank you for your time and feedback
The Verbs

1 Like

while i appreciate your enthusiasm for building on nouns, overall I find this proposal to be very unfocused in the way that it lists several ideas and fails to prioritize or discover the real need for any of them. combined with the astronomical salaries and very strange calculator to justify them, i’m personally a big ‘no’ on this.

if you genuinely want to build on the ecosystem full-time, find a specific initial problem that you’re passionate about, propose a detailed solution to the problem, ask for a reasonable sum of ETH to execute it, then rinse and repeat, growing your compensation and funding intervals as you prove your ability to execute and earn the communities trust.

given the sums involved, the proposal system isn’t so burdensome that you can’t engage with it once per month at the outset. the current proposal to lower the proposal threshold to 1 NOUN and the addition of Discourse as a place to coordinate pre-proposal should also help

3 Likes

Thanks @4156 - we’re grateful for your thoughts! A few in reply:

  • Unfocused: we think all ideas are solving real problems. Can you say which one you relate to the most? We’d love more feedback that’ll help us prioritize (by the way prioritization is one of the most difficult things to achieve with the DAO so far)
  • No need: just as an example, the Amendment idea solves actual problems we’ve seen in both props 3 and 4 that resulted in offchain amendments
  • Salaries: we’ve shared an open model rather than just throwing a number, with the hopes that it’ll help create an informed discussion. Can you share specific points you would change? We really think such a calculator should be useful for all DAO engagements. We see Dev cost as another problem in proposals we’re trying to iterate on with the DAO, and this spreadsheet is our attempt
  • Rinse and repeat: our feedback to the DAO is that it’s costly to provide highly detailed proposals for every idea prior to execution, especially with what we feel are currently slow feedback loops. We’re suggesting a different approach where the DAO would attempt to hire for time, rather than per project. Would love to hear more specifically why you don’t like this model?

As you said, we’re still interested. If we can get inputs on what’s everyone’s favorite problem from our list, we can put up a more detailed proposal on it.
We would then appreciate everyone’s help in getting it through the proposal process quickly. In other words, we’d love to learn that the process is now more efficient that we think!

P.S.
We’re more than happy to listen to any idea you or any other Nowners are excited to see built - we want to ship great ideas from any source!

1 Like

This proposal asks for the formation of a committee to decide on the process for deciding on proposals. These are already in place. DAO-management seems to be becoming a new trend. It is quite redundant as DAOs are a form of management themselves.

This is succinct and great advice though:

if you genuinely want to build on the ecosystem full-time, find a specific initial problem that you’re passionate about, propose a detailed solution to the problem, ask for a reasonable sum of ETH to execute it, then rinse and repeat, growing your compensation and funding intervals as you prove your ability to execute and earn the communities trust.