Bad voting UX due to delegate issue

[tomhirst]

The voter registration requirement causes bad UX when a user tries to vote on a proposal:

1. Proposal is active in the system that a user wants to vote on
2. They can only vote with the vote balance they had at the proposal's start block (all good)
3. The user's vote balance doesn't qualify unless they have first registered to vote (delegated to themselves) at the proposal start block (meaning that they can't vote - bad)

We should consider making the contract level changes as I can't see a UI feature fixing this alone. For instance: We enforce vote registration in an app-wide pop-up as a primary action, yet there still may be existing proposals that first-time voters want to participate in.

Ref: #312

[Techmoen]

Could you please expand on point # 3? Would this mean that, unless a user registers, their veOGV balance will not count towards the overall veOGV for voting? ie. is total votes available based on total veOGV (9,757,561,776) or veOGV registered to vote (considerably less) when determining % for quorum?

[micahalcorn]

Could you please expand on point # 3? Would this mean that, unless a user registers, their veOGV balance will not count towards the overall veOGV for voting? ie. is total votes available based on total veOGV (9,757,561,776) or veOGV registered to vote (considerably less) when determining % for quorum?

Good question 🤔 @tomhirst?

[tomhirst]

Could you please expand on point # 3? Would this mean that, unless a user registers, their veOGV balance will not count towards the overall veOGV for voting? ie. is total votes available based on total veOGV (9,757,561,776) or veOGV registered to vote (considerably less) when determining % for quorum?

A user having not registered prior to a proposal being made means that they won't be able to use the veOGV they see in their balance to vote on the proposal.

I'm pretty sure that quorum is decided by total supply of veOGV, not the total supply of veOGV belonging to pre-registered voters. Reasoning:

Taking the latest proposal on our Rinkeby staging environment as an example: https://ousd-governance-rinkeby.herokuapp.com/proposals/69231780417556611847051253435734797850494369432476032994988544425636331066890 The figure required for quorum is 71.03 million and the total supply of veOGV is listed as 1.78 billion. 71.03 million divided by 1.78 billion = 0.0399 and 0.0399 * 100 = 0.39, ~4% - which is the GovernorVotesQuorumFraction we set on contract deploy: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/affe2456ea2aee96ea2af031b6e5ad07d77f1873/contracts/governance/extensions/GovernorVotesQuorumFraction.sol#L31

So my interpretation is that unregistered veOGV still contributes towards the total supply used to calculate quorum. The contract takes the total supply of veOGV at the time of proposal creation and requires 4% of it (on staging only, this will be 20% in prod, ref: #295 (comment)). You can see a comment here that supports this, too: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/24fc709533faffffed9cf7a0ab89c3ddeb8aed3f/contracts/governance/extensions/GovernorVotesQuorumFraction.sol#L12

This does raise a good question, however. If < 20% of veOGV is held by unregistered users - early proposals will be unable to pass.