[DRAFT] Developer DAO Improvement Proposal Formalization

[DRAFT] Developer DAO Improvement Proposal

Authors: tonyolendo, willblackburn.eth
See the initial DDIP discussion here and here.

This is a draft proposal. Please comment with feedback!

Summary

The below proposal serves as a meta-proposal to define the Governance process after the deployment of our $CODE governance token. The proposal rules & guidelines defined will go in to affect at the launch of the $CODE token.


What is a DDIP?

A Developer DAO Improvement Proposal (DDIP) is a proposal that seeks to enact a change or changes regarding how the DAO is governed. DDIPs should be limited to the following areas:

  • Any decision that impacts the Treasury balance or allocation.
  • Core Team and Guild Leader appointments, removals, remuneration, and process changes.
  • Advisor relationships and compensation.
  • True Partnerships with other DAO, Protocols, Investors, etc. Sponsorships do not require a DDIP and are handled by the Marketing Guild.
  • Anything that impacts “The Foundation” - referring to the foundation being setup to help the DAO operate.
  • Any other item that affects DAO governance in a material way such as Season specifications, operational working groups outside of the Guild structure defined, etc.

For example, a DDIP is not required for:

  • Guild-related proposals that do not meet the above criteria.
  • Cross-guild decisions that do not impact the treasury.

Who can create a DDIP?

While anyone can complete the first steps below to begin a discussion around a proposal, there are requirements for the Forum and Snapshot vote phases. Our explicit intention is to continue to remove controls around the proposal process. Proposal procedures are at risk for various governance attacks. As we mature our governance mechanisms, we can continue removing controls and decentralizing further.

For a proposal to move to the Forum and Snapshot vote phases, it must be championed by a DAO member with a minimum of 50,000 $CODE who has been allow-listed for Governance procedures. The passing of this process allow-lists the Founding Team members for the Governance process. The governance approved allow-list will be actively maintained and visible on our Wiki.

We hope that by the end of Season 1, we can reduce the controls on this process as we get accurate information about items such as active governing power (percentage of $CODE that is voting in proposals), $CODE liquidity, supermajority refinement, and more. A DAO member who accumulates 50,000 $CODE can trigger a governance allow-list vote without the need for a champion.

What is the DDIP process?

DDIPs must follow the process and format specified below to qualify for our governance process.

Phase 1: Conversations

The starting point of any proposal is a conversation. Discussion of a DDIP should take place on Discord, where members can provide opinions on the impact of the DDIP. There should be clear, observable agreement on an item before entering the next phase. Phase 1 can be further broken down into the following stages.

  • Post in Discord. Start the conversation in the relevant channel. This can be a guild channel where the proposal most closely aligns, the #general channel, or any place where people can discuss and share their thoughts on the idea. Work with guild leaders and moderators to ensure the discoverability of the topic and discussion.
  • Generate Consensus: At least 5 other members should come alongside the proposer to show their support for the proposal. The duration for this is open-ended. The specific means of showing support need not be too prescriptive; the conversation flow should simply show that there are other people who think this is a good idea.
  • Support and Champion: Once a proposal has been sufficiently discussed and there is clear, demonstrable support for the DDIP and the DDIP has received the nod of at least 5 backers and an allow-listed governance Champion, it can enter Phase 2.
  • If needed, Champions can be found by notifying the Moderator role in Discord.

Phase 2: Brainstorming and DDIP Development

Once an idea has received support, it must be documented in DRAFT form using the template here.

A Discord Forum post should be created under the Proposals category. The Governance Guild should be notified to create a new thread in Discord to facilitate community-wide participation and discussion. The goal is to receive even wider community discussion, review, and comments.

The Forum post template will show that the title should include [DRAFT], and the post should be tagged with draft-proposal. This will allow forum members to see that this is a work-in-progress proposal.

Phase 3: Forum Vote

A DDIP enters Phase 3 after it has received observable support in the discussion on the forum. Specifics on the timing of the next stage, the Snapshot vote, should be made clear in the post if required.

The Forum post will end will a clear vote. There should only be one affirmative vote that will move the DIPP to Snapshot voting.

Quorum Requirement: A minimum of 100 forum votes cast will constitute a quorum.

Time Requirement: A minimum of 72-hours must pass before a voting decision is determined.

Supermajority Requirement: A vote will be considered passed if it receives at least 66% affirmative votes.

Phase 4: Snapshot Vote and Execution

The DDIP will then be staged for elevation to Snapshot.

The Snapshot proposal will end with a clear vote. There is no quorum requirement at this time on Snapshot votes. However, voting must run for a minimum of 72-hours before the proposal voting period ends. Ideally, the Snapshot voting period runs for one week.

Once completed and if passed, execution will begin. The Governance Guild is responsible for working with the required guilds/teams/projects/leads to successfully implement the proposal. The Governance Guild will also prepare a DDIP report for the Season’s retrospective.

Quorum Requirement: A minimum of 2% total circulating $CODE will constitute a quorum.

Time Requirement: A minimum of 120 hours (5 days) must pass before a voting decision is determined.

Supermajority Requirement: A vote will be considered passed if it receives at least 66% affirmative votes.

13 Likes

This is an important step in streamlining the process for DAO improvements. I also believe this increases the legitimacy of DAO proposals - if you have to go through a formal process, you are incentivized to know what you’re talking about.

2 Likes

Out of curiosity, how many members will have the required 50k $CODE as of Season 1 starting?

4 Likes

Definitely like this approach to progressive decentralisation via $CODE holdings. I believe it is really important we include a step before a members is given the power the post to snapshot to ensure people cannot just buy up tokens and perform a Governance attack. Maybe this could be a DAO wide vote once a Season, or a committee that has this power delegated to them?

I think it is important we introduce some kind of rule about an emergency snapshot proposal being expedited to snapshot by people who are allowed to post to Snapshot. Such situation this may be important could include:

  • The release of funds required for any legal defense of the Foundation when setup (potentially to apply to directors of that foundation also given the risk they are taking on in being named/doxed in this way.

we should probably create a snapshot poster role or similar to make this easier.

is it assumed that any vote that passed this threshold will be elevated or does it also require the support of someone with the rights to post to snapshot? What happens a vote passes this threshdold but no one with those rights feels comfortable elevating (for whatever reason, discourse is open to anyone after all…). Would it make sense to have a check here for sybil resistance? Otherwise who has the rights to post to snapshot doesn’t actually have strong sybil resistance if they have to action each vote. hope that makes sense!

This will only be the founding team at genesis of Season 1. Given how the Coordinape rounds are playing out though suspect sever core contributors will be quite close and with further $CODE being earned via [DRAFT] Rewarding Contributions in $CODE people should this thresh pretty quick into S1.

I think it’s important we still have some kind of manual check here either a DAO vote that allows someone to be given this right OR an elected committee with delegated responsibility to approve/reject, to ensure people can’t just purchase lots of $CODE and perform a Governance attack

Once completed and if passed, execution will begin. The Governance Guild is responsible for working with the required guilds/teams/projects/leads to successfully implement the proposal. The Governance Guild will also prepare a DDIP report for the Season’s retrospective.

I understand it is common practice within governance to provide a grace period of 2-3 days before work begins on the passed proposal. This is mainly used in DeFi protocols, but maybe worth using a grace period as it provides people a few days to sell off their ‘membership’ if they do no agree with the passed proposal.

This mentions a governance allow-list vote, but maybe it should be a bit better defined.

I would love to avoid language like that in the proposal. One idea would be to remove the time requirement on the forum vote and leave it as a suggestion. But I think 8 days is survivable in almost all cases and preferable.

Yes, phase 1 requires finding an allow-listed champion. I think I should make that part of the template explicitly.

1 Like

I like this idea for the future, but I think with us not having an on-chain protocol and needing to move fast early on, it’s worth leaving this out.

yes believe it’s important we define this so it’s clear. could potentially see it being existing allow-list members that need to approve of someone being added or a committee ?

do you have any thoughts on that?

awesome. not sure if I’m miss-understanding but i’m thinking it would be better to require someone from the allow-list to support prior to starting a forum vote. this would avoid a potential bad situation whereby a forum vote passes and then no one on the allow-list supporting it.

yeah can see what you mean re language. don’t think the forum vote should be optional though, this proposal process need to be really explicit imho, and agree you’re probably right 8 days is survivable in most situations.

just wanted to check your thoughts on this vs using the Moderator role given they are not a 1-to-1 match?

I’m happy to see this process get formalized. Thank you everyone for working to push this forward! Really critical work for our future.

The like the general process of discussion->forum draft-> (approval with champion support) → forum vote → snapshot vote → action.

I have some concern around timings. For some things, this will be too slow, and for others, this will be too fast.
For emergencies, pushing through governance will take ‘an eternity’. I’m not sure adding a ‘fast-track’ provision is truly wise, but without it we may be left in a bad situation. Perhaps an emergency fund to cover emergency contingencies? Not sure about this one. Ideally, let’s just not have any emergencies for now. :slight_smile: (Perhaps a quorum of trusted champions should be able to trigger faster action?)
On the other side:
For serious fundamental changes, like to our mission and values for instance, a week or two seems much too fast. I’m not sure what to propose here, but some things should require a higher bar to change - perhaps like the difference in procedure between adding a law and amending a constitution.
Does it make sense to consider some decisions (like mission and values) to be ‘locked in’ and require an ‘unlocking’, or a higher bar (in time, in quorum, in super-majority) for amendment?

2 Likes

@willblackburn as I’m draft the 1st version of the ByLaws for The Developer DAO Foundation it’s becoming clearer how important sybil resistance is for this process.

The Foundation Company’s director will be bound to the will of the DAO in almost/potentially all situations. This makes it really important we clarify the follow:

This mentions a governance allow-list vote, but maybe it should be a bit better defined.

We need this check and balance in the DDIP process so bad actors cannot simply purchase enough tokens on the open market to perform a Governance attacked as this could give them the power to add/remove directors or even empty the treasury.

We’re also going to need to add something to this section to make it clear anything that impacts The Foundation Company must go to snapshot:

A Developer DAO Improvement Proposal (DDIP) is a proposal that seeks to enact a change or changes regarding how the DAO is governed. DDIPs should be limited to the following areas:

  • Any decision that impacts the Treasury balance or allocation.
  • Core Team and Guild Leader appointments, removals, remuneration, and process changes.
  • Advisor relationships and compensation.
  • True Partnerships with other DAO, Protocols, Investors, etc. Sponsorships do not require a DDIP and are handled by the Marketing Guild.
  • Any other item that affects DAO governance in a material way such as Season specifications, operational working groups outside of the Guild structure defined, etc.
1 Like

I think it’s important that we build eventually-sunsetting protections into our processes and rules. Our process for progressive decentralization will be ongoing, with the major phases in these early seasons taking place on the order or ~2-3 years.

According the the attached proposal [DRAFT] Rewarding Contributions in $CODE the avg. seasonal reward is 2400 $CODE, meaning that on avg it will take 5 years to get to 50k.

How does that play with the gradual decentralization, is this the approx. time frame or are we counting more prominent token re-distribution via purchasing?

2 Likes

I cannot speak to the exact calculations, but there will be many contributors who earn above average rewards and will collect $CODE faster. There will also be other ways to earn $CODE than budgeted positions such as retroactive coordinape circles.

this is a really good question. adding to @willblackburn 's comments these calculations are an estimate of the average contributor however more active contributors are likely to receive considerably more $CODE for their contributions per Season and thus those core contributors will reach the threshold faster.

It’s also important to note these are starting points to have a “good enough” system in place that allow the DAO to start recognising and rewarding contributions whilst still maintaining some sybil resistance as we mature as an org. I suspect we may have increase the $CODE rate and/or reduce the threshold as we see how this plays out in S1.