Keep in mind that for the moment, we have a budget of 2M Algo/Quarter, so we still have some margin to adjust thresholds’ tuning.
For the first iteration, we might have something like this:
A proposal is approved if and only if:
A quorum of X% of the total number of xGov
The Y% of voting power approves
Then we adjust X & Y based on the amount asked; these parameters could be dynamically chosen based on what we see on the snapshot ( Maybe not in the first iteration due to the engineering effort /time)
xGovs Shall vote either “Approve”|“Reject”|“Abstain”
Value creation = performing the most valuable activities. The one we are focusing on this year is improving consensus participation.
@fisherman.algo I don’t remember the first time I saw a comment on social media or discord suggestions about node runners as xGovs, but it’s caught our attention enough times to bring us here. It is definitely better than what we have now.
Personally, I would like to get to a stage where DIDs could be used to prove expertise. People getting Algo certifications now could be experts soon, as we will look into ways of implementing that as well, at that point we could consider other types of voting.
Your blog post idea was out of scope. We don’t have a CfP on this topic, so the only consideration at the moment is the xGov process we’ve been piloting for the past 9 months. Best to focus on what we can build.
Ultimately, xGovs will be made of community+devs+foundation members because that’s who we all are
The new xGov will also have an rotating, elected council, which will be in charge of some key tasks. That might evolve as the program grows.
I still prefer @fisherman.algo’s solution of a committee with a retroactive focus. It mitigates the issue of whale monopolies, the issue of hazy forecasts of future utility, and the issue of xGovs not being well equipped to ensure technical milestones/deliverables are met (count me among the smooth brained). But it seems that is not the path being taken.
So, I’ll just say I share concerns about potential concentration of power in the hands of liquid staking protocols and other large whales seeking self-enrichment. Thus, some form of quadratic voting should be applied, IMO.
If this turns into Messina, FF, and other well funded projects starving out community development, it will quickly sour everyone.
The Algorand Foundation is the customer for grants. So, logically, it does not make sense for them to require the seller of services to follow a KYC protocol, which is intended generally for customers.
Traditionally, this is a contract for services between either two companies or one company and an independent contractor. There is no need to require one party produce a government ID.
There are legitimate concerns for proposers about what happens with their data. One of the biggest problems on Algorand is security. There is no guarantee for proposers that their data is safe, or won’t be sold or shared with third-parties.
This is already a huge problem with ASA verification. Hipo Labs, the maker of PeraWallet decided to remove all ASA verifications and then demand creators produce a government ID to them. But, Hipo Labs is not a reputable company and they have had significant ethical, legal, and security problems in the past. Personally, there is no way I would produce any sensitive or personal data to that company.
In certain circumstances, it would be more bearable if identity verification would only be required as a condition after a contract award. But, this certainly should not be a requirement at the proposer stage because there has been no award. It is a win-lose situation for any proposer, where the Foundation gets free personal data, but may not make any award to the proposer.
It makes sense to limit one grant per person or entity at a time, but there are better solutions to ensure that end than demanding people produce sensitive personal information. It is important to understand that people should have a right to privacy and their personal data. This is critical for individual security and sovereignty. The grant program should not infringe on that.
As an organisation we need to know who we are the grant recipients. Right now the grantees information live on the contracts signed with us. However, the new platform will integrate with a KYC provider. AF will not have access or store any personal information. We will only get the green/red light.
We added this requirement to the start of the process for two reasons:
To help mitigate spam proposals
To ensure that we don’t waste time with proposals going through all the stages only to realize at the very end that the entity does not meet the KYC requirements.
That way every proposal approved in the voting phase will be funded either immediately, if retroactive, or once deliverables have been verified, if proactive.
Right. Any time you sign a contract, you need to know the identity of the other party; and you should take proper steps to verify the other party. I’m not understanding where the shortfall is currently that requires additional processing or KYC.
So, for example, previously the grant program was run through Submittable. Is the new platform going to be like that? Now, the program is run through GitHub. Will the new platform launch for the next round or the current round that closes at the end of the month?
The main problem with KYC is that when you require users upload a government ID, it puts them at serious risk of identity fraud and otherwise is a serious security risk because it could potentially disclose home addresses and other sensitive government data.
This then becomes a huge security risk for the handler of that data as well because breach could and should have catastrophic legal consequences. It also opens the handler to significantly more cyber threats, as government ID data has significant black market value. As a result, this data becomes a significant liability for the holder.
The main point being, there are better and more secure ways to verify identity than to require government ID disclosure.
The new platform is a combination of smart contracts with a user-friendly frontend and is still under development, it will not be integrated with Submitable.
The KYC provider we work with is reputable and follows financial industry standards for data storage and security.
The next round is voting session 4 - the last one of the pilot phase - and the process will be the same as the previous three sessions with proposals submitted through github. There has been a few modifications to ARC-34, after voting session 3 retro. If you are planning on submitting a proposal this quarter please review the ARC-34 changes beforehand to ensure it meets the current criteria.
small timeframe after you always argued that xGov is in beta and we can’t expect too much? so 9 months of beta till now (or 1 year since the first sign-up?) was not a lot of time? i am just disappointed to hear again why AF isn’t able to deliver a great solution instead of the chosen okayish one due to time. I heard enough excuses, at some point its just enough
i am wondering, how do you proof that person operates the algod node?
if you want to proof it with the online status of the account, why dont you call it the correct name? the person does not need to run his own algorand node to make his account online… and this will be even more visible when AF will be paying for stake to be online
To be honest, I’m still trying to figure out how the previous xGovs program will be concluded, I’ve been staking via Folks Finance gALGO Vault the past 3 quarters, now I can’t sign up for xGovs, yet all my rewards from the past 3 quarters have gone into the pool…how are we going to settle that? I feel like we should be solidifying plans for that first, then talking about the new program.
I think you do not have the problem, because folks finance set the delegation to your primary account, so your primary account is the “xgov” controller account. I guess you noticed the stake at your primary account not your folks escrows when you casted the votes.
Just wondering, are you running the algod participation node and you have all your accounts (primary and folks accounts) in online state? Or are you using the public infrastrucure? Or not protecting the algorand blockchain at all? If so, what is the reason for it? Do you plan to stake at the aggregator pool account which will be online to get the participation rewards to all its members?
B. Transition for Previous xGov Members
We think that to transition from the pilot to the new system, previous xGov members should be rewarded for past participation and then retire their xGov status. This ensures a single, unified mechanism for becoming an xGov and prevents the overlap of old and new systems.
We currently think releasing funds (with rewards) at the end of the xGov’s pilot is the best thing to do.
I agree @lobo it is not ideal to have to wait so long to have the basic version implemented. I do hope we can iterate faster once we launch the new xGov portal.
Can voting power be evened out somewhat between whales vs minnows by a save and cap system?
For example:
Maximum number of votes accumulated and usable per period is 100.
If you are a minnow and accumulate 30 votes, but nothing for current period is interesting, can abstain from voting and save for next period. So next period maybe now have 60. Can continue to save until have 100, and cannot accumulate more.
Re: non-linear voting power @pescennius@CryptoFarmer: If there is any voting power benefit to splitting up your stake to multiple addresses (“sybils”), this will be exploited. The xGov voting power system can not be vulnerable like that, and I am not aware of any solutions to this problem that do not involve KYC / Identity verification.
@StephaneBarroso I understand the sentiment here but I think that this will get very messy. Between liquid staking protocols, pooled solutions (Reti), exchanges, etc., it seems like a large number of actors would end up with access to voting power corresponding to stake that does not belong to them (but is just escrowed in their possession.)
Okay thank you! So I should just automatically receive the funds as long as I’ve been voting…thanks for the response, my apologies for the delayed response!
I’m just running a node on my own hardware but using the gALGO Vault…next quarter I’m not really sure what I’ll do, if I run a node, I don’t have 30k staked so I won’t receive rewards, but I like the convenience of being able to leverage the $ALGO for both consensus and liquidity in DeFi. I’m also not really producing a lot of blocks with my stake, so I feel like my new xGov votes will be trivial…I guess I’ll have to see what solutions are live on mainnet by that time.
