The Algorand Foundation held a public xGov meeting on April 4, 2024 for the new version of xGov.
Main Discussion Points:
A. Becoming an xGov Member
Operate an Algorand node to participate in the consensus (no minimum Algo stake is required)
Complete the registration process to become an xGov member.
Receive an xGov vote for each block proposed by your node. This approach intends to reward participation in enhancing the network’s security and operations rather than just the size of Algo stakes.
A fresh cohort of xGov members will be selected to join the voting committee periodically, with eligibility based on activity during a specific timeframe. Snapshots will be taken every X million blocks, where currently, 1 million blocks roughly equates to one month.
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.
C. Proposal Submission Changes
There are plans to introduce a KYC requirement for proposal submitters. This is in line with feedback from the pilot phase and aims to limit active proposals to one per KYC-verified individual or entity at a time, ensuring completion before another can be submitted.
D. Refining the Voting Mechanism
Adjustments to the voting and rewards mechanism are proposed to mitigate potential manipulation. These will be structured with thresholds and durations tailored to the amount of funding requested:
Category
Requested Amount (ALGO)
Discussion time (at least)
Voting time (after discussion)
Small
10k ≤ A < 50k
1 week
1 week
Medium
50k ≤ A < 250k
2 weeks
2 weeks
Big
A ≥ 250k
3 weeks
3 weeks
xGov IP
-
2 weeks
2 weeks
We still need to define if the threshold of voters & votes should be the same for each category or if each one should follow a different curve.
Feedback: We invite you to share your insights and what you think about all this.
Upcoming Initiatives: In the near future, we’ll host a community event to unveil the definitive version of our proposals. Stay tuned for details.
blocks produced and ALGO stake correlate tho, over a long timeframe its essentially the same (assuming a perfect healthy node), so it doesnt really lead to what you wanted or am I missing something?
And again just because you operate a node (nowadays you can just download an exe) doesnt mean you are an expert in any way, its again just whales doing what they want
On a more philosophical level I agree that xGov voting power shouldn’t 1:1 correlate with ALGO holdings. imo its important that developers, projects, and other actual users of the chain have a louder voice than passive investors. However, I do think that requiring node operation is also a good step in that direction.
I believe there are ways to compromise giving value creators outsized influence without defaulting to giving that influence towhales. It could be one, or some combination of:
stick with allocating by consensus, but voting power is allocating quadratically or some other concave function that diminishes the value of additional stake. There is plenty of precedence for this.
Allowing users to acquire larger stakes by committing to lock their funds for a longer amount of time. Algofi had a mechanism like this for BANK
a tiered system. The existing system would remain as is, but you can double your voting power by proposing at least N blocks in the leadup to a vote. N is a function of how much the user staked, such that both whales and small nodes have to participate most of the time to quality.
You say you want to empower “value creators” but all three suggestions listed are functions of stake, not value creation, so they don’t really achieve your stated objective.
I, too, am wracking my brain for a way to create a robust system to give weight to people who are truly engaged and “expert” but I am currently searching for workable ideas. Some sort of system of elected representatives might change the dynamic, but that also comes with its own set of issues.
Perhaps the way to balance the system is to give engaged participants a different role, such as proposal screening or vetos. I am increasingly of the mind that a strong system needs built-in and independent checks and balances rather than a one-dimensional approach as a function (directly or indirectly) of stake.
We cannot have a soft “staking” like we do with current governance, and an application/smart contract will not be able to check that. (And I doubt people will want to miss out on rewards to be an xGov)
However, we can have an on-chain control of who votes; this is fairly similar because your chance to propose a block is proportional to your number of Algos.
Remember, they need to register as xGov also (this part is not defined yet), but I doubt that CEX or Pools will bother to register without incentive.
Imagine the new xGov system is operational. We look back at the activity over the last one million blocks in the Algorand blockchain, which is approximately equivalent to the past month’s worth of transactions and operations.
During this period, every address that successfully proposed at least one block and was registered as an xGov member will earn one vote.
For the upcoming cycle, which will cover the next one million blocks, the total number of votes that can be used for governance decisions will be equal to the total number of votes earned by all addresses in the previous cycle.
TL,DR
If 500 blocks were proposed by registered xGov members, that means 500 votes will be in play for the next cycle.
The pools run by defi protocols like folks finance will have big advantage if you consider the number of blocks proposed as a criteria for number of votes.
We have a small timeframe to get this implemented and one of the big short term goals for the Foundation - if not the biggest - is for the community to have more stake securing the network. Incentivizing consensus and allowing block proposers as xGovs goes hand in hand.
The “1 block proposed 1 vote” criteria is the first option we are considering. It will not stop there. Once the platform launches and this new methodology is tested, we will continue to explore ideas to wide the criteria to join as an xGov, as well as other ways to improve the program.
A major concern that I have not seen being addressed is what if exchanges/pool-node-runners who aren’t the actual stakeholders and receive a large number of xGove votes do not vote for the best interest of network and real stakeholders? Or, what is the protection against the conflict of interest?
This isn’t an imaginary concern but a real one. Exchanges like coinbase and binance run their own networks (base and bnb) and do not want to see a better competitor. Moreover, they work closely with market makers and traders and depending on the market cycle stage they may hugely benefit from negatively impacting the Algo price.
I don’t see how running a node makes you an effective allocator of capital or an ‘expert’ on the ecosystem. The voting will be a whales games as it is directly correlated to the amount of stake you have. So now experts who have a small stake relatively speaking will have almost no say compared to the whales who could potentially care less about public goods funding. Node operators incentives are not to fund the ecosystem but to generate yield.
I don’t remember this being talked about at all over the past few months. Now all of a sudden we need to rush and that’s the reason for picking flimsy criteria?
I would still love to hear feedback on the idea I proposed of a council of community+devs+foundation that are hand selected for being experts in their field, giving them all equal voting power, and then when votes are done take the median.
Xgov and network security have nothing to do with each other. Why are we trying to use Xgov as a way to get people running nodes? Shouldn’t that be handled by node incentives?
This is 100% a whales game now, not experts making hard choices on public goods funding. The experts votes will likely not make any material impact when compared to one whale with hundreds of millions of ALGO staked.
You say you want to empower “value creators” but all three suggestions listed are functions of stake, not value creation, so they don’t really achieve your stated objective.
Given the complaints already, why not make it quadratic? This is already really common in web3 public goods funding and not meaningfully harder to compute with the data you are already going to use for xGov. You can use it to limit how many votes someone gets in the first place by taking the sqrt or log of their blocks proposed. That allows you to keep your timeline while at least acknowledging the concerns being raised by members here. Because as @awesomecrypto@vidhyanand mentioned, exchanges and large defi pools are going to create distortions because they can have perverse incentives. And if you won’t do even that, I’d love to hear an explanation of why it wasn’t feasible.
One thing i have to specify is, the only quantitative way to measure commitment is proof of stake and there by node running. All the other methods of selecting xGovs can be gamed in long term as lot of money is involved. So this is step taken in right direction.
We certainly have to look into other effective methods of calculating the votes for each xGov.
I missed the call, but i like where this is going. I fully support the node running requirement and block proposed = vote seems like a good starting point to see how first few periods will go.
Overall i think it’s an improvement over the current voting power allocation, but i would, like many have pointed out already, like to see some sort of a transform function on the number of votes per account, with log or quad function to prevent whales completely running the show. In the current “old” system you could stack over 4 periods and get to a decent voting power, in new system this completely removes any impact of small voters as their power will be reset every 1k blocks or so… making them unable to stack or get relevant power - so this should be addressed.
I’m also a bit warry of the scenario when there is low participation and its implications to voting power distribution. Were there any consideration of thsi scenarios and what are the solutions for it?
I think it can be solved with some math.
As I said in the first post, there will be two thresholds: one based on the number of votes and the other on the number of voters(addresses).
Even if an exchange/pool gathers a lot of votes and can influence part of the threshold, in order to influence the other part, they will need to create multiple nodes (with more than 30k Algo to keep the incentive) and then vote manually on the website for each node.
For example, if we say you need 50% of the vote available and 50% of voters to get your funding, it seems like a strong enough mechanism to prevent gaming the system.
they will need to create multiple nodes (with more than 30k Algo to keep the incentive) and then vote manually on the website for each node.
Both of those things can be scripted. If I feel comfortable writing the code, an exchange or liquid staking provider will do it if the incentive is there.
For example, if we say you need 50% of the vote available and 50% of voters to get your funding, it seems like a strong enough mechanism to prevent gaming the system.
Its not just about pushing through the votes, deny votes to certain projects or initiatives can also be strategically advantageous.
But generally I agree that this can be solved with math. I’d err on the side of cautiousness here though and restrict whale voting more than you have to. It will be easier to recover from giving them too little voting power than too much. Ignoring the money and just from a reputational standpoint, we really don’t have margin for this to look like its being exploited by whales. The crypto community is fickle and petty. If the notion that xGov is pointless and just for whales catches on, it won’t go away. Just look at how accelerated vesting played out…