Let me explain better the rationale behind the Global Quorum in this scenario: let’s suppose a small minority of the current xGovs shows up at the voting (for example 20%). I don’t think it’s a good idea to let them decide the distribution of the whole 2M funds, I’d rather declare the voting session invalid and wait for the next voting session, where a new wave of xGov will become eligible, therefore increasing the probability of reaching a higher percentage of participation in the next voting session. This notion of Quorum is exactly the same as what exists in referendum, which is the most important tool of Direct Democracy (see here).
1 Like
I dont get it, so if every xGov governor will vote, the quorum will be 100%?
What if there is situation that there 50 projects requesting funds, lets say 200k, the total distribution is 2M, and each project will receive from more or less 20k-50k votes. So no project will be approved, even the one that gets the most votes?
In my algorithm everyone is sorted by the popularity of the proposal, and the top projects are funded. Also note, that i do not sort just the reserve list. I sort all, and its simple math proof that the projects you call winners are at the top of the list. (For example if you do not enable the non voting for approved proposal, or if you allow hidden voting, this algorithm is not broken)
If you are worried that only 30% of xGovs will decide whole xGov budget you should probably do more marketing and easy the decision making. The slashing of the rewards is already quite strict so people will learn. Did you find out who are those 3 accounts holding 40% of xGov votes? Perhaps the best thing is to speak to them directly and find out why they did not vote.
1 Like
@scholtz I don’t understand your question: the Global Quorum simply says that if only 40% of the xGov (by stake) votes, the voting session is not valid. As per your second question: if they get only 10% of the votes (20k/200k) I am not happy about distributing the funds to them, there must be a threshold. Regarding your last observation: we are already pushing for more education in Voting and we know that the biggest xGov didn’t vote for technical reasons and now they can vote: here you can find their action of updating the controller address: here
1 Like
Ofc we look at extreme cases here but in general it shouldnt be about just giving away those ALGOs from the xGov fund each period when those projects arent able to convince enough xGovs. So if someone only got 2.5% of the votes and needed 10% why should they get the money? they clearly werent able to get enough votes and it cant be always the xgovs fault
i am in favor of 50% needed
Hi, I just wanted to summarize the decisions we made together with the Community in this Twitter Space with @StephaneBarroso & @Adri here.
- Two Quorums: 1 Global (for the Voting Session) = 50% and 1 Project (for every Proposal) = 50%. (modified from 33% as initially proposed)
- Switch from
Voting Power Needed = (Amount Requested) / (Amount Available) * (Total Number Of Algo In Term Pools)
to the following:
Voting Power Needed = (Amount Requested) / (Amount Available) * (Total Number Of Algo who Voted )
- Create a list of Winners and a Reserve List. (see above for a detailed description)
- During the next session we are not going to limit the number of proposals but we are setting a Minimum Requested Amount = 1000Algo.
Thanks to all the participants, looking forward to share with you the next updates!
.
1 Like
if quorum isn’t met, what happens to the governance rewards? or people who don’t vote, does it lose their funds?
I dont know, but this is against the ethos of distributing the allocated algos.
If will repeat my example from the above, and i think it is quite realistic.
If there is 50 proposals requesting 200k algos, and there is budget only 2M algos, when xGovs will distribute their allocations kind of equally to each projects, NONE of the project will get funded with the requirement of 50% votes.
What about the project quorum to be (Sum of algos for distribution / Sum of all requests) / 2 … So in my example it would be 2000/10000/2 = 10% . If the sum of algos requested would be 2M and granted 2M, it would be 50% (so that if not all xgovs participate, it will be possible to accept it)
I am in favor of global quorum. The first session had 30% of votes, and active voters will have their voting power trippled. And those whales who did not vote did learn that they have to vote. So in the next voting session I assume something like 90% of votes to be casted.
Also did not record any response from you regarding incentivizing xGovs by doing the reviews.
@Adri I just noticed the twitter space where you discussed this. https://twitter.com/i/spaces/1YqKDgzpvwQxV Is there some public calendar of such events? Btw i dont think the governance should be done on likes on twitter space, but through onchain voting. You know i will be happy to help with the vote coin project any time
If Global quorum is not met xGov who voted still have their Algos while those who didn’t vote are removed from the xGov Pool, exactly like it happens now. The only additional effect is that the vote session is declared invalid and no Fund distribution happens, until the next Voting Session.
The ethos is not distributing algos in any case just because some projects did their proposals, the ethos is to distribute algos to projects who received sufficient support by the xGovs. I reiterate that receiving 10% of the needed support is a poor performance and I think we shouldn’t support them just because they presented a project. I am sorry that you missed the Twitter Space and I would have loved to discuss live with you these topics, but we have a deadline for implementing the improvements, going through an onchain voting also for this is definitely unfeasible and could lead to an infinite regression (an onchain voting for deciding what is the improvement to be voted, and so on…).
Still i think you overestimate that there may be many requests for funding exceeding for example 100x of amounts to be distributed, and in that case no project will get funded by your formulas.
For example on cardano just finished the 10th round of grants and they distributed 50 mil ADA (~12M USD value) and total requests was 316M. https://projectcatalyst.io/fund10-voting-results.pdf
If algorand would get community engagement same as cardano, and would still distribute 2M algos ~= $200k, the ratio between proposals and money would be 12000000/200000 = 60. In that case no projects would be approved, only those where big whales put a lot of money to xGovs and fund their own projects.
you are working on the assumption that each of those proposals would get significant votes which is not given imo
I believe reserve list implementation as mentioned on the latest twitter space warrants bit more discussion before including it in the xgov.
Reserve list goal: to allow Good! proposals that almost “passed” to get funded if there is leftover algos
Current implementation as per twitter space: Proposals that didnt pass but got more than 50% asked votes get ordered by % filled and tehn approved untill there is algos left. (% votes filled, e.g. missing only few votes to pass, would put proposal to 99.9%)
Issue:
this approach allows for proposals that asked for small sums of algos(low impact proposals) to pass without actually getting the % of confidence from voters.
Extreme Example:
Poposal A asks for 1k algo and gets 900Algo, its at 90% filled status,gets put on reserve list and as its 90% filled-top of the list it gets funded. This proposal DIDNT CONVINCE literaly any xgovs, but it still gets passed at high priority - not ok
proposal B asks for 100k algos, but gets only 80k algos filled(80% filled, would place lower than above 1k algo example alrhough it convinced significantly more xgovs).
solution: weighted order on the reserve list, weight(TBD) should take total % of votes received AND % filled into account when determining final score (0-100%).
Let’s take weight of 30% + 70% for starting point, and assume 2mil total votes.
(formula to determine 30% part would use total votes received, some constant with upper threshold etc…to make sense - e.g. Min(votes received/100k *30,30)
In this case proposal A would get final score (0.001% + 90*0.7) = 63%
and proposal B would get (24% + 80 * 0.7) = 80%
Both proposals would still qualify for reserve list, but the order woudl prioritize the proposal B, making sure that the proposals that convinced a lot of people(good proposals) actually get passed or atleast contend for passing, instead of being left behind tons of small algo requests(the reserve list as is encourages submitting multiple smaller proposals), that would drain the remaining algos.
hope this makes sense
1 Like
Hi, can you check the discussion above or give me comment on my proposals?
I have suggested
- At the end of the voting session the proposals are sorted by
votes/requested. Traverse from the top project down and decide on its allocation: If we have enough money to be allocated to it fund it, else move to next project. - project quorum to be (
Sum of algos for distribution/Sum of all requests) / 2 (so that we do not fund bad small projects) - allocate 5% to xgov rewards system. Allow xgovs do reviews of the proposals and give each xGov option to comment on any of them (or lets do limit max 30 paid reviews). Also some review of review should be introduced. Distribute the review rewards equally according to all valid reviews.
Comparison between xGovs and referendums (with the typical quorums therein) has little to no merit because the mechanisms are different as well as serve different purposes. Firstly, in a referendum, the whole electorate votes, while xGovs represent a (self-elected) subgroup of Algorand. Secondly, referendums are nowadays commonly used to decide on important societal issues and not distribution of (a relative small amount of) funds, i.e. budgeting. Thirdly, if an xGov does not vote, one forfeits one’s right to vote, i.e. falls out of the electorate permanently for that xGov term.
Moreover, it is contradictory to claim that a quorum is needed and that the decisions were:
where 235 people tuned in (who might not all even be xGovs) out of the +4k registered to be an xGov, the space was announced less than a day in advance, and voting was done as a show of emojis (which is not even recorded) instead of an on-chain vote by the actual xGovs. Regarding the response that an on-chain vote is unfeasible, it is the exact reason why xGov needs (and should have started with) a constitution, as already suggested.
To comment on the stance that the quorum raises the probability of reaching a higher percentage of participation:
Could you please elaborate on the justifications for this assumption?
Modeling this behavior is challenging, to say the least.
Once the program matures, it would be realistic to assume that the participation in each session by each term pool follows an identical distribution and that participation in two subsequent sessions are independent (as per the program’s design). Due to the cyclic nature of the term pools, the probability of reaching a certain percentage of participation would be identical for each session (assuming that the number of total xGov votes of new term pools remains constant), and thus also the probability of reaching the quorum.
To reiterate the main issue of introducing a global quorum as currently suggested: it opens the possibility for the to-be-ineligible majority of voters to block making decision of active xGovs, which is detrimental to the program that needs active xGovs.
Alternative to the global quorum
Lastly, to also offer an alternative solution to the main argument for the introduction of a quorum, i.e. that without it a small number of participants could decide on a large amount of funds.
Instead of introducing a relative quorum of the votes that need to be eligible at the end of a session for it to be considered valid, rather define what amount of total xGov funds of a session are the xGovs allowed to distribute depending on the amount of ALGO that remains eligible in that xGov session.
In other words, define what amount of ALGO is required to vote in order to allow spending of 1 ALGO; i.e. what number of votes is it consider representative to either approve or reject the spending of 1 ALGO.
For example, for xGovs to be allowed to distribute 2M ALGO, at least 100M ALGO need to vote in the xGov session.
If only 50M ALGO vote, the xGovs are allowed to distribute at most 1M ALGO. If only 10M ALGO turn to vote, the total spending is capped at 0.2M ALGO, etc.
The requirements for the funding of projects to be approved remains unchanged. It is just calculated at the end of the session according to the number of funds the xGovs are allowed to spend based on their participation.
The exact ratio could be defined each quarter in regular Governance when the top-up of xGov is decided (e.g. Would you approve topping of of xGov to 2M ALGO that can be distributed in full only if at least 100M ALGO vote in xGov? Otherwise, the topping up is limited proportionally to the number of ALGO that vote in xGov). This would allow to deal with increased number of votes entering the xGov program during its ramp-up as well as to reduce the requirement later on when Governance rewards start to diminish.
P.S.
It would be highly appreciated if you were to actually lead a discussion by addressing the points raised here, commenting on them and refuting them, instead of just explaining your views. That would be much more fruitful and the claim that the decisions were made together with the community would have more legitimacy.
Please also refrain from making citations out of context - as in the case of the space at 30:55 were you omitted the explanation for the view why a global quorum is not needed.
2 Likes
@Adri
Could you please explain what you meant when you said at 30:00 of the space that those xGovs of term pool 1 who voted in 1st session will have more voting power in 2nd session? Did you mean that they will have a relatively larger voting power because the xGovs who did not vote were disqualified (but that the their absolute number of votes will not change)?
Could you also please comment on what changes to the template requirements will be made besides the minimum and maximum requested amounts (if any)?
Will at least any guidelines be added to improve the quality of the proposals and simplify the work of xGovs to review them?
What we are proposing here is an improvement from the initial mechanism, which demonstrated to under allocate, therefore we would like to counterbalance this by creating a Reserve List. I potentially see an added value in your 30/70 weight proposal, but I honestly don’t know if we are overcomplicating: I don’t see this proliferation of 1k algo projects in the proposal and moreover the real question is: who is going to vote this clearly fake 1k proposals? If on the other side there is value, I am happy to fund interesting small projects. By not introducing the 30/70 weight we are saying to the projects: think twice about asking too much money because it’s going to be difficult, which I think it’s a legitimate message.
- I think separating the Winners List from the Reserve List it’s useful because winners have by construction the funds available (if the get x% of the votes there will be for sure x% of the funds) and the Reserve List is conditioned to having funds still to be distributed.
- I really don’t understand your proposal, the Project Quorum is needed to filter out projects, why we should link it to how much money they asked divided by 2??
- It’s not under discussion here, even if it could be a good idea, let’s make one step at time, also considering the time needed to implement the improvement proposal
@anon I will try to answer point by point to your observations and criticisms:
-
Once again: since the Voting Power will be calculated on how many xGovs will show up, it’s important that this number is robust and not driven by a small minority, that’s why the Global Quorum, your observations have little to no merit (as you say) because you don’t understand the mechanics: if 10% of xGovs show up is it good to let decide them for the whole 2M? Definitely No. You cited my passage but you clearly didn’t understand, because everything is explained there: with a new cohort of xGovs there is a higher probability of reaching the quorum in the next voting session, it’s simple mathematics: the survivors of the previous cohort (which have demonstrated to be good voters) now represent the entire Term Pool 1 and therefore, supposing the same percentage of participation (as you say) in the new cohort, the impact of this no-showers will be mathematically lower, because the total number is bigger and you have filtered out no-showers in the Term Pool 1.
-
We have to implement the improvement in a short time and we cannot afford a proper vote every time we have to change something, do you agree that in this way we could digress indefinitely to vote for everything (vote on the change, but then vote on the proposal to be proposed, and so on)? You complain that a decision has been made during a Twitter Space with “only” 235 participants: why didn’t you show up to contribute to the discussion? Do we have to send a Calendly to every of the 4k+ Governors to decide when the discussion will be?
Please let’s be practical, when you criticize you should also make a concrete proposal, we all know that this is just the second iteration of looong process! -
About Your proposal: first you criticize the Global Quorum and you see no value but then you introduce one, 100M: where does it come from? If you refer to the total number of Algos in xGov Pool (which is definitely not 100M Algo as you say, it was 2.139M in Voting Session 1), for me it’s totally equivalent to defining a Quorum, with the only difference that below you still distribute a fraction of the total: below your Quorum, if you think twice, this is exactly what happened in the last voting session, in which 33% appeared and they decided, due to the old voting mechanism, only on that 33% of the total funds. Since we are discussing how to move from the old voting mechanism, I don’t see a real added value in your proposal, but happy to hear others’ opinions on this. Anyway, if you think it’s a good idea, next time come to the Twitter Space and pitch your idea, with proper numbers and simulations, like other members have done.
I am happy to discuss every idea, but please let’s keep the aggressiveness outside the discussion and respect others’ ideas, even if you don’t agree.
Legit projects/requests will ask for exactly how much they need, asking for less just to get passed(or to be more competitive on reserve list) makes no sense if you actually budget for the delivery and just got a bit short in the end. In period 1 only 20k algo and under proposals were passed, clearly showing that people are hesitant to fund larger asks, this approach just affirms this narative making xgov useless for any significant proposal that requires larger chunk of funds, whereas if i understand it correctly xgov is supposedly the next step/replacement of the grants process(yes, it has amaller allocations to work with for now, but if we build the system around 10k algo allocations and specifics with this, then scaling it to fund larger proejcts once more funds are available will require few periods to calibrate- again… ). I’m always happy to wait and see but clock is ticking and crypto never sleeps.
also it’s not overcomplicating, its jsut changing the criteria for reserve list, one line of code to push teh narrative that proejcts that actualyl got large amount of total votes regardless of their asks are probably bigger impact/more endorsed by xgovs than small 5-10k algo asks, that are legit jsut farming free money.
again i’m firm believer if project asks for 5k algo and doesn’t get that many votes from all the xgovs, they have 0 place on reserve list.
@trekianov Thank you for addressing the points more directly.
However, I think there were clearly quite a few misunderstandings of my previous comment.
Regarding the Global Quorum
The common point of the suggested Global Quorum and the suggested Alternative is that measures should be put in place to prevent a small fraction of ALGO (holders) distribute large amount of common funds.
The difference is on where the limits should be placed.
With the Global Quorum, the (minimum) limits are to be placed on the relative amount (i.e. ratio) of ALGO that volunteered to participate in the process of fund distribution and the ones that actually participated in the process (i.e. voted), as explained:
With the outcome of not meeting the set limit be to not distribute any funds, as explained:
The main issue with this is the possibility of not distributing any funds which would be frustrating for the volunteers that actually participated in the process, as already stated:
One additional aspect the Global Quorum does not solve is the case when there are few ALGO volunteering to even participate in the voluntary fund distribution process of xGov. As an example of an extreme case, if there are only 3 users each with 1 ALGO participating in the xGov process, and two do vote while one does not, the whole 2M funds would be available for distribution.
Although it is to be noted the registration process is simpler compared to the voting, and thus less likely to experience technical issues that could lead to a low participation among the whole ALGO. But there are other reasons besides technical issues that could lead to a low participation in the voluntary process of xGov, e.g. the frustration with ones effort being completely wasted just because others did not vote.
Therefore, the suggested Alternative, where the (minimum) limits are placed on the amount of ALGO that volunteered and participated in the process relative to the funds to be distributed. The reasoning being, the larger the absolute amount of ALGO that actually participated in the voluntary process of funds distribution, the more representative are their decisions of the views of the actual fund owners (i.e. the whole ALGO community), and thus the larger amount of funds can be distributed with a high confidence.
In this case, the actual limits would be set by the whole ALGO community (i.e. fund owners) during the regular Governance vote, as already suggested. (In the example from the previous comment, the limits were arbitrary, but meant to reflect that much more than 1 ALGO should be required to vote to allow distribution of 1 ALGO).
Indeed, this Alternative is resembling the old approach. The difference is that in the old approach, even if 1B ALGO participated in xGov and only 30% voted (i.e. 300M), the maximum number of funds distributed would still only be 30% of the available funds (e.g. 0.6M out of 2M). With the Alternative, the full amount of funds would be available for the distribution (assuming e.g. the limit of 1 ALGO distributed per 10 ALGO voted). Regarding the terminology, this could technically be referred to as a quorum on each ALGO to be distributed.
Regarding the probability of participation
I think I misunderstood you. Please correct me if I am wrong, but you are referring to the conditional probability that the Global Quorum would not be met in two sequential sessions, while I understood it as the probability that a certain participation level is reached (or exceeded) in a voting session (and how that is changing between sessions).
Regarding the process of changes to the voting mechanism
I agree completely with the points raised. This is exactly why we need to have rules on how changes to the process can be made to be legitimately considered “made together with the community”, i.e. as suggested with the “xGov constitution” in the previous comment.
There would be no objections if there were rules stating that Algorand Foundation reserves the right to call up a vote 24h in advance for changing the mechanism, where the vote is conducted on Twitter with unrecorded emojis, and is considered valid if at least 100 users participate. Or something more realistic, e.g. that between the end of the last xGov voting period and the start of the proposal submission window for the next session, each Friday by 00:00 UTC+0 the Algorand Foundation can announce suggested changes to the xGov mechanism, and the xGovs that are currently eligible have 24h to vote by issuing a transaction to an address (similarly as with regular Governance). The results are confirmed if at least 10k ALGO vote and the majority of the vote approves the changes.
These rules can be introduced by the Algorand Foundation as part of T&C to participate in xGov, or preferably put to the general Governance vote for approval.
P.S. On the manner of the discussion
All the comments are/were made with the intent to provide constructive and respective feedback. If the latter did not come across and/or was interpreted to be aggressive, I do apologize. To note, the critique was never directed at any individual or at their assumed understanding. The last postscript was made as a mere suggestion on how to improve the quality of this discussion. The previous comment also made concrete proposals, which have been elaborated in this comment.
1 Like