Structure around TIPs; initiation, discussion & voting

[Naxsun]

This is a proposal by @jakelynch and @Nahsun trying to collect thoughts & ideas and make a first proposal on a potential Threshold DAO voting structure and process.

Goals

• Easy for existing community to navigate and easy for new community members to participate in the future
• Ability for anyone to submit an initial proposal
• No voter fatigue and no voter spam
• No conflicts of interest (e.g. proper delegation of powers)

How

• Categorizing TIP’s
• Clustering multiple TIP’s on a voting ballot
• Effective triage system
• A fixed voting schedule / cadence, that allows to plan, promote and for parties to align with stakeholders well up front

Building Blocks

• Elected Multi-sig 9-person council (4-4-1 structure)
  • Staking rewards management
  • Contract upgrades
• Token Holder DAO (first instance of governor bravo)
  • Treasury Management (power of the purse)
  • Token Issuance (t-token contract)
  • Governance System Changes
• Staker DAO (second instance of governor bravo)
  • Contract upgrades
    • Can be vetoed by Token Holder DAO
  • All other responsibilities
• Developers

Do we want a quorum?

• Projects have run into issues regarding quorums relating to:
  • Trouble establishing a threshold – this is especially true for new projects that do not have sufficient data to track participation.
  • Voter fatigue or tragedy of the commons (i.e voters feel lack of motivation if uneducated on vote or the vote is going the direction they want).
  • Network gas fees and other standard excuses.
• A quorum system is inefficient in that a high quorum could lead to voter stagnation, while a low quorum can lead to ballot abuse.
• A council is in the best position to vet these proposals, assess their merits and effectively triage governance decisions.

Proposals are categorized into three categories

• Urgent Proposal (related to security)
• Proposal is not time-sensitive
• Time-sensitive Proposal (not related to security)

For contract parameters, an initial decision is made up-front in which category each parameter falls.

There will also need to be a group of proposals where the multi-sig as a council is not part of the temperature check & voting process, for example voting members in and out of the council.

Urgent Proposal (related to security)

• This is based off this proposal by @maclane and @pdyraga
• Dev team is notified by white hat and prepares a patch
• Multi-sig is notified by dev team and implemented patches
• Token Holder DAO is informed, and a time-sensitive proposal is drafted to compensate white hat

The flow for non-security related proposals to be as follows:

1. Initiate a proposal (anyone)
2. Temperature Check (optional)
3. Multi-sig council selects proposals for biweekly ballot
4. Proposal discussion and education
5. General Assembly votes on proposal

Potentially step 3 and step 4 could be swapped. This increased the risk for voter fatigue, but it would allow the multi-sig to make a more representative judgement. We’re interested in hearing the thoughts from others here.

Proposal is not time-sensitive

• 2-week period from initial proposal to voting completion
• Phase 1 (1 week)
  • Education / Defense Period
  • In the first week, the proposer will be responsible for answering questions and defending the proposal.
  • Council can use this to determine whether the proposal should be added to the voting ticket
  • Temperature check
  • Council does a preliminary vote to determine if proposal has significant backing and/or has merit and should go to general assembly for vote
  • Council can rely on Signal to gauge community (that is not required – they can skip Signal vote and go straight to ballot)
• Phase 2 (1 week)
  • All votes are cast in this 7-day vote period (ending on Sunday midnight UTC+00:00)

Time-sensitive Proposal (not related to security)

• A special vote is initiated that follows a similar process as the not time-sensitive proposal but on an independent schedule that is cut in half
  • Phase 1 (3 days)
    • Education / Defense Period
      • See above
    • Temperature check
      • See above
  • Phase 2 (4 days)
    • All votes are cast in this 4-day vote period (ending is variable - 7-days from start of phase 1)

[Will]

Combating potential voter fatigue and providing the community with a clear method of knowing which proposals are the most important are both governance wins.

Are there any other DAOs that have a batched voting system like this? It would be helpful to look at them as a reference point.

[jakelynch]

The BarnBridge DAO implements a similar batch-voting approach. The above proposal makes some meaningful and intentional deviations from BarnBridge’s model.

BB uses Signal voting in a similar way (as a temperature check). However, this has led to some disputes as to whether the core team should be able to participate in the signal votes - ironically ending in a Signal vote (linked here). This is certainly something we should address before making the same mistakes, but that’s a separate topic.

Their motivation for batched voting is:

1. The Signal vote filters proposals out early.
2. Batched voting saves gas.

This is the outline of their onchain voting process (per their docs - linked here):

Currently, the core team coordinates when DAO votes occur in order to optimize for this gas intensity. DAO votes are reserved for actual on-chain actions, whether that be deploying smart contracts or allocating treasury funds. This means that such votes will occur periodically as roadmap items get deployed (e.g., new applications, new liquidity mining reward pools) on-chain; such votes could however be called by any community member willing to pay the associated gas fees. Each DAO vote can support up to 10 separate on-chain actions, which is why we currently roll successful Snapshot proposals into them.

Each proposal is formed of:

• ID

• Title

• Description

• List of targets (addresses)

• List of values

• List of signatures

• List of calldata

A proposal can execute up to 10 different actions, but they must be done so atomically (i.e., all or nothing).

In order to give DAO participants enough time to stake, vote, check and discuss proposals, each of the following periods lasts for 4 days: Warm-up, Voting, Queued for execution, Grace.

Notice, the Queued period is the only state that requires a user action to activate. So when it is activated, its 4-day lasting period counts from the moment when the voting ended, not when the user did the action. For example, if voting ends and someone queues the proposal 2 days after, it will not stay in the queue for 4 more days but only 2 days because 2 have already passed.

During the Queued period, a special type of proposal, referred to as an Abrogation Proposal, can be added to the original proposal. While such a proposal allows for a last-minute action to be added, it requires 50% of staked BOND to participate; essentially, it serves to provide extra bandwidth for DAO action in the case of an emergency vote.

Once a proposal is accepted, it will have to wait in a queue before it can be executed. During this time, it can be canceled by:

• the creator;

• anyone if the creator’s balance falls below the 1% threshold;

• cancellation proposal.

Once a proposal becomes executable, any users can call the execute function. If the proposal is not executed during the Grace period, it is marked as expired and cannot be executed anymore.

Based on my experience working with BB, here are my thoughts on their model and some reasons why @Naxsun and my proposal deviates significantly (while still advocating for batch voting):

(1) We believe a scheduled voting period is more reliable and easier for people to incorporate into their life - if you know that there is a vote every two weeks you’ll be there. If there’s nothing to vote on, that’s not a problem. If there’s an emergency or something time sensitive, we’ve addressed that.

(2) BB relies on the core team to determine whether a signal vote has “clearly unanimous agreement among the community’s most engaged members”. This is ambiguous and can lead to conflict. For our proposal, it makes sense to have the Council, who is elected to represent everyone, determine what should make it on the ballot. They are incentivized to listen to the community and the inclusion of something on the ballot is not a risk IMO (exclusion is a risk - but that is why their incentives matter).

(3) BB also requires a quorum to avoid votes being rushed/pushed through without majority consent. IMO a scheduled vote accomplishes the same goal, but does not come with the same error (to be specific, the error that occurs often with quorums is that voters do not turnout because they agree with the vote so a quorum isn’t established and something good doesn’t get passed). Our proposal is like the town hall model, which encourages active participation, but does not punish abstaining.

(4) Lastly, I believe a major mistake that BB makes is that they aggregate all of the onchain votes into a single yes-no for each batch. If you vote yes, you vote yes for all of the proposals on the ballot. If you vote no, you vote no for all of the proposals.
To be extremely clear: this is not what we are proposing. We are proposing that votes occur at the same time (e.g. batched), but not that they are contingent on each other. BB does this because they trust the temperature check and see the onchain vote as more of a formality. I think this is a mistake for many reasons that I can expand upon if requested.

I also want to add that this proposal is just a first draft. Our goal is to find the best pipeline/process for the T community governance, so if there are any concerns with this proposal or alternative approaches (even if they are radically different), I know that Nahsun and I are very interested in discussing the pros and cons.

Some helpful background: I’ve based a lot of my contributions to the proposal on what I consider to be the good parts of US-based local, state and federal govt.

[Eastban]

Great work on this proposal @Naxsun and @jakelynch, thank you very much !
I agree on almost everything on this voting structure for our current starting state of the Threshold DAO.

I really like the idea of a fixed voting cadence, but I’m not sure that a 2-week voting process is the right cadence. Having to inform/discuss/decide/vote every 2 weeks still sounds exhausting to me.

For non time-sensitive proposals, I would rather propose a month based schedule, and try to educate the whole community around the fact that we all have one determined period in the month where we should pay attention, decide and vote. Seems simple, predictable and straightforward to me.

I saw this in MakerDAO which has a far complexer DAO. They call it Monthly Governance Cycle, and seems to work fine :

MakerDAO’s MIP51 defines a monthly Governance Cycle that provides a predictable framework for Maker governance decisions :

I mention this as an example, keep in mind that:

• MakerDAO is today a mature, large and more complex DAO.
• their proposals have a review and freezing period prior to this government cycle, as can be seen in the following graph.
• submitted proposals must follow strict guidelines defined in MIP0.

[jakelynch]

I think monthly makes a lot of sense and would lead to much more engagement when it matters.

[Naxsun]

Same here.

Monthly for non time sensitive and weekly for time sensitive non-security related sounds good.