In this post I am proposing a revised strategy for Community Snapshot voting which was introduced by @davekaj earlier this year in this Forum thread. As Dave noted in his post, protocol enhancements shall necessitate a review of the strategy that aims to reflect adequate voting representation of all network participants. As such, Curators are not included in the current strategy as that network role did not yet exist at the time the current strategy was deployed. Furthermore, this year has allowed us to gain experience with Snapshot and the current strategy and I will start off by sharing some frequent feedback I have seen raised in the community.
This has been a very common question and it is rather challenging to provide an accurate answer on a case-by-case basis. Voting power continuously changes, primarily based on stake changes in the network. Here an example of voting power changes across network participants which is based on a 5% total increase in network stake (between Delegators and Indexers):
An interesting follow-on observation in those numbers is that voting power for individual network participants decreases as overall stake in the network increases relative to total supply. We can extrapolate this further and assess voting power changes as overall stake percentage goes up. Below is an example of voting power if total stake in the network were to reach 60% between Indexers and Delegators:
The issue now becoming apparent is that voting power for non-network GRT keeps increasing as network stake grows, even to the point where it can have higher voting power than network participants. Naturally, this feels counterintuitive to the idea that network participants should have a higher weight in community votes.
As we are currently at a network stake of around 27% relative to total supply, we don’t have an imminent misalignment of voting power, but rather the opportunity to make changes now in order to future-proof our community voting strategy.
The following proposal introduces two fundamental changes: simplicity and network-alignment. The current strategy results in a possibly different level of voting power for each network participant based on changes to the overall levels of stake in the network. This has resulted in confusion with many network participants this year and does not seem to be a fundamentally necessary feature to assign desired weight levels. I personally support the idea to assign higher weight levels to those network participants that have 1) generally a higher degree of protocol knowledge and 2) have a higher responsibility in executing the protocol functions and services. Instead of a continuously changing voting power, I instead propose a fixed voting power weight as follows:
- Holder: 1
- Delegator: 3
- Curator: 5
- Indexer: 7
We know that the current design allocates 33% to each of the three current voting groups (Holders, Delegators, Indexers) which diminishes each network participant’s individual voting power as stake in the network grows. The above proposal would flip that around and give each participant a constant voting power regardless of stake changes in the network. For reference, here is how the group voting power would change as stake levels change in the network:
A growing network stake no longer adversely impacts the voting power for individual network participants. That is generally a principle I strongly support and hereby propose. The proposal also includes Curators and Subgraph Devs (assumption being that any Subgraph Dev with skin in the game would signal on their own subgraph) in the strategy with a weighting power that seems adequately placed between Delegators and Indexers.
You are welcome and invited to provide any feedback on the general outline of the proposal as well as on the suggested voting weights.