Voting Mechanism Improvement Proposal for xGov Fund Distribution

Governance
1

Hi, following the discussion we had in Twitter Space with @StephaneBarroso here I briefly sketch here the proposal discussed there, which is build on these main improvements:

1. Two Quorums: 1 Global (for the Voting Session) = 50% and 1 Project (for every Proposal) = 33%. If the total stake of voters is > 50% the Voting Session is considered valid and we can proceed to fund distribution, otherwise an irrelevant fraction of xGov could decide for the majority, thus spoiling the concept of representation, therefore we declare the Voting session invalid. The Project quorum will be introduced later, in the Reserve List creation.

2. 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)

3. Create a list of Winners and a Reserve List: the Winners are those projects which managed to collect the needed votes (as in the present iteration). This mechanism ensures that for the Winners there are for sure sufficient funds. If all the funds (2M Algo in the previous case) are distributed (very unrealistic case) to the winners, the algorithm stops here. If there are funds left to be distributed, a Reserve list is build by ranking by “percentage of success” the proposals that managed to obtain at least 33% (Project Quorum) of the required voting power (see the above formula). The available funds are distributed until exhaustion to the sorted Reserve List.

I would encourage @SilentRhetoric and @scholtz to continue here the fruitful conversation we already started in Twitter Space. I also let @StephaneBarroso explain the proposal on how to limit the number of proposal in order to have an efficient voting session. Here it is the spreadsheet prepared by @StephaneBarroso to simulate the impact of the new voting mechanism on the last Voting Session, so you can play with data:
https://docs.google.com/spreadsheets/d/1V2tLolhKYtNguB1mVZ6xrd4FO6cZ8J45bCRxIQZqzjg/edit?usp=sharing

3 Likes
2

Here is my idea to Limit Proposals for the xGov Process

To regulate the number of proposals for the xGov process. Here are some stipulations:

  • Proposals should strictly seek grants of specific percentages of the total ALGO planned for distribution. These percentages might be:
    • 0.50%
    • 1.25%
    • 2.50%
    • 5.00%
    • 10.00%
    • 15.00%
    • 20.00%
    • 25.00%
  • There should be a skewness towards the middle percentages. Ideally, we aim for more projects requesting grants in the 10% to 15% range as compared to the extremes of 0.5% or 25%. This would somewhat mirror a gaussian distribution.

As an illustration, I have mapped out an example based on the 1st session involving 2M ALGO:

  • Total Proposals Allowed: 40
    • 5 proposals seeking 10K ALGO
    • 6 proposals seeking 25K ALGO
    • 4 proposals seeking 50K ALGO
    • 10 proposals seeking 100K ALGO
    • 6 proposals seeking 200K ALGO
    • 4 proposals seeking 300K ALGO
    • 3 proposals seeking 400K ALGO
    • 2 proposals seeking 500K ALGO

I’m looking forward to hearing your thoughts and feedback on this proposal.

2 Likes
3

I like the idea of percentage based grants and clear max/min amounts.

At first glance the number of proposals per range feels very restricting. There might be projects out there that only need 10k but if there are a lot of proposals in this range already they will might feel the need to ask for more and now risk getting their proposals approved because a higher amount means they need more votes.

Also I don’t understand how that would even work, first come first serve basis? That would be awful. Someone from AF deciding what proposal is worth it and what not to get to 40 proposals? Also a bad idea. Sounds like we would already need a small (not mandatory) vote before the actual xGov voting session to determine which proposals make it in and which not.

Some ideas:

  1. Max 2 proposals per person/organization to limit number of proposals (makes gaming it harder and i feel like adding more proposals means you cant finish them anyways in a period so why not propose them next period)
  2. have specific % based grants but dont know if limiting an amount of proposals that should be in a specific range would help. we don’t need to force something like a “gaussian” like distribution, this should happen naturally.
2 Likes
4

Disagree completely with the change to Total # of Algo who voted when the main issue was low participation rate. The focus should be on better and clearer messaging, not weighting the vote to the get grants approved. This is such a drastic change to the process with a low % participation rate. If this needs to be done to get some $ out the door, it should still meet the Pass Requirement. The 50% and 33% just allow more junk to get through.

Second, again disagree completely with @StephaneBarroso and limiting the amount that can be approved via a price point. What even is the thought process behind this? I don’t get it. Goes completely against the ethos of a permissionless system.

Overall, keep your finger off the scale and let the process work itself out on it’s own.

5

I like the idea of using actual voting power instead of total stake, but I think too many garbage projects are going to get funded with the 33% threshold per project. I think it should be 50% minimum, but I’d prefer a 60% supermajority.

I agree with capping the number of proposals per period

1 Like
6

Hi @LoafPickle,

Thank you for sharing your insights. I’d like to provide some clarity on the points you raised:

  1. Regarding the 1st Quorum at 50%: It’s worth noting that, had this threshold been applied during our first session, no grants would have been allocated due to the 34% participation. This threshold is, in essence, a stricter criteria compared to our previous setup.
  2. On the 2nd Quorum: The intent of this quorum is to potentially support projects that were on the cusp of getting funded. While you might find the 33% mark somewhat low, the perspective here is that each proposal stands on its own merits. If it garners votes surpassing a set threshold, it’s indicative of its merit in the eyes of the participating community.
  3. The Rationale Behind Using a Price Point: This mechanism serves to guide applicants. For instance, seeking 50% of the entire fund would invariably diminish chances of approval. Similarly, a request for less than 10k Algo (equivalent to about $1K) raises questions about the project’s scope and feasibility. Instituting a fixed number of proposals aids both from a user interface viewpoint and for xGov members. Given the voluminous nature of proposals, a deluge might become overwhelming and counterproductive.
1 Like
7

I have some thoughts about restricting the proposal amounts and quantity:

  1. I think making the proposal request amounts be nice, round numbers makes sense and lets people compare apples to apples more easily among proposals of similar size. I also think capping the asks at some fraction of the pool is reasonable. In my view, asking for more than 25% of the total pool is too much.

  2. I do not think it is tenable to restrict proposals to some arbitrary count within each size bracket. If there was a session with 5 large asks or a session with 40 small asks, that seems fine. What we do not want is some huge number of proposals. I actually think 30 might be a reasonable limit. Or 25, or 20.

  3. As an aside, although I myself made two proposals in xGov1, it probably does make sense to restrict each person/team to one proposal per period.

  4. I think the 33% threshold is too low for the second round. If the voting formula divides by total Algos voted, the next session will see many proposals getting higher “success percentages.”

8

On the voting mechanism

I think having a global quorum for the voting session makes no sense at all.
Voters that do not show up to vote anyhow become ineligible from the xGov program.
Therefore, there is no risk of “a minor fraction of xGov overpowering the majority” as declared by @StephaneBarroso on X (twitter.com) neither for

The reverse even applies. If there is a global quorum requirement, it opens the possibility for the to-be-ineligible majority of voters to simply block making decision of active xGovs.
Moreover, in the current mechanism, xGovs anyhow represent an arbitrarily-large subgroup of Governors.
Therefore, there is no need for a quorum.

I am also against the reserve list. With it, we are just lowering the threshold for spam proposals and/or self-voted proposals getting through.

All in all, I do not think there is a need for large changes to the voting mechanism at this stage only after one session, especially since there are fairly certain explanations for its poor performance - i.e. the technical issues of voting of whales, static ordering of proposals on the voting page, and poor communication about the program. Better to make incremental changes, focus on the low-hanging fruits, and reevaluate afterwards.

That said, changing the calculation from “total number of ALGO in term pool” to “total number of ALGO that voted” is absolutely necessary.
If this is not changed, funds from the next session will be blocked by now-ineligible votes from the first session.

On the limiting of proposals

While I know there is a large effort required to go through the proposals, I do not think enforcing limits to their numbers is the way to go.
As already stated by @lobo, it either introduces a race condition in case of first-come-first-serve system, or requires (another) middleman to filter them, which goes against decentralization.
I would rather see that by default xGov should be advised to abstain in the vote.
They should be convinced by projects/their supporters/fellow xGovs to vote for specific proposals rather then expect all xGovs to go through even 40 proposals.
Last period there was “only” 26 proposals and it took me a full day to go through them all.
What would help is to add more specific guidelines to the template, as already discussed on Github.

Nevertheless, I do think setting a minimum request amount is needed to ease the potential administrative burden and efficiency on Algorand Foundation.
This would also act as a deterrent for malicious actors/spam/self-proposals as they would need to get a certain minimum number of votes (assuming the current voting mechanism and not the reserve list).
I would suggest putting this limit to 1% of total available funds, i.e. a maximum number of 100 proposals being approved.

I would also agree with restricting submissions to one (or at most two) proposals per person.
Projects with a dedicated and focused team on a single project consistently deliver better results compared to ones that try to do multiple things in parallel.

2 Likes
9

Hello,

I think there is a fundamental problem in Xgov in terms of incentives. Fix this and everything will fall into place on it’s own.

As of now, there is no REAL incentives for any Xgov to put in any REAL, LEGIT effort to read, to vote, to participate.

For most people, they just want the free Algos, that’s why their here. Many just log in on the last day, and just did eeni meeni minie mo and voted without thinking of anything.

Because worse case even if you don’t log in and vote, you only lose your rewards, which were free and not even yours to begin with.

I don’t know if it is even possible to fix this fundamental problem, or if there is any solution to this… Please you guys suggest some.

Thanks

1 Like
10

There are no incentives for xGovs. This was decided on purpose exactly not to attract people who only vote to get some rewards.

@Adri I think it should be added to the disclaimer at Governance registration that there are no additional rewards for xGovs.

1 Like
11

I do not understand why want to complicate it with the specific percentages.

This will greatly complicate the talks about having the grant requests in USDC instead of Algo, as grant requests in USDC are much more efficient because algorand foundation has more cost efficient way to dump algos to the market than if every project will be dumping the algo on the market separately. Also the USDC requests creates much better budget calculation and less risk buffer request by the projects.

Also I noticed that with my formula, AF would distribute 1 975 101 Algos and with your formula 1890101 Algos.

@trekianov … i dont see my formula in the 3 options in the first post if i read it correctly. My proposal is simple: 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.

I dont see the reason to force people to get specific range. If one project requests 10000 algos and other will request 9999 algos, there is no advantage for any of these projects because number of will differ. If both project reach 100% votes for the proposal both will get funded and if not, there is basically no chance that the 9999 project will have equal number of votes for it and get the advantage.

The argument used there is : “To regulate the number of proposals for the xGov process”

@StephaneBarroso Why do you believe we need to regulate number of proposals?

With splitting the 10k project into 3k project and 7k project the project is risking that it will get funded only by 3k algos, because there is high chance that bigger more important part will have significantly lower votes/requested ratio. And for the community as a whole it is better to fund as many projects as possible, so this splitting may be even good because at least something will be funded.

I believe that the xGov creators should really focus on more important things like community reviews, making the better templates to request funds, making the possibility to do delegation of the voting power, making the possibility of encrypted votes or request proposals and making whole ux experience better. Also important thing is to make it much more efficient to allow the milestone acceptance by xGovs.

Actually i believe there are.

On the negative side the lock mechamism decreases the APY in comparision to standard gov APY. If you receive 10k algos each quarter you can stake the rewards and get the interest on interest.

On the positive side is that 30% of xGovs in first session did not vote, so I believe their standard governance rewards are distributed to thos who voted. So in the next xGov voting session I hope to see 3x higher voting power from G7 period plus G8 period. In 6 months i believe the rewards from G7 will come to my account and it will be 3x of standard governance for that period. Note that i believe that it was only one time when those whales controlling 40% of all xGov balance did not vote, so in the next periods this will probably not apply in that ratio.

1 Like
12

I was not precise enough with my first sentence (but it was in the last one). There are of course many incentives to participate as an xGov but there are no “guaranteed” monetary incentives as participants in the xGov program do not get any rewards from the Foundation.

I see that a lot of users think that xGovs get some rewards from the Foundation as is with Governors. It should be clearly stated at the disclaimer that this is not the case. It is true that xGovs might still get some rewards as other xGovs become ineligible. However, if all were to fulfill their duties, that would not happen (unlike in Governance).

13

I agree… In the case that every xGov governor vote, the return is even negative compared to gov rewards (APY vs APR).

Perhaps the foundation should create incentive that xGovs may be able to do paid reviews of the xGov proposals, and this would be beneficial for xGovs, would increase engagement and would increase information value for the xGov vote. Allocate for example 5% of the whole xGov budget to these reviews distribute them proportionally for each review and everybody would be happy. If you want advanced version, you can do reviews of reviews by those who participate more and get more skillful in it.

2 Likes
14

I will add simply that vanilla governance rewards need to go to zero as quickly as possible, and xGov can be incentivized but with higher participation requirements. The relative reduced APY disadvantage of xGov then becomes a moot point.

1 Like
15

I think there are incentives. Our rewards from regular governance gets locked up and then whoever fails to fulfill their duties for 12 months, will lose their rewards.

Those leftover rewards will be split amongst the eligible XGovs.

16

I just feel Xgov needs to have something to lose for not doing their duties thoroughly and genuinely. Because if someone has nothing to lose (even tho they have nothing to gain), why would they bother in giving 100% commitment and put in genuine work to grow this ecosystem in a positive manner.

Unless you’re a true saint - but this is very rare. Most people are actually in Xgov in hopes of getting more rewards.

I can almost guarantee that if you make people pay to be an xgov and lock up their algos for say 3 years (and then after 3 years, if all xgov duties are fulfilled, the foundation can perhaps reward these people extra, maybe pay them double or triple or however you want the incentives to be - I don’t know), many will opt out of xgov right away - because now they have their own hard earned algos to lose.

17

But that is the thing. If everybody votes, there are no rewards (unlike in Governance).

That is one of the problems. xGovs are supposed to be dedicated, already active and committed users who understand that the most rewards will come on the long-term if Algorand succeeds and they understand what is needed for that to happen (unlike many users who are interested only in short-term rewards).

1 Like
18

You are right, I agree with you fully.

How do we make sure we only get genuine, dedicated humans to be in Xgov who actually want to see Algorand succeed and are working for the long term benefit for the alogrand ecosystem? How can we accomplish this in a decentralized manner? How can we prove that people are actually doing their work genuinely and not only for short term rewards sake?

19

With Zero monetary incentives, you don’t get enough people to do the work.

With monetary incentives, you get many more ppl to do the work, but the quality of the work probably diminishes. Since many only care about short term rewards.

How to we find the perfect balance?

20

@scholtz your formula enters in defining the Reserve List. Winners are identified as in the current mechanism, then the remaining proposals are sorted by
votes/requested, but there is also a Project Quorum: a Project enters the Reserve List only if it has received more than Project Quorum. Essentially the Reserve List is a subset of your entire project list, ranked by the same observable.