Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ARC-34 Update Threshold #233

Conversation

ShaperOfEntropy
Copy link
Contributor

With the current calculation of the threshold for whether a proposal gathered sufficient number of votes to be approved, it is possible that a large portion of funds end up undistributed if any voters forget to cast their votes since their votes still count towards the total. Moreover, voters that did not vote become ineligible in the xGov program but their Algo remains in the Term Pool. Therefore, only the part of the votes that belong to xGovs still eligible at the end of the voting period should count towards the threshold (similarly as is with regular Governance and the cool down period).

With the current calculation of the threshold for whether a proposal gathered sufficient number of votes to be approved, it is possible that a large portion of funds end up undistributed if any voters forget to cast their votes since their votes still count towards the total.
Moreover, voters that did not vote become ineligible in the xGov program but their Algo remains in the Term Pool.
Therefore, only the part of the votes that belong to xGovs still eligible at the end of the voting period should count towards the threshold (similarly as is with regular Governance and the cool down period).
@SudoWeezy
Copy link
Collaborator

We cannot change anything for the current period.
However, we have two options available for the next ones, and it should be discussed with the community:

  • we follow your proposal and move the requested amount base on the number of voters.
  • we could take the bet that the next session will be more efficient and will not have a massive gap between participants & voters and not try to solve this with maths (people who register for xGov will be more careful to spend their votes & proposals will be more thoughtfully created)

@ShaperOfEntropy
Copy link
Contributor Author

Theoretically, you could redo the threshold recaluclation off-chain and distribute project funds based on that already for this period. Nothing would change to the voting as it is still recorded by the smart contract. It would just aid the program as a whole and I think community would support such a change even during the period, especially as I do not see any downside to it.

we could take the bet that the next session will be more efficient and will not have a massive gap between participants & voters and not try to solve this with maths (people who register for xGov will be more careful to spend their votes & proposals will be more thoughtfully created)

If this problem is left unsolved, there will always be the possibility that some funds end up blocked, which would be inefficient, especially since the solution is a very simple one.
The problem with the approach that we hope the situation will improve with the next session is also the fact that the unspent votes in this session will continue blocking funds for the next 3 sessions.

@SudoWeezy SudoWeezy closed this Oct 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants