Pgov Minimum Proposal Criteria

bZx Improvement Proposals
#1

In light of the sneaky little proposal that was posted for pgov, without any forum post prior to this, it highlights the need to set in stone some absolute minimum requirements to be deemed valid…

So… up for discussion and further ideas, but from reading in chat and my own thoughts,I propose the absolute minimum criteria for any proposal anywhere to be deemed a valid proposal.

A forum post must be created prior to any proposal, and be open for a minimum of 4 days before the proposal can even be open for voting/

A further 4 days minimum voting time, for votes to be allowed to come in, further discussion.

There maybe more ideas forthcoming but i thought id start us off with that and see how discussion goes :slight_smile:

Personally on the last vote, I voted no, simply because of the way it was handled

1 Like
#2

I share your concerns, but imho making rules to solve potential problems should be a last resort, not a first.

Preferably we should maintain the flexibility to make changes in a (very) short time frame, and if there’s any obvious abuse, I’m sure the team won’t execute it.

And if it needs some programming, we still have time to propose a cancelling vote.

#3

The basic rules already exist on other DAOs so if they are not already defined for BZX, it makes sense to formalize them now.

I suggest the following:

  • Having a “non-binding” proposal type to gauge community sentiment before an actual vote (so the sneaky proposal is fine if it can be considered non-binding)
  • A minimum quorum for voting, not sure if this is already in place (e.g. at least 30% of circulating supply must vote before a proposal is accepted)

I agree that there should be flexibility to make quick changes, a rule can be drawn up to cover this

#4

In general the guidelines we have started following for snapshot proposals are:

  1. Proposals should first be posted and discussed at forum.bzx.network.
  2. After sufficient discussion of the proposal and it’s possible alternatives, which is a subjective criteria, it can be proposed in snapshot by a 0.5% or larger holder.
  3. Proposals should run for a minimum of three days. These minimum thresholds are common across the defi space.

There isn’t an already developed way to enforce the 3 day rule in snapshot, but I will investigate building this in. I do see a way to enforce a quorum, so this is something we can discuss adding (ex. at least 30% of circulating supply must vote before a proposal is accepted).

#5

I like needing a quorum of at least 30% for a vote to be valid, and I also agree with the minimum time requirements so far suggested. I would suggest we also have a possibility to pass an “emergency” vote. I can’t think of anything specifically, but there may come a time in the future where a 3 day discussion period and a 3 day vote period is too long to make a change. Maybe with Dev approval an “emergency” vote of 2 days discussion/notification and 1 day voting would be considered valid in extreme circumstances.

#6

I would say reduce the quorom as 30% may be too high but a quorom will definitely be needed to ensure validity for a proposal and potentially an introduction of a super-majority situation for major protocol changes (major changes would have to be defined in a rigid manner of course)

#7

Drypto, I would only argue that anything less than 30% represents a danger of centralization by whales. That danger always exists, but at 30% they at least need 16% coordination to win a vote.

#8

the problem I fear with 30% for a quorum is that votes may not pass due to the token holders not paying attention. Like the last vote that occurred for polygon only had roughly 22% of tokens used for voting. As there is an introduction of CEXes and other tokens lock-up sources, it becomes even harder to reach quorums that are high. A better solution is to require > 50% to pass a vote with a lower quorum.
EDIT: > 50% as in, requiring 60% voting in favor for it to pass or a number greater than just a simple majority.

#9

The team already holds 20% so 30% isn’t that difficult to reach if you have their participation, which I believe won’t be a problem for now. We could later change it, though.

For emergencies, the team still holds the admin keys so it can be paused instantly with a vote later on to justify it.

In the future we could directly start a vote when there’s an emergency and have a fast emergency vote and a normal emergency vote.

The fast vote executes as soon as a certain (lower) threshold has reached, that will pause the platform immediately for 12 or 24 hours. This pause can only happen once a week (to avoid abuse) but can be reset again after a normal vote has passed.

In the meantime, a normal emergency vote can be held to vote on a longer pause and additional actions that might be required.

If this is even programmable, is this something we would want, or does anyone have more ideas?