We at cLabs have been noticing that the baseline participation level required to pass governance proposals has been increasing rather quickly and rallying the requisite votes is becoming a barrier to upgrading the protocol. There are a couple parameters that can be tweaked to address this. The baselineQuorumFactor is the proportion of the historical average participation level that constitutes quorum. This is currently set to 1, which is the highest possible level and decreasing it would have the benefit of immediately reducing the quorum and alleviating the barrier to upgrades. We’ll probably want to reduce this value as it is currently quite high and passing proposals has already become challenging. An additional option is the baselineUpdateFactor — the weight of the most recent proposal on the historical participation average. Reducing the baselineUpdateFactor would decrease the rate at which the baseline quorum increases going forward but would not decrease the current baseline. It’s difficult to anticipate how fast participation levels will increase in the future, so it may be too early to know whether an update to this variable is appropriate, but we’d love to get the community’s input on this.
Yeah I for one would support lowering the baselineQuorumFactor, a value of 1 is super strict in that any gap between participation in a particular proposal vs the rolling average will be treated as “NO” votes.
To exacerbate this even further, I believe participation is treated as a % rather than an absolute number. So as more CELO gets locked the difficulty of passing proposals will continue to grow.
I’d love to see some of these mechanisms be revisited in a Governance 2.1.0.0, but in the meantime I think lowering the baselineQuorumFactor would be an appropriate measure.
I think starting at 1 with the quorum factor at launch was a good idea, but personally, I think on the spectrum of protecting the network by requiring high participation to making changes easy, we are probably a bit too conservative.
I think the existing mechanism of a MultiSig of governance approvers, longer governance periods and sufficiently enough interested governance participants lead me to support a decrease in the participation requirements.
So if baselineQuorumFactor == 1 that means baseline must continue to grow until some proposal actually fails to cross the participation threshold and fails to pass. If that is indeed the case, that does seem problematic, so reducing it makes sense.
With current formula and current baselineUpdateFactor of 0.2, minimum new baseline after a passing participation is:
baseline * (0.8 + 0.2 * baselineQuorumFactor)
So if:
baselineQuorumFactor = 1 -> baseline can not decrease after a passing proposal
baselineQuorumFactor = 0.9 -> baseline can only decrease by ~2%
baselineQuorumFactor = 0.8 -> baseline can only decrease by ~4%
My vote would go for baselineQuorumFactor = 0.8, since decreasing it by 4% doesn’t seem too problematic and should make it easier to cross passing thresholds.
Also, if in addition to this, we wanted to reduce the current baseline, we could create a dummy proposal and ask everyone to not vote on it at all. Even if some people end up voting on it anyways, as long as it doesn’t pickup significant number of votes, it can still reduce current baseline by ~20%.
Based on my observations rallying up CELO owners to vote a decrease by ~4% would have little impact. Amount of work would be about the same since some vote with a lot of CELO. With this in mind I’d recommend reducing the baselineQuorumFactor = 0.5.
with baselineQuorumFactor of 0.8 the passing requirement will immediately decrease by 20%.
What I meant in my post is that, new baseline can only decrease by up to 4% at most with passing proposals when baselineQuorumFactor is 0.8. So we don’t see continued drop off of the baseline in addition to the initial drop due to the new QuorumFactor.
Yeah I thought about this too, but it feels like a hack that would not last for very long.
I’m not sure I understand the concern with the baseline dropping? It seems like that’s actually a goal here, since the current participation baseline doesn’t feel sustainable without additional governance tooling or incentives.
On another note, we might want to also include in this proposal extending the referendum time from 5 to 7 days.
Rationale: was speaking to some of the voters and it seems that organizations have set processes on how and when they perform operational tasks such as voting. For some this is one day of the week (e.g. Wednesday), which means, with current schedule of referendums Thursday (or Fridays) to Mondays (or Tuesdays) they may not be able to vote.
An update on timing: We’re planning to submit this proposal at the same time as an upcoming proposal related to consumer incentives in order to reduce voter fatigue and operational overhead. We are currently blocked on knowing exactly when that proposal will be ready but should be able to give an update on that within the next few days.