[Draft 2] Firming up Governance

Title: [Draft 2] Firming up Governance
Authors: frogmonkee#6855
Squad: frogmonkee#6855
Date Created: November 7th, 2021
Date Posted: November 8th, 2021

CC’ing those that replied to the original post:
@NFThinker @hashedMae @hodl @RedVan @Kouros @Grendel @cyclist @tomahawk @angyts @chao @jameswmontgomery.eth @ZrowGz @chao @samanthaj

:warning: Changes from the previous draft are marked with a :warning:

SUMMARY

This proposal introduces some voting parameters and guidelines in response to feedback around the recent Proposal: Olympus Pro post.

Included are:

  • Specificity on what goes to snapshot and what does not

  • Quorum and voting requirements

  • Community education guidelines

  • Proposal wording and presentation

BACKGROUND

  • Olympus Pro was first formally mentioned on October 1st during the inaugural tokenomics discussion.
  • On October 14th, Proposal: Olympus Pro was posted to the forums.
  • On October 22nd, the proposal was uploaded to Snapshot and went live for voting on Monday, October 25th.

Since then, voting is 78% in favor, with 6.7M BANK voting no. Relative to previous snapshots, this discrepancy shows a divide in the community’s sentiment. Previously, the largest deny vote we saw was just under 600K BANK at 2.66% voting Deny.

Having spent much time listening to people thoughts and concerns, I’ve identified the following pain points:

  • Many individuals were surprised to know this vote would go to snapshot and not to the Grants Committee, as they were accustomed to seasonal specs being ratified on snapshot and the GC distributed the seasonal allocated budget.

  • The proposal went to snapshot before some members could even participate in the forums. Specifically those with less time to participate in day-to-day activities

  • Individuals that were not educated on the topic felt like they had to sit out

  • Individuals felt like their opinions were ignored.

  • The snapshot vote left out crucial information, like a link to the forum post and the voting options were worded were not impartial (Deny option)

MISSION & VALUES ALIGNMENT

Back during Season 0, when we began outlining our governance processes, we emphasized the importance of gathering consensus within the community and using Snapshot as a way to ratify decisions, hence a consistent 95%+ approval rating on prior snapshots. This was because, historically:

  1. Many snapshot voters are not engaged in day-to-day operations in the DAO and will miss a lot of context. Simple things like framing language are enough to significantly sway votes.

  2. Voter fatigue is real. Too many votes is too much noise. This is reflected in Index Coop, which has very low participation on many of their snapshots and is reflected in our own snapshots, with a variance of almost 50% of voters at times.

This is consistent with what Boardroom, a governance platform, is noticing as well.

For these reasons, we have a robust proposal process (unlike Sushiswap that has proposal like this) and a seasonal spec that embeds much of our decision into one ratified vote.

To align with these values, I’d like to introduce a number of different rules and mechanisms that will help us gather community consensus before moving something to snapshot.

SCOPE OF WORK

Proposes a series of changes to governance that, upon soft consensus will be ratified with an on-chain snapshot vote and subsequently included in each Seasonal Spec thereafter, as parameters are likely to change.

SPECIFICATION

What Goes to Snapshot?

Part of the confusion here is understanding what goes to snapshot and what doesn’t. Historically, we’ve sent the Seasonal Spec to snapshot, along with validating project and guild funding. This is the first time we’ve had a purely tokenomic post gain traction and it wasn’t clear to the community that it would go to snapshot. As such, here are few reasons something should go to snapshot. Please comment if you have further suggestions:

  • Seasonal specification (including Grants Committee allocation) [1] [2]

  • Seasonal Project and Guild funding [1]

  • Major Governance changes [1] [2] [3]

  • Tokenomic changes [1]

  • Grant committee decision with sufficient conflict of interest (eg. cannot achieve majority vote) [1] [2]

  • Extending budget

  • Emergency vote / “Break glass” scenario (See Appendix A)

What does not go to Snapshot?

  • Individual projects funding

  • Additional guild funding

Quorum & Voting Requirements

:rotating_light: Quorum requirements are formalities to achieve sufficient consensus. Culturally, we should thinking beyond quorum. If a proposal reaches quorum and voting requirements, it is your responsibility to capture feedback and dissent in order to achieve better alignment. If someone raises a good point or you gauge sufficient disagreement, go back to the drawing board and incorporate that feedback. @Kouros has a great example with his Gas Reimbursement post. Despite having a nearly 90% in-favor voting, he has opted to redraft his post to incorporate feedback. We are a DAO, we move together. Ape strong together.

We don’t have clear guidelines on what qualifies as quorum. As such, I’m proposing the following. I suspect some of these will be controversial, so I’ve added some context.

  • :warning: Forum quorum is a rough estimate. For reference, both Olympus Pro and Tokemak have over 70 votes while these two 1M+ BANK proposals have 45 votes [1] [2].

  • Snapshot quorum is the average amount of BANK voted with since S2 prep.

  • 80% approval is quite high, but I think we need to be strongly aligned. As mentioned, things that go to snapshot should already have strong consensus. Furthermore, there is a LOT going on in the DAO. A high threshold makes sure that only widely supported ideas get the financial and on-chain support they need.

  • Tokenomics is not explicitly included as proposals would fall within the budgetary ask

  • Timeline refers to how long it must stay up on the forums

  • Emergency vote bypasses time requirements in favor of greater voter turnout and alignment.

  • :rotating_light: Each season, quorum & voting requirements can be updated as part of the Seasonal Spec

:warning: The biggest point of contention in the previous post was voting requirements. I’ve included some polls below to gather consensus:

:warning: Standard Forum Voting

  • 51% +
  • 67% +
  • 75% +
  • 85% +

0 voters

:warning: Standard Snapshot Voting

  • 51% +
  • 67% +
  • 75% +
  • 85% +
  • 90% +

0 voters

:warning: Emergency Protocol Forum Voting

  • 51% +
  • 67% +
  • 75% +
  • 85% +
  • 95% +

0 voters

:warning: Emergency Protocol Snapshot Voting

  • 51% +
  • 67% +
  • 75% +
  • 85% +
  • 95% +

0 voters

:warning: The second biggest point of contention in the previous post was quorum. I’ve included some polls below to gather consensus (apologies for the # of options)

:warning: Snapshot Voting Quorum

  • 30M BANK
  • 35M BANK (Avg since S2)
  • 40M BANK
  • 45M BANK

0 voters

:warning: < 50K Forum Quorum

  • 20
  • 25
  • 30

0 voters

:warning: < 50-250K Forum Quorum

  • 25
  • 30
  • 35

0 voters

:warning: < 250-500K Forum Quorum

  • 35
  • 40
  • 45

0 voters

:warning: < 500K-1M Forum Quorum

  • 45
  • 50
  • 55

0 voters

:warning: < 1M+ Forum Quorum

  • 55
  • 60
  • 65

0 voters

:warning: Governance Forum Quorum

  • 55
  • 60
  • 65

0 voters

:warning: Emergency Protocol Forum Quorum

  • 85
  • 90
  • 95
  • 100

0 voters

Education Requirements

Proposals with big asks and governance changes are often complex. As such, they need to be properly communicated to the DAO with time for them to digest and process new information.

In the Additional Requirements section, there are three education tools to use:

  • A short 5 minute presentation on the community call

  • A longer Q&A and presentation, selected at an optimal time via Lettucemeet (needs to be included in the forum post and scheduled after surfaced on the community call.)

  • Presentation must be recorded with at least 1 week to let people listen to the on demand video. This could extend the 2 week timeline if the recorded video is uploaded with less than a week in the timeline. PLAN ACCORDINGLY.

  • Tokenomic and governance decisions would get priority editorial placement in the Weekly Rollup as an educational explainer piece while they are in the forums.

:warning: Proposal wording, presentation, and conflicts of interest

  • Snapshot posts must always include a link back to the proposal’s forum posts

  • :warning: Snapshot voting options must have a clear ask followed by two options: “For” and “Needs Revisions” as much as possible. Given that soft consensus is meant to be gathered well before moving to snapshot, multiple voting options can skew the outcomes, as pointed out by HashedMae.

  • :warning: Proposals can have more than two options when asking the community to select between an array of options for an already-approved option. For example: [1] and [2] are not asking for consensus on whether we should execute a particular action, but rather asking for consensus on how to do something that has already been approved.

  • :warning: Proposals must include a section for disclosing any conflicts of interest, namely if (1) Members of the squad are associated with any party involved outside of BanklessDAO and (2) Members of the squad hold any investments with any party involved outside of BanklessDAO.

  • :warning: Proposals on Snapshot must include quorum and voting requirement criteria

  • Agree
  • Disagree (leave comments)

0 voters

FINANCIAL IMPLICATIONS

Not applicable

BRAND USAGE

Not applicable

SUCCESS METRICS OR KPIS

Not applicable

NEXT STEPS

  • Incorporate feedback into a new draft

  • Move to snapshot

SQUAD BACKGROUND

@frogmonkee - Long time contributor to BanklessDAO. Active in Writers Guild, Ops Guild, and strategy for the DAO. Care deeply about governance.

:warning: APPENDIX A - Emergency Scenarious

An “Emergency Scenario” would refer to a proposal/motion that needs to fast track consensus and would likely consolidate power into the hands of a few for a short period of time, often the multisig signers. Examples could include:

  • Liquidating positions due to black swan events
  • Legal action against the DAO
  • Smart contract hacks
  • Immediate changes to governance (IE closing a governance loophole)

Emergency proposals would indicate that they are initiating the “Emergency Protocol” which fast tracks soft and hard consensus by increasing quorum + voting requirements and removing all time requirements.

8 Likes

Thanks for the post, very analytical and well explained, it is also useful to define more precisely the terms of approval of the projects.

2 Likes

Great work, @frogmonkee.

1 Like

Thanks for the second draft.

We really need ranked choice voting or some kind of weighted average rather than simply choosing the 1 of 5 vote percentage options with the highest # of votes.

The winning percentages may not ultimately make sense in terms of raising the bar for passing with each level of higher severity votes if voters don’t accordingly vote for higher requirements as the severity increases above.

80% was an option in the prior poll, and I became convinced that should be necessary for emergency actions. However 85% didn’t sit well with me, and I reverted to 75%. Why was 80% not an option in any of these voting requirements when that was initially proposed? Maybe I’m picky, but I like low whole number ratios like 2/3, 3/4, and 4/5. 17/20 is no bueno.

Could someone define “emergency protocol” or provide a link where it is defined? Thank you!

1 Like

@samanthaj:
It’s in loosely defined in the Appendix.

@tomahawk
Yeah the numbers are kinda arbitrary. I struggled a lot with choosing the right amounts. Discourse doesn’t have ranked choice voting, so we would need to use an external application. If other people feel the same, I can try to make that happen. I’m not heavily opinionated.

1 Like

Does 20, 25, and 30 denote the # of members that need to vote for a proposal that is seeking less than 50k bank?

@tomahawk has a great point here. Say 30 of us vote and 8 vote for 85%, 9 vote for 80%, and 13 vote for 75%, the majority of voters wanted a consensus either 80% or over, but 75% wins because the most people grouped for that number. The minority beats the majority because the majority was split. This could create a U.S. republican primary of 2016 problem.

@frogmonkee I can help look into ranked choice voting options for this. I’m trying to think through the best way to handle this issue.

Yes, this is correct.

1 Like

Sorry if I’m coming across as hypercritical. I do very much appreciate the time you’ve put into improving these processes.

If ranked choice isn’t a practical solution, we could use a weighted average as such:
Consider the Standard Snapshot Voting poll. If the number of votes for each option are v, w, x, y, and z respectively, and the total number of votes is n = v+w+x+y+z, we can compute a weighted average of the responses as [ v*(51%) + w*(67%) + x*(75%) + y*(85%) + z*(90%) ] / n.

As it stands right now with n=19 votes on that poll, we would compute the weighted average as
[ 1*(51%) + 3*(67%) + 7*(75%) + 6*(85%) + 2*(90%) ] / 19 = 77.2% (closest to 75%)
image

Not hypercritical, I’m just lazy and don’t want to do more work if I can’t avoid it :stuck_out_tongue:

I’m good with TWA. Just need more votes on this. Will surface on CC.

1 Like

Maybe it should be ranked choice? Either we get a solid consensus or the measure get’s put back up with the top two and get’s voted upon again? This is kinda one of the big pushes of the Forward Party because it helps fix that issue.
Thoughts?

Oh sweet, yeah, I mean if it went to a “runoff” like that, the second round could just be a repeat vote on the points, but they would only include the top two, yeah? I like ranked choice. I like quadratic voting even more, in the sense of how Colorado did it. Gitcoin’s version is great for on chain where tokens are involved, but that’s not applicable here so much.

Voted wrong, can’t change my vote :frowning:
What I meant to do: For the forum vs snapshot percentages, I mixed the votes on mine. I was thinking if we had a high requirement for forums, it might mean that all the discussion is able to happen at that time, all the learning and compromise. Then since it has passed a high hurdle there, where it isn’t token dependent, it would be less important to have a super high limit on the snapshot %.
So Discourse/forum highest, Snapshot more flexible. Prevents something being snuck in with a loose margin to snapshot where it could then be overwhelmed by an external potentially bad actor who scooped up a large bag to push a vote through.

agreed, there is only a minimal amount of educational outreach on these types of projects and it’s not enough.

Hey @frogmonkee, thank you for tackling this difficult task. I also highly agree with having more education / Q&A sessions going on especially for larger proposals.

Something I could imagine would help some people (including me) to participate more regularly would be automated reminders about educational sessions and proposal deadlines, possibly subscription to proposals you want to follow so users get notified when it moves to snapshot, or alerts when new proposals are posted (possibly through DEGEN?).

Also a concise overview would be nice. I know there is an overview of all active proposals on discourse but it is not very nice as you see only a title and then you have to click through the list of items to read up on the details. I would find it beneficial to have a place e.g. on the bDAO website where you can get a quick digest, like an abstract along with easy access to schedule education session / watching the recording, and links to discourse and other resources should you want to read up on the details or go for vote.

And lastly, just a thought to throw in here: I was wondering if there has been a discussion around something like conviction voting. It is used on polkadot and works something like this: If a user is strongly opinionated about a certain proposal but does not have the voting power to make a significant impact, he/she can boost their voting power by locking their tokens. Longer lock means higher boost. It is my understanding that this can be used to counteract whales pushing a proposal. Not sure though if this is needed since we have the forum approval first.