Introducing Delegated Voting: Enhancing Governance on Moonriver and Moonbeam

Governance Delegation
,
1

Introducing Delegated Voting: Enhancing Governance on Moonriver and Moonbeam

TLDR: delegated voting will soon be introduced to Moonriver and Moonbeam. This post aims to present the primary benefits and potential drawbacks of implementing this governance mechanism. Furthermore, it seeks the community’s input regarding a Community Delegate Code of Conduct.

OpenGov brought a multi-role delegation feature to Moonriver, enabling token holders to delegate their tokens for voting purposes based on tracks. Previously, delegated voting existed, but a complicated user interface (UI) deterred many users from utilizing it. However, with the new delegation feature that will soon be integrated into the [Moonbeam DApp], this hurdle is eliminated, making vote delegation easier than ever.

Overview

Delegated voting is a mechanism that can empower token holders to delegate their voting power to a trusted individual or group, enabling them to vote on their behalf. This system is implemented with the objective of enhancing decision-making efficiency and ensuring that governance matters are handled by individuals possessing the necessary expertise and knowledge. It’s important to note that even when tokens are delegated, they remain securely stored in the original wallet. Additionally, voters utilizing delegation retain the flexibility to modify their chosen delegates or reclaim their voting power whenever they deem necessary.

Pros and Cons

Delegated voting, as a governance mechanism, presents both advantages and disadvantages worth exploring. Understanding these pros and cons is crucial for assessing the potential impact of delegated voting on the overall effectiveness and inclusivity of decision-making processes within a community.

One of the primary advantages of delegated voting is its ability to promote efficient community based decision-making. By allowing token holders to delegate their voting power to trusted individuals, delegated voting ensures that decisions are made by individuals with expertise in relevant domains. Delegated voting also empowers token holders who may lack the time or expertise to actively participate in governance, providing them with the opportunity to contribute to decision-making indirectly.

Furthermore, delegated voting has the potential to solve the issue of low voter turnout or ‘voter apathy’ that is frequently observed in decentralized communities. This issue is critical because it can cause significant delays in critical updates, such as runtime upgrades. Conversely, low turnout can lead to malicious actors harming the network with lower stakes, which can be detrimental to the entire ecosystem. By delegating their voting power to delegates who share their values and interests, token holders can remain involved in governance processes without needing to participate directly on every issue. This characteristic promotes wider participation and ensures that decisions are not solely based on a small group of highly active token holders.

However, there are certain drawbacks to consider when implementing delegated voting. One concern is the potential for centralization of power. If a small number of influential delegates accumulate a significant amount of voting power through delegation, they may exert undue influence over governance decisions. This concentration of power could undermine the principles of decentralization and lead to decisions that may not truly reflect the collective interests of the token holders.

Another challenge associated with delegated voting is the risk of delegate misconduct or negligence. While delegates are entrusted with voting power on behalf of token holders, there is a possibility that they may act in their own self-interest or fail to fulfill their responsibilities diligently. To address this issue, establishing a clear code of conduct for delegates and implementing mechanisms for transparency and accountability become crucial in order to safeguard the interests of token holders. Therefore, one of the objectives of this post is to gather input from the community regarding what should be included in the delegate code of conduct. As for the enhancement of transparency, the initial step will involve creating a dedicated space for delegates in a community Forum where they are required to update their delegators about decisions they make and explain rationale behind each vote.

It should be noted that delegation is a permissionless process, and token holders are not obligated to adhere to the code of conduct. However, if a potential delegate wishes to utilize community resources and openly present themselves as a delegate to other community members, such as through the Community Forum or the Moonbeam Dapp, it is reasonable for the community to request the observance of the Community Delegate Code of Conduct.

In conclusion, delegated voting offers advantages such as efficient community decision-making and increased participation. However, it also presents concerns regarding the potential centralization of power and the need for robust checks and balances to ensure delegate accountability. Careful consideration and thoughtful design of the delegated voting system, including mechanisms for delegate selection and accountability, are necessary to maximize the benefits and mitigate the drawbacks of this governance mechanism.

Delegated voting on Moonriver & Moonbeam

Delegated voting has been a feature of Polkadot’s governance for some time, but its potential has not been fully realized due to the complicated UI. However, this is about to change with the upcoming Moonbeam Dapp update which will enable token holders to delegate their votes more easily. Through this new functionality, token holders can delegate their voting power based on five different tracks. These tracks correspond to the different processes that proposals undergo during a referendum, depending on their level of emergency and importance.

Screenshot 2023-05-11 at 15.56.57
Screenshot 2023-05-11 at 15.56.571496×718 50.7 KB

(to read more about different tracks see here)

For example, Root track is designated for highly critical updates such as runtime upgrades, and token holders can choose to delegate their voting power to a delegate who has the necessary expertise and knowledge about the networks and their ecosystems. This will ensure that critical decisions are made by individuals who are well-informed and have the necessary experience to make strategic choices. The General Admin track, on the other hand, is open for general on-chain decisions, and token holders can delegate their voting power to any delegate or even choose to vote themselves. It is important to note that token holders can change their delegate or take back their voting power at any time. This flexibility provides token holders with the opportunity to remain engaged in governance processes without requiring direct involvement.

Overall, the implementation of delegated voting on Moonriver/Moonbeam is poised to promote efficient decision-making and encourage broader participation in governance processes. Token holders have the opportunity to delegate their voting power to delegates with the necessary expertise while retaining the flexibility to change their delegate or vote themselves.

Points for discussion

In order to ensure the integrity and effectiveness of delegated voting on Moonriver/Moonbeam, it is important to establish a clear Community Delegate Code of Conduct. Here are the initial guidelines based on the research on the topic:

  1. Act in the best interest of the network: Community Delegates should prioritize the long-term success and development of Moonriver/Moonbeam and make decisions that benefit the networks and broader community.

  2. Vote on the vast majority of proposals: Community Delegates are expected to actively participate in the governance process by casting votes on the majority of proposals. This ensures that token holders’ voting power is utilized effectively.

  3. Be knowledgeable about developments in the network: Community Delegates should stay informed about the latest updates, advancements, and challenges within the Moonriver/Moonbeam ecosystem to make well-informed decisions.

  4. Review each proposal thoroughly before casting a vote: Community Delegates must carefully examine and analyze each proposal before voting. This ensures that decisions are based on a comprehensive understanding of the proposal’s potential impact.

  5. Notify delegators about the rationale behind each vote: Community Delegates should communicate the reasoning behind their voting decisions to the token holders who have delegated their voting power. This fosters transparency and helps delegators understand the delegate’s approach.

  6. Adhere to transparency and disclose any conflict of interest: Community Delegates should be transparent about any conflicts of interest that may arise and disclose them to the community. This fosters trust and ensures that decisions are made without bias.

  7. Communicate intention to stop being a delegate at least 1 month prior to termination: Community Delegates should provide adequate notice to their delegators if they plan to stop serving as a delegate. This allows delegators sufficient time to transfer their tokens to another delegate.

  8. Delegates should engage in the debate process, take a position on governance proposals, and abstain in rare circumstances: Community Delegates are encouraged to take a clear position on governance proposals, expressing their support or opposition. However, in exceptional cases where there is a conflict of interest or lack of information, delegates may choose to abstain from voting.

We value your input and perspectives. Therefore, we invite you to share your thoughts on the proposed Community Delegate Code of Conduct and the implementation of delegation. Are there any additional guidelines you believe should be included? What measures do you think should be implemented to ensure delegate accountability and transparency? Feel free to comment below as your feedback will contribute to shaping a robust and fair governance system for Moonriver/Moonbeam.

In addition, there is an ongoing survey on vote delegation where you can get a chance to be one of 20 winners to receive $100 USDC by filling it out by May 31, 2023.

9 Likes
2

As for the risks associated with centralization: I would suggest simply putting a limit on the amount of voting power a delegate can get. Something like how we have a limit on the number of delegates on collators. But use the percentage approach. If a delegate gets (for example) 10%, then the function of delegating votes to this delegate is blocked (becomes inaccessible).

2 Likes
3

Hi @lyn , this is a great write-up, and thank you for sharing it, as well as the proposed Code of Conduct. A couple of questions:

Notify delegators about the rationale behind each vote

Is there a suggested way in which delegates should share the rational? I would imagine here in the forum as a comment to proposals would be the most sensible place, but maybe there are other thoughts on this.

Is there any community action which can be taken if a delegate goes rogue? For instance, I imagine many stakeholders that delegate votes will set the delegation and forget it. Down the road, a delegate may decide to use that power in a way that may harm the chain. As an example, even with a limit on voting power as suggested by @GodsHunter , there’s the potential that one delegate with a large amount of delegations could prevent important proposals from passing.

1 Like
4

I would think that the more options the better, Twitter is usually a common place where delegates post their rationale when they vote on a proposal / even individuals person do this

posting a msg in the groups( tg and discord) can also increase opinions and interest

1 Like
5

Hey, Lyn, I want to express my appreciation for this well-written post. Thank you for initiating this discussion!

Indeed, it is of utmost importance to introduce a feature that increases the participation threshold in governance. many community members fail to fully grasp the significance and necessity of engaging and expressing their thoughts, given that all changes are exclusively made through governance voting.

IMO, it would be sensible to consider implementing an entrance deposit for individuals / organizations aspiring to become delegates and receive delegations. this would serve as a safeguard in case a delegate acts against the network’s interests or disappears without notifying anyone. we could explore the possibility of implementing slashing or other deterrents to address hostile behavior by bad actors.

additionally, if major ecosystem projects like Stellaswap, Beamswap, Moonwell, Prime, and others become delegates, it raises the question of whether they could accumulate significant delegations and exert influence over voting outcomes, such as determining grant results.

regarding the delegation of voting rights, can any token holder delegate their vote, or maybe users can delegate only exclusively staked tokens??

If I’m not mistaken, in Cosmos, tokens can only be delegated to validators, and only those who stake Atom tokens can participate in governance. users who have revoked their stake are excluded from governance participation.

considering that collators possess greater technical knowledge, should delegates exclusively be collators, or is our main objective to allow any active network participant to become a delegate?

I believe that active influencers becoming delegates may lack a comprehensive understanding of the network’s intricacies and might vote without thorough research. their popularity and recognition could lead to them accumulating a substantial delegation threshold, potentially compromising the objectivity of the voting process.

It would be beneficial to contemplate measures to address situations where explicit conflicts of interest arise. for instance, several influential individuals might propose something that appears objective at first glance but is not, and by collaborating, they promote the proposal and use their majority votes to manipulate the outcome.

we should consider safeguards to prevent unintended consequences and maintain the integrity of the network.

IMO, delegates can provide explanations for their voting choices in the comments of specific proposals here on the forum. this approach would enhance objectivity and comprehension. additionally, duplicating these explanations on twitter would ensure that those who do not closely follow the forum can still be informed about the decisions made.

1 Like
7

Thanks @lyn for putting this together. Going through the post and also through the replies I do have some thoughts to share:

@GodsHunter → this is a great idea. Unfortunately I don’t think this is possible with OpenGov at a code level. Maybe we can do this at a UI level or at least warn the user and having the user at least check a checkbox that they acknowledge the risk.

To what @Jim_CertHum and @jose.crypto said - Agreed that a lot of the community might set it and forget it. Maybe we could implement a feature in which delegations expire after a certain amount of time, and the Moonbeam dApp will suggest you to delegate again? I’m thinking about how current democracies work. You vote on representatives and you basically “set it and forget it” and the representatives are expected to execute on your will (more or less). After some time, your delegation expires because their term comes to an end.

^ Definitely some food for thought on how we can improve

@turrizt - On Cosmos, IIRC, you automatically delegate when you stake your tokens to validators there, but I’m not sure if you can delegate to any other account. I don’t agree that censoring is the way to go. A the end of the day Web3 is all about decentralization and letting people express their opinions in a censorship-free environment. Some things should be considered tho, for example, when delegating, an UI should show roles that this person you are delegating to (for example, Collator, OpenGov Tech Committee, High-Particiation, or others). But if I want to delegate to Alice which is a newbie and just learned about crypto yesterday, I should be able to (although I would not do it haha!)

2 Likes
8

Hey @GodsHunter , thank you for your comment :raised_hands:
That is a valid suggestion. In fact, we did consider this option as a potential solution. It would serve as an effective deterrent against the concentration of power in the hands of a single delegate. However, as Alberto mentioned below, OpenGov on Polkadot currently does not have this feature. Since Moonbeam mirrors Polkadot, we are unable to implement it on our network(s) at this time. Nevertheless, it’s an idea worth considering for future enhancements and updates.

2 Likes
9

Hey, @Jim_CertHum ! We are thinking of having a dedicated page on the Forum for Community Delegates: sub-category in the [Governance] category where each delegate will have their own page. The Community Delegate will be responsible for updating their page the way they find necessary (we might need to provide a simple template first).

As for a “rogue” delegate - we are preparing a delegate dashboard which will reflect the voting behavior and on-chain activities of delegates. There will also be a “health score” that will reflect how often a delegate votes, participates in the Forum discussions, the number and types of community badges and NFTs they hold, etc. Instead of punishment, we are going the other way around - encouraging delegates to behave well for the sake of their reputation and social capital. That being said, if the community decides there should be some strict measures against those delegates who misbehave, it is up to them (the community) to propose and suggest what they think will be best for the network.

2 Likes
10

Hey @jose.crypto ! You are right, twitter should definitely be one of the places where Community Delegates share updates with their delegators. They can tweet the link to their Forum page every time they post it there (see my response to Jim about Forum page).

1 Like
11

Hey Turrizt! You come prepared, as always! And I really appreciated that about you :pray:

There are several issues you raise and I’ll try to address them one by one.
But before that, I’d like to say that I do not have all the right answers, and I’m sure there will be many changes in the future. We are after all breaking new ground here :slight_smile:

Regarding an entrance fee: anyone can become a delegate. In theory, you can delegate your own tokens, any amount, to yourself and become a delegate. The goal of delegated voting is to attract more voters to participate in governance, not create an extra threshold.

As for the ecosystem projects, you are right that the teams (members) can be Community Delegates. We do not and cannot prohibit that. In theory, they can accumulate large amounts of delegations and vote in grant proposals. However, I think those who choose them as their delegates would vote for them even if there were no delegated voting in place. Moreover, if the community comes to a conclusion that delegated voting is disrupting the grants process, it can propose alternative methods.

To your point whether Community Delegates should exclusively be collators: No.
Anyone can become a delegate, regardless of their skills and expertise. Sometimes, active community members can know and be involved in the ecosystem more than some collators.
I’m sure you will make an extraordinary community delegate yourself, Turrizt!

About conflict of interest: one of the expectations is that Community Delegate will be conscientious and disclose any conflict of interest in the Forum, and if necessary, abstain from voting. That being said, you are right, we should think about what the community should do in case the delegate chooses not to disclose it. I’d be interested in your thoughts about it.

2 Likes
12

I get it. Yes, then use this as a graphic warning. Something like a bright red marker. Perhaps in the future this will be possible at the code level as well.

1 Like
13

@AlbertoV19 @lyn – my main idea is not to endorse censorship or impose unnecessary problems or restrictions. however, I am concerned about the potential influence of a group of influential individuals who may hold significant voting rights but lack the ability to conduct proper research and possess basic knowledge in the governance process.these instances can lead to future problems, especially if these influencers gain more power. It is worrisome that many users and influencers may base their votes solely on market conditions, potentially rejecting numerous proposals that would greatly benefit the network and its ecosystem as a whole.

there is a risk that some delegates may lose interest, abstain from voting during crucial moments, collude, or vote against proposals that are clearly necessary and objective. It is of utmost importance to consider how we should respond to such behavior. I place great importance on this issue and believe that it is crucial to proactively anticipate various chaotic scenarios. by having a clear plan of action, the community can effectively address and mitigate such cases, thus preventing chaos

1 Like
14

Yeah I understand your concerns but censorship it not the real answer here. As @GodsHunter suggested maybe do some sort of notification mechanism when delegating, and showing something like Governance Centralization Indicator or something. Tools or indicators like this will help for sure. But this is a great point for discussion.

3 Likes
15

I’m uncertain whether this will be effective in cases involving influencers, as their community will delegate votes to them and they may not be concerned about it.

for instance, on stakeglmr/movr, there is a designation known as a community collator, but it seems that it doesn’t receive sufficient attention. I don’t want to exaggerate this problem, but it’s also important not to underestimate the influence of the community. In Kusama circles, there is a user known as HACN, who can significantly impact the outcome of votes in many instances. I would prefer to avoid a similar situation in our case

2 Likes
16

This is certainly an issue with democracies – even ones that are representative. It reminds me of the story that a US President told when he met another leader of a pseudo-democracy (more of a dictatorship). The latter basically said the world moves too fast now for democracies to keep up with the changes that governments need to adjust to, including changes driven by technology. I don’t agree with this viewpoint, but the scenario here could lead to some of the problems you describe.

And I agree with @AlbertoV19 that censorship isn’t a good answer. I don’t think the implementation of OpenGov permits an expiration of delegations, either. I think the most likely scenario, if a delegate does attempt to use power to cause chaos, is eventually enough noise would be made that people would act in their own best interest which would be to undelegate their voting power. Also of note is that I don’t think enough delegations could be made to implement something harmful – just delay change until that noise was loud enough that they would lose that power due to revoked delegations.

3 Likes
17

Anyone should be able to nominate themselves as a delegate, as not all collators participate in the decisions, some are simply limited to their role of keeping the node running effectively.

I personally don’t like that default delegate to their collator option, it doesn’t make sense to me

18

A UI like the one that Novawallet now manages seems fine to me, showing the delegates, a brief summary of who they are, and the amount they have as delegates, as well as if they are defined as an organization (DAO, company ect) or individual

Screenshot_2023-05-20-10-41-52-473_io.novafoundation.nova.market
Screenshot_2023-05-20-10-41-52-473_io.novafoundation.nova.market1080×2400 241 KB

19

I gave an example that is used in the Cosmos ecosystem, and there validators are required to take an active part in voting. the Cosmos community is incredibly involved in governance, so sometimes it makes sense to explore the strengths of other ecosystems. IMO, the collators are the most technical and active members, for me it makes sense, and that’s why I decided to mention it :slight_smile:

in Cosmos, validators have the ability to vote on behalf of their delegators, but delegators always retain the option to vote themselves or change their validator’s decision. this feature is quite valuable as it promotes a robust governance process. collators appear to highly value their reputation, suggesting that they will likely vote honestly and purposefully. additionally, this can incentivize collators who primarily focus on node maintenance to become more active participants in governance. It is essential to consider various possibilities and highlight encountered features, as they provide food for thought

1 Like
20

btw, Kusama has approximately 10k nominators, but the number of delegations is relatively low. additionally, HACN has the potential to disrupt the system at any time, which raises doubts about its effectiveness on Kusama. It might be worth taking this into account

21

I agree that we can and should look at the strengths of other ecos but honestly it seems like a bad idea to do it by default, that it appears as an option, it should be the right thing to do

since many nominators are to " set and forget", so with that logic they would not even know that they are delegating and giving voting power to that collator