UIP8 - Defining a voting quorum for the Escher system

[maaatttt]

Simple Summary

Defining a quorum for Ubiq Improvement Proposals.

In order to avoid a situation wherein a UIP is passed when voted upon by only a small portion of the total existing Escher, a specific percentage should be required in order for a proposals voting outcome to be considered valid.

Motivation

The Escher governance system relies upon the total Escher held at the addresses that have voted instead of raw total number of votes. Therefore, it should determined by the community what percentage of existing Escher will constitute a quorum. Having a minimum viable weight behind any winning candidate will add clarity and legitimacy to the voting process.

Perhaps a single, simple percentage to handle all proposals is the preferred route. Perhaps the community at large feels that it there should be a higher burden for proposals that relate to core protocol changes, and other lower tiers to handle proposals of less gravity such as community held funds or project naming schemes or graphics.

Implementation

• If this proposal (UIP8) is passed in the affirmative, all successive Ubiq Improvement Proposals will be subject to the definition of what constitutes a quorum, here determined by the winning candidate.

• If this proposal is passed in the affirmative, it (UIP8) must adhere to its own strictures by having a weight equal to or greater than that which is detailed in the winning candidate of this proposal (UIP8); If passed in the affirmative without reaching the quorum defined by the passing candidate, the proposal (UIP8) will be considered invalid.

• The quorum is defined as a percentage of all existing Escher. No single candidate is required to reach the quorum threshold for a proposal to pass, unless they receive 100% of voting weight.

• Regarding a Tiered Quorum - A proposal is related to "core protocols" and subject to the higher quorum tier when it creates a fundamental change to the nature of Ubiq the ecosystem. Examples include but are not limited to; Changes to the block reward reduction schedule, the Proof of Work hashing algorithm, the consensus system (PoW v PoS), changes to the functions of the Escher governance system, et al.

Examples:

• (Assuming 20% quorum) UIP is voted upon. Escher weight of all candidates combined = 23% of all existing Escher. Valid Quorum, Resulting winner is implemented.
• (Assuming 20% quorum) UIP is voted upon. Escher weight of all candidates combined = 17% of all existing Escher. Invalid Quorum. Resulting winner is not implemented.

Candidates

1. Simple Quorum - All proposals will be considered valid and allowed to pass only if 10% or more of total existing Escher vote for passage.

2. Simple Quorum - All proposals will be considered valid and allowed to pass only if 15% or more of total existing Escher vote for passage.

3. Simple Quorum - All proposals will be considered valid and allowed to pass only if 20% or more of total existing Escher vote for passage.

4. Tiered Quorum - Any proposal which does not relate to core protocol changes will be considered valid and allowed to pass only if 10% or more of total existing Escher vote for passage. Any proposal that does relate to core protocol changes will be considered valid and allowed to pass only if 20% or more of total existing Escher vote for passage.

5. Tiered Quorum - Any proposal which does not relate to core protocol changes will be considered valid and allowed to pass only if 15% or more of total existing Escher vote for passage. Any proposal that does relate to core protocol changes will be considered valid and allowed to pass only if 25% or more of total existing Escher vote for passage.

6. Tiered Quorum - Any proposal which does not relate to core protocol changes will be considered valid and allowed to pass only if 20% or more of total existing Escher vote for passage. Any proposal that does relate to core protocol changes will be considered valid and allowed to pass only if 30% or more of total existing Escher vote for passage.

7. No Quorum - All proposals pass or fail without regard for the proposal voting weight relative to total existing Escher.

8. Abstain - Non-support for any proposed candidate. Voting weight from Abstain votes does qualify as participation and does contribute toward any potential quorum requirement should UIP8 succeed.

References

The total supply of Escher is 450454965.391453439756557953 ESCH

About the Escher system

About Quorums

[weifageo]

Thanks for putting together this UIP @maaatttt. I think this could be very helpful moving forward as I remember this being a point of uncertainty during my previous proposal.

Here are some of the participation metrics from the previous UIPs for reference.
UIP #1: 33.3542%
UIP #2: 19.4104%
UIP #4: 12.3767%
UIP #6: 23.9715%
UIP #7: 15.3425%

[Nickardo]

A good Samaritan abstains when (s)he does not understand the proposal or care about its outcome. I am not a good Samaritan and abstained from voting itself last UIP.

I think there’s a relatively high barrier of entry to vote and this should be taken into account. At the same time, with a quorum in place, I would feel more enticed to vote abstain if only for the sake of progress.

My ideal candidate would be tiered, but on different metrics than those suggested.

In broad lines:

• All proposals to be subject to a quorum
• Operational decisions subject to a low quorum
• A monetary/resources threshold for operational decisions which, if triggered, raises the quorum substantially
• A high quorum for protocol decisions

Operational decisions subject to a low quorum
Operational decisions encompass all proposals not related to the protocol’s fundamentals.
For the monetary/resources threshold I would suggest using a percentage of total funds/resources available.

A high quorum for protocol decisions
Ubiq is enterprise oriented and derives its value from being stable. I feel any fundamental changes to its protocol ought to have a firm mandate. Ie; change to block reward, consensus algorithm, deviating from conservative upgrade schedule

Clawback
Decisions have to be made to move forward, setting the quorum too high might grind Ubiq to a halt. Perhaps some form of clawback clause should be included for when, for a prolonged period of time, the quorum has not been met.

I refrained from naming numbers because I consider those to be separate from the structure of the quorum itself.

[maaatttt]

@weifageo Thanks for the participation details. Looks like the average participation is around 21%. At the moment my opinion is that the minimum viable vote weight should be below the current average participation percentage.

@Nickardo Thanks very much for the feedback. Could you explain the monetary / resources threshold suggestion further please?

In the meantime, I am going to make edits to the issue in order to include the following;

• Add language that makes it clear that all proposals are subject to a quorum.

• Add language that makes it clear that the threshold percentage relates to vote weight cast relative to all existing Escher and that no single candidate is required to reach the quorum threshold for a proposal to pass, unless they receive 100% of voting weight. Highlighted with an example.

• Add language that makes it clear that a vote for the Abstain candidate, while signalling not to support one of the decisions, does count as a participating vote and contributes it's voting weight to reaching the quorum.

• Add language that adds emphasis on the need for higher percentage weight regarding any protocol changes.

• Adding a third Tiered Quorum candidate for uniformity and added options.

--- Regarding a Clawback feature ---

Any suggestions as to how this could be defined are welcome, but perhaps this may be of enough substance to warrant its own UIP?

Here is my shoot-from-the-hip idea for a Clawback protocol;

"Any UIP failing to reach quorum may be immediately resubmitted for vote no more than twice. Any resubmitted UIP must reference the failed proposal number(s) for any successive retry. Assuming a second failure to reach the standard and a third submission for a vote, a quorum will be defined as having at least equal voting weight as the failed proposal with the highest weight and the winning candidate must have at least 80% of the weight of votes cast in the clawback round"

[weifageo]

Just catching up again on the feedback, if we can't figure out all the details for a potential Clawback feature, we can always discuss and vote on that in a future UIP. Having more proposals could help generate more engagement of the Escher system, so we don't need to pack too much into UIP8.

Just looking over the candidate options again, one suggestion I have is to adjust the simple tiers to match the lower end of the Tiered Quorum options (ie. 10%, 15%, 20%) as to date we've only ever had > 30% on our first UIP. I agree we want to offer a clear understanding for what is considered a quorum, but I'm hesitant to set anything too high based on previous participation rates.

Just my thoughts, I'm curious to hear what others think!

[j40j]

@Nickardo I really appreciate your additions here. I’m in support of a quorum being written into the proposed UIPs. I also support the idea of a tiered Quorum. 10% total Escher supply minimum for a UIP to even be valid should be the base IMO. After I do agree with establishing a tiered system.

[maaatttt]

@weifageo

Just catching up again on the feedback, if we can't figure out all the details for a potential Clawback feature, we can always discuss and vote on that in a future UIP. Having more proposals could help generate more engagement of the Escher system, so we don't need to pack too much into UIP8.

I don't have any issue with spinning off the Clawback idea into a separate proposal. Might make it easier to reference later if we keep topics a little isolated like that.

Just looking over the candidate options again, one suggestion I have is to adjust the simple tiers to match the lower end of the Tiered Quorum options (ie. 10%, 15%, 20%) as to date we've only ever had > 30% on our first UIP. I agree we want to offer a clear understanding for what is considered a quorum, but I'm hesitant to set anything too high based on previous participation rates.

I like the idea about setting the percentages for the Simple candidates to match the lower bar of the tiered candidates at 10%,15%,20%.

---

Circling back to @Nickardo suggestion...

A high quorum for protocol decisions
Ubiq is enterprise oriented and derives its value from being stable. I feel any fundamental changes to its protocol ought to have a firm mandate. Ie; change to block reward, consensus algorithm, deviating from conservative upgrade schedule

We should include this in the UIP itself. It's important for it to be obvious what type of alterations would constitute a protocol change. It might be obvious to people involved in the drafting that kind of thing but there should be as little ambiguity as possible.

I will add the following, and we can change it later if need be.

"A proposal is related to "core protocols" and subject to the higher quorum tier when it creates a fundamental change to the nature of Ubiq the ecosystem. Examples include but are not limited to; Changes to the block reward reduction schedule, the Proof of Work hashing algorithm, the consensus system (PoW v PoS), changes to the functions of the Escher governance system, et al."

That might still be too hazy but I think it shows the direction we should be taking it imo.

[Nickardo]

@maaatttt

Apologies for the delayed response.

Could you explain the monetary / resources threshold suggestion further please?

I have to reconsider my phrasing, I don’t think ‘resources’ is a proper definition for what I want to say.

It would apply to all funds managed by the community/ESCH holders. Perhaps in the form of both a percentage and minimum nominal amount.

My thinking on this is twofold. Regardless of the funds available, committing a sizeable percentage of it to one cause has an impact on Ubiq’s future.

But, mostly I see it as an additional form of spam/abuse protection. Taking Decred as an example, some of their rejected proposals were asking for >$100k. Of course Decred’s warchest is quite more sizeable than Ubiq's, for now. In the case of big appreciation of fund value some might be inclined to try and claim it for a fake cause. ie wait for an opportune moment - acquire the required amount of ESCH - fabricate a UIP.

A higher threshold would make it more difficult and require an attacker to make many smaller proposals to have the same reward, which takes more effort and increases visibility of the attack. An even safer approach would be to also prevent smaller proposals as an attack vector by choosing for a single - high percentage - tier, but then we come back to a too high threshold grinding Ubiq to a halt given recent voter turnout.

Example (arbitrary numbers):

Fund balance: 1MM

Case 1: 

Simple quorum of X% applied to all spending decisions.

1 UIP could potentially drain the entire fund.

Case 2:

Quorum of X% applied to spending decisions lower than $5K and/or not more than 2% of total funds ($20K).
Quorum of X+Y% applied to spending decisions above that amount.

Either 200 or 50 UIP's would be required to drain all funds.
Assuming acquiring X+Y% is either too expensive to be viable or impossible due to solid distribution of ESCH.

Of course another assumption here is that the de facto owner of the keys to the funds adheres to the government policies as set herein and does not deviate under any circumstance from decisions made. Which I am in favour of, ESCH decides.

I am unsure about the optimal balance.

As a reference; Decred has built in a block reward that goes to their development fund. Holders of Decred can buy tickets which count as votes within their governance model. Decred is on route to even decentralise management of the fund itself, after which community approved payments will be made without any intermediary.

[ghost]

1. make it simple alias threshold to get more eyes to see it (and one whale cant tip it in favor), i say 20%+ lower bound.
2. clawback unused ESCH if not used for 1year+, comparsion: it is your f** duty to go to the polls otherwise the democratic model is broken. witholding is NOT a vote, but a rejection of the system itself (if you want to tdo that, COME ON, show us you got better idea by making a proposl ;). The clawed ESCH should be airdropped to active adresses on the network be a metric of our choice, eg tx sent in the last year, or uips voted on etc.
   FIN

[maaatttt]

@Nickardo

Thanks for your clarification! I think you bring up a very good point. I think it may be a good idea to keep the quorum's as simple as possible, but it may also be a good idea to implement a type of check-pointing regimen when there is a certain percentage of community managed funds at stake, as you mentioned.

Maybe a proposal that passes the quorum that aims to make use of X% of total funds could be required to pass through multiple UIP's to unlock the total funding in tranches that on their own would not be as excessive. It would give voters multiple opportunities to stall / revoke approval for remaining funds should a projects development not meet expectations or halt outright.

ie; The initial vote would signal approval for the idea / release monies to begin development / schedule the next tranche vote with specific requirements / time frames. Each followup vote could detail requirements for the next until the project is completed and funds have been fully distributed

While I think this could prove to be an important detail, I wonder if it starts to go beyond the intent of this particular UIP similar to the Clawback idea. It could be efficient for the community to draft a number of UIP's that follow the hypothetical passage of "UIP8" that address these various "related-but-distinct" ideas.

I would be happy to hear opinions as to whether or not people think this mechanism belongs in UIP8 or on it's own.

[maaatttt]

A new consideration has come up recently that will have an effect on the quorum discussion.

With the imminent release of Ubiq's onchain uniswap-based exchange, the ESCH token will inevitably become an easily trade-able asset. Naturally this will result in some ESCH holders depositing their tokens into liquidity pool contracts to maintain the market pairs. As a result we would see a fluctuating amount of voting weight come under control of this non-custodial system.

It's my opinion that "UIP8" should include clarification regarding the status of ESCH voting weigh held within these pools and the eligibility regarding votes / quorum.

Here are some thoughts to consider:

• Should the quorum % be based on the static total number of ESCH in existence, regardless of how much is being held as trading liquidity?

• Should the quorum % be based on the total ESCH that remains outside of liquidity pools at the block a vote ends?

• Should there be any restrictions on the movement of ESCH into and out from liquidity pools during a specific time frame surrounding a vote to be considered valid / part of the quorum?

• Should ESCH liquidity providers have the ability to use ESCH-LP Tokens as a proxy that permits their pooled ESCH to count as valid vote weight and therefore qualify for quorum ?

A few opinions:

I think that the scenario that seems appropriate to me at this time is that quorum should be the total number of ESCH in existence regardless of the % that is functioning as trading liquidity, and that there should be no time restrictions imposed on the movement of ESCH as long as the balance is present & confirmed (not pending) at the block a vote ends. I think that if there is a safe way to allow ESCH-LP Tokens to serve as a proxy since they prove ownership of ESCH, that it might be a good thing to consider so as to not penalize liquidity providers who are contributing to the overall functioning of the system.

I'm sure there are plenty of other possibilities to consider that I have not yet considered. Interested to hear suggestions.

[Bullchad123]

If its technically possible I'd prefer ESCH-SLPT tokens to be used as a proxy. This would avoid severe changes in liquidity on Shinobi around the time of voting. Otherwise this system could be manipulated and draw attention from the voting process.

[Bullchad123]

I'm also not in favour of clawing back / burning unused ESCH. I think this could be problematic, for instance if someone had to leave the community for a while due to health reasons and we burn all their ESCH. I'd be pretty pissed.

Now ESCH has a value there is an incentive to simply dump unwanted tokens, which will be bought up by people invested in the network, increasing the chances of them being used.

I also think the voting system should be kept as simple as possible so as not to cause confusion.

[maaatttt]

I'm also not in favour of clawing back / burning unused ESCH. I think this could be problematic, for instance if someone had to leave the community for a while due to health reasons and we burn all their ESCH. I'd be pretty pissed.

I agree with you. Perhaps I misunderstood initially what was being referred to as Clawback to mean a method for resolving a stalemate after multiple attempt to pass a proposal for the same issue. If the idea is meant as the desire to take away ESCH from an owner, I could not be more against that ( not to mention it is not a feasible thing to suggest ).

If its technically possible I'd prefer ESCH-SLPT tokens to be used as a proxy. This would avoid severe changes in liquidity on Shinobi around the time of voting. Otherwise this system could be manipulated and draw attention from the voting process.

If this is something that warrants more consideration we need to consider that, as you know, once ESCH is included in a liquidity pool the LP tokens one receives represents a % of the pool and not a defined # of ESCH any longer. That makes calculating vote weight an issue. Worth thinking about.

[JEDC07]

How's this topic going ?