Community Snapshot Voting Strategy

[Oliver]

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.

Problem: What is my voting power?

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.

Proposal

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.

[juanmardefago]

Just as a quick heads-up, Curator representation has been added to the latest strategy if I recall correctly (tagging @ari to make sure this is correct), but it was added using the old participants VP split.

The idea of having fixed amounts of VP per GRT on each group is still valid and an actually decent solution, and it’s a good discussion to have. My only concern is whether that introduces game-ability on the snapshot votes (which, since they are not final right now, wouldn’t be that bad, but still something to be aware of).

My guess is that it doesn’t, because of the taxes/thawing periods, but if those things ever change (curation tax 0%?) you could be a holder that curates to get more voting power. (Although I think you could use an “old” snapshot of the VP, to make sure nobody moves GRT around freely just before voting, to game the voting power system, and then takes the GRT out)

Short summary, aside from some minor considerations I think it’s a decent idea which improves on the current system!

[ari]

@juanmardefago n the current implementation of voting strategies, Curators are represented as part of the token holders group, based on their tokens deposited for Curation. Previous to that fix those tokens were not properly represented as part of their balances. This means that Curators do not have any individual weighting like indexers, delegators or token holders.

@Oliver it’s an interesting observation to see how the distribution of voting power changes with time and in scenarios where we have more stake participation. Definitely it won’t be a good idea to have greater power given to plain token holders than network participants.

Are the weights based on any analysis or just set as an example? The scoring would be easier to do this way and it might even be easier to understand for network participants.

[Oliver]

I have done some local pragmatic-based analysis that led me to proposing the above numbers. I started out with 1-2-3-4 as an intuitively reasonable weighting distribution. The issue I felt here was that at the current network stake levels of 27% the non-network holder group would have over 50% of VP, which did not seem reasonable to me:

I went up to as high as 1-4-8-12 and the issue I felt at those levels was that non-network holders become significantly marginalized in their VP as network stake grows. At 60% network stake, the VP of the remaining 40% of non-network holders was down to 10%:

While non-network holders should have relatively less voting power vs network participants, I feel it should not happen to the extent where it discourages voting for non-network holders altogether. The 1-3-5-7 proposal subsequently appeared to hold voting distribution across the different groups fairly steady along different network stake levels and as such I view it as a reasonable middle ground.

@juanmardefago I like your idea of implementing an older network stake snapshot when voting proposals are created, such as taking data from 1 week prior to voting start.

[Topher66]

Excellent breakdown. I agree that the voting strengths for the various categories should reflect their involvement and expertise. Thanks for sorting out and testing the various combinations. 1-3-5-7 appears reasonable.

[DataNexus]

I’m in favor of this.

For curators would we want to utilize the sum of share value as opposed to the signal amount (current vs cost basis)?

[MrStevenStiffler]

I am not too concern on people trying to curate to attain voting power. Because, if they curate to the wrong subgraph this could be very costly.

[davekaj]

Hey y’all,

I love the proposal. I support the general idea. First I will provide some context as to the original voting score:

• The original plan was to give all actors a voice, including the people who just hold GRT in their wallets. Even though they do not have as much skin in the game as the Indexers or Delegators, they still need to be considered.
• We always wanted the individual groups to have a say no matter what. That is why we locked them in at 33% each.

So the good thing about it is, each cohort does have a say. The bad thing about it is that the voting power per token can get skewed pretty bad, as shown by Oliver. I had not thought about it from this angle, and I think this should be corrected.

I do think the proposal is good, and I really like the simplicity of it. Because users should be able to easily know their voting power.

One option I would like to add to the proposal is the potential of putting upper and/or lower bands on the percent of vote power the total cohort can get. For example:

(This is only a quick example, it needs more thought)

• Token Holders - no more than 25%
• Indexers - no more than 35%
• Delegators - no more than 35%
• Curators - no more than 10%

The point of this is to prevent a scenario where Indexers can completely take over the network because they always have the most strength if a vote is in their control. In the long term, this could prove to be contentious, as delegators could get to a scenario where they will never be able to win a vote against indexers. It could also create a black market for delegators to put their tokens into a smart contract as a bribe, and get paid for it (see Votium for a real-world example).

In conclusion, I would like to see Oliver’s proposal implemented, but with upper or lower bounds on the voting power by cohort. It would also be great to keep it simple for the users, which will be a bit complex, with what I am suggesting to be added.

[Oliver]

Thank you for the feedback @DataNexus @MrStevenStiffler @Topher66 and @davekaj!

I am supportive of an introduction of bands. I also feel that the initial 33% voting distribution included an element of fairness which could also be extended to bands, and thus have same thresholds that apply to every group. One goal with that should be to identify the biggest possible range between lower and upper band, so that the simplicity of the model 1-3-5-7 remains applicable in a high number of different distribution scenarios.

• On the upper side, there seems a natural 50% ceiling (why go higher when introducing the concept of bands) but that may feel a bit high itself. 40% may in turn come closer to everyone’s comfort level.

• On the lower side we may find a higher range of opinions. Let’s start off with 5% to see how actually VP changes. Below is a look at VP based on the the current staking distributions in the network

Indexers and Delegators are within the band range and thus maintain their VP of 7 and 3 respectively. Non-network holders VP goes down from 1 to 0.55. The Curator group is most interesting with a jump from 5 to 833. While that seems massive at face-value, one should bear in mind that curation has by far the lowest share. Even if all Curators were to vote on a proposal today, the combined vote share would still aggregate up to 5% of all votes. On a positive note nonetheless, such high VP might in fact be slightly stimulating for curation itself.

Looking ahead, it would seem that the Delegator group may be first in line to possibly surpass the upper band in the future among the network groups. As a reference: at an upper band level of 40%, the VP for Delegators would then go down from 3 to 2 if their overall share were to grow to 60%, still 2x of a non-network participant.

Would love to hear feedback on:

1. Idea of same band thresholds for all groups
2. Suggested values of 5% for lower band and 40% for upper band

[DataNexus]

Though it initially looks dramatic, I feel like this concept makes sense. With curation being a smaller voice this offers a way for our activity to still make an impact.

I currently have 15k in curation stake, which would give me a voting power of 12.5m or an equivalent to an indexer with a 1.7m stake. As the query fees grow on the mainnet I would expect the curation stake to grow at a faster % than the other stake holders since it is currently at such a small level. So this should become less and less dramatic.

[MrStevenStiffler]

Very interesting concept, I think making the VP adjust so that it balances out in the future is wonderful.
I do think that having the minimum of 10% may be a better number for the lower band, otherwise the avg voting power of the other 3 roles would be something close like 31.6% which seems very close to the original 33%.

[davekaj]

I like the upper band of 40% for all of them. It keeps power in check.

I wonder about the lower bound of 5%, if it is even needed. Curators are being rewarded 166x the voting power, because there are so few of them. I don’t know exactly if that is the right way to reward them.

Personally I would go with just a 40% upper band, because it also adds simplicity to the equation, which is already kind of complex. All you need to know is that it is 1, 3, 5, and 7, and that you have the potential to have your VP decreased if one cohort is crowded.

What do you guys think?