xGov Voting Session #2 - Retrospective

Governance xGov Proposals
,
1

Voting session 2 closed a couple of days ago and here are the official stats:

  • 1464000 of 2381556 ALGO allocated
  • 2813 out of 3653 wallets voted
  • 2,865,471,141,239 out of 3,282,211,058,290 total stake voted (87.3%)
  • 12 projects directly approved
  • 6 projects approved with the reserve list feature, implemented after voting session 1.

What an improvement from our inaugural session!

Retrospective #2

We are hosting an X Space retrospective (retro) to discuss the results and what improvements we should focus on for Voting Session 3 in February.

MONDAY 18th December 12pm UTC

Please start adding your feedback below. We will gather your main points/suggestions to kick off the retro.

----- AND -----

We would also like to invite all approved proposers to join us on stage at the retro to, not only sharing their xGov experience and how we can evolve the platform, but also to their building plans with the community.

Let’s do this Algo BUIDLERS!

1 Like
2
  • max proposal per person/company
  • potentially a higher % needed for the reserve list since a lot got funded this way, in particular 4 proposals by the same person, which is weird
  • voting for already passed proposals did waste a lot of votes again so why should it be allowed if there is a mock proposal?
  • limit proposals you can vote on if the weird behavior silent pointed out still persists (in a way that scales so whales aren’t forced to waste their votes, so the more stake you have the more proposals you can vote for)
4 Likes
3

  1. I think there should be no limit on the number of proposals that a person can vote.
    We have to find out the real reason behind the behavior and deal with it rather than restricting it.

  2. I certainly agree with higher % required for reserve list. My suggestion is 80 - 90%. That will make sure that the projects that are on the edge (can happen if quality of proposals in a lot is very high) can move into reserve list.

2 Likes
4

honestly i dont think we can determine really why 1 happens

1 Like
5
  • HoneyPot proposal that makes you ineligible as xgov if you vote for it (to eliminate indiscriminate/botted votes)
  • Reserve list alloaction cap (e.g 200k algo max OR what is left in the gov pool, whichever is smaller), its utter nonsense proposals pass only because there are funds left (i think 2 proposals in total didnt pass, and out of 1.4mil algos voted for, 700k were approved through reserve list). Reserve Allocation cap eliminates guesswork about what % to put reserve list threshold at. And it also limits number of “reserve-passed” proposals. Only the top few will get in like that. And this basically simulates how the reserve list selection would pan out if there were more proposals approved in the first place. e.g. less funds available for reserve list and only top % voted ones would qualify.
  • UI/badge in the voting tool for the doxxed/non-doxxed devs to help people sort through flood of proposals
  • Ideally chart a course to faster iterations on the xgov voting periods in the future. quarterly cycle is not fast enough. If you aren’t lucky with timing you might have to sit and wait on a great idea/solutions/tool for the ecosystem for north of 6 months - by that time it could jsut aswell be obsolete.
5 Likes
6

i like the reserve allocation cap idea

3 Likes
7

One missing piece is verification of milestones/deliverables.

  1. There should be a process that has to be followed to make sure the proposer completes the milestone or deliverables before release of funds.
3 Likes
8

I really don’t care about the max per person, it can be easily gamed through having multiple people submit it vs one person.

Reserve needs to go. Probably won’t happen, but it should be at least 85% of the votes needed to get on a reserve list and from there they can sit and wait if any of the approved projects drop out and funds can be allocated to the reserve based on closest to 100%.

3 Likes
9

I passed with reserve and I am really grateful about it. I do understand the issues with it though. Are there any easily findable public follow-through about the delivery of past proposals? I think it would make voting a lot easier if we had like bi-annual newsletter about the state of all passed proposals. We are a small community with recurring proposers.

3 Likes
10

I am reeeally happy but I also find it a bit strange that I get the same treatment as someone who fully passed. On the other hand it’s difficult to find the right amount to ask. What if I asked 100k algo and got voted 95%. Loosing all because of that 5% seems bad too. I think reduced funds / a cap would be the way to go with the reserve list with an option to reject if the proposer thinks the funds would not cover costs and the development is not worth it.

2 Likes
11

Yes. That make sense. that is why i suggested a minimum 80% vote share to be in reserve list.

2 Likes
13

I totally agree with the higher percentage required for the reserve list. There should also be a maximum amount for the reserve list (e.g. 10% of the pool size if left in the xgov pool).

1 Like
14

I definitely agree with increasing the minimum for reserve to 80%. Also there should definitely be a cap on the amount used in the reserve. Shouldn’t be able to have 100% pass just because of reserve. The objective isn’t to just spend all of the funds after all.

1 Like
15
  • stacking of voting power between periods (normalizing it per session to mitigate effect of reduced Governance rewards)
  • decoupling of voting power from Governance rewards (going to 1 ALGO = 1 vote principle)
  • improved guidance on proposal contents and required details
  • signing off on the delivery
  • honeypot proposal to disqualify non-committed voters
  • implement exclusive disjunction logic for voting either on any proposal or on the mock proposal but not both, otherwise disqualify the voter (as the action is illogical and counterproductive)
  • optional KYC by Foundation for proposers
  • max number of proposals per (KYCed) person/company
  • sorting of proposals on UI by publicly doxxed
  • remove reserve list
16

The constant number for reserve list does not make sense.

Imagine the situation where algorand would promote grants program extensively, and there are requests for 100M algos and only 2M allocated.

Lets say there is 200 proposals for 500k Algo.

And lets say everyone votes for all proposals uniformly… With big number theory this is quite real.

So all voters distribute for each proposal 40 000 algos, and all proposals would miss 400000-40000 = 360k Algos to pass. Thus no proposal will pass and we are at square 1. So do you want to finance ecosystem projects or you want to see the failure of the algo grants program again?

So the question is who can sqew the big number thery to his favor? The answer si quite simple - Whales. People who had a lot of algos in the begining can pass the proposals that they want. And math is pretty simple there as well. If you have for example 10% of all votes, you can request 10% of the allocated budget for your project and you can pass it. (Also smaller players can do this, if you hold 0,5% of xgov votes, you can request 10k algo with confidence it passing)

So the question is, what is target of the xgov voting session… Is it to build a new projects on algorand blockchain giving out 2M algos each quarter, or is it to support whales fund their selected projects?

Please cancel the reserve list completely and do it the way that anyone can request grant. Sort all proposals with popularity and fund the best. Let’s break barriers of entry and allow anybody to propose anything they need in the algorand ecosystem. Also it might be good to have some idea place where people who do not have dev capacity to write and propose what they want to see built.

There is many people however wanting to have some threshold in place. So if you want to do the threshold, please do it variable not constant. Please use at minimum the requested amount variable, allocated funds variable, number of people who do not vote, and more.

Also 2M algos is really not much to distribute in my opinion. I dont understand how poeple are happy with this when AF is giving out much more grants directly to them selected companies giving out much more to support defi ecosystem or distribute much much more through the governance…

Also in light of #82, i would like to call to make a allocated funds to be distributed in multiple categories. I shot the #82 the Prague community meetups to the vote as the example how worldwide voting does not favor the local events. Most of the voters does not have any incentive to vote for some events in europe if they live in the US or India, but they have incentive to vote for something they get the service in return such as the CL AMM. Which is absolutely logical. However this demonstrate that some projects have higher probability to pass than others. To make this more fair perhaps some funding categories should be created, and if we want to support also the local events, local hackathon grants or whatever this should be done. Or perhaps this is argument why there should not be the reserve list threshold. Or parhaps there should be some other variable someone create to allow some projects to have lower threshold for passing.

1 Like
17

xGov funds are not for special local meetups

also you are using a worst case artificial case to argue why you are right which is a very unlikely one imo

1 Like
18

I have not seen for what should be the xgov funds. I assume it is for general well being of algorand community. With this I do not understand why it should not be used for inperson meetups.

I hope to see the rules for the xgov program adaptive. So if there will be massive marketing campaign from the AF that here is the grants program, I assume that it will handle and finnish better than session 1.
Yes, the example is extreme, but it demonstrate the point. Even if there is not 50x of requests but lets say 5x of requests this will start to show if we have the constant 60% or proposed 85%. Btw it works the oposite way as well… If there is not enough proposals to match the funding the threshold should be higher.

19

imo xgov funds are supposed to fund things that add value to algorand in general. local meetups are not adding any real value imo, they just benefit the few people from that region. same goes for rewards for liquidity for a specific token especially since we have the defi boost already

it should be adaptive but it will be hard to come up with an adaptive mechanism that is fair, not gameable and people can agree on

1 Like
20

We should hide the vote from everyone until the end. No one should see which proposals have how many votes until xgov is closed.

  1. If your projects passes 100% of votes, then you get the funds, if you don’t reach 100%, that means the majority of the algo community don’t want that project. This is what democracy is suppose to be about. Not everyone will get what they want. We need to stick to the rules.

Imagine taking an exam and you get 49%. Your teacher is going to write F for fail. And then you go and say but it’s only 1 percent less to pass… can you please give me extra 1 percent please… This is not how the world works. 49% means fail. 50% upwards means pass. If you got 49%, sorry but work harder for next time. Same with xgov - If your project got 99%, suck it up and move on, it didn’t pass. Maybe next quarter it will pass.

This brings me to reserve list… I’m not a fan of reserve list simply for the above reason I mentioned - HOWEVER, if we must have a reserve list, it should be 90% + of the votes to be considered.

Anything less is just defeats the entire purpose of XGOV.

  1. To all who want funding - Ask for less, you will most likely get the funds. Ask for too much, you probably won’t get the funds. Its common sense.

If your project really needs ALOT of funding, you need to break it down into very small pieces and milestones… Each milestone needs to be checked, double checked, verified, that it actually does what it’s suppose to do. Once the milestone is met, the funds are released. And so on…

When you build a house, you don’t pay the contractor 100% of the funds upfront - if you do pay 100% upfront, you’re a fool because this CAN make the contractor not give so much attention to detail anymore since he has already got paid… Instead of using 6mm steel, he may cut corners and use 3mm steel. Or it could even lead to the contractor just running away and screwing you over…

Common business sense.

I forgot to mention: Every project that gets funded via grants NEEDS to be open sourced. Incase the team fails to deliver, someone else can carry it on if needed.

1 Like