[Proposal: 88] Moonbeam On-Chain Remark for Collator Guidelines and Request for Collator Self-Bond Change

Governance Democracy Proposals
,
1

Working with @Jim_CertHum, decided to use the submitted Moonriver proposal as a baseline for Moonbeam as well since it captured community comments that can work for both networks.

Abstract
This proposal seeks community agreement by remark to formally adopt on-chain guidelines for collator operators on the network and request a change to the minimum bond amount for new collators to 2,000,000 GLMR in a future Moonbeam runtime upgrade. The proposed guidelines will help ensure responsible behavior and establish clear expectations for operators, while the change to the minimum bond is intended to help maintain a diverse set of collator operators.

Details
This proposal seeks to obtain community support for an on-chain remark that articulates the community’s expectations for collator operators on the network.

Part I
The first part of the proposal is to formally adopt a set of guidelines to ensure that collator operators behave responsibly and always act in the best interests of the network and the community. While these guidelines have been informally followed and documented as community norms, codifying them on-chain will enable the community to explicitly adopt them and provide clear guidance to collator operators. It will also establish that there is the potential of penalties for operators who fail to meet these expectations.
By establishing clear guidelines for collator operators, the community can strengthen the network’s overall governance and promote greater trust between delegators and operators.

They are as follows:
Collators have a responsibility to the network to act honorably. If any of the following forbidden offenses occur, action may be taken via on-chain governance:

  • An entity is running more than two collators unless the community determines by governance that it is for the benefit of the network that an entity should run more than two

  • A collator is running multiple nodes using the same Nimbus key causing equivocation. Equivocation is the action of submitting multiple blocks at the same block height, which forks the network. It is strictly forbidden due to the network degradation that it implies. This can be done by a malicious actor (trying to get more blocks included/produced) or by mistake (having a backup node running with the same key). Each node needs to have its own unique keys and any backup solutions need to ensure there can be no possibility of equivocation

  • A collator acts in a nefarious manner that is uncharitable to the community or other collators

The community also expects collator operators to be actively engaged in the community as a reflection of their commitment to both the community and the network. This engagement is crucial for building trust with the delegators they serve. While the level of engagement is not strictly defined, some examples of what is expected include:

  • Be active in the community

  • Join the Discord and introduce yourself, provide updates as needed, and help support community members or other collators

  • Create tutorials and educational content

  • Become a Moonbeam Ambassador

  • Contribute to open-source software relating to the ecosystem

  • Join the official community forum and actively participate in discussions

  • Actively participate in governance and vote on proposals

Part II
For the benefit of the network, the community expects that collator operators will provide services in a manner that is in line with industry standards. If any entity does not provide a level of service expected by the community, action may be taken via on-chain governance.
Examples of the expected level of service from collator operators are as follows:

  • An operator should provide an on-chain identity with a Reasonable judgment with at least one verified communications channel

  • An operator should maintain a client version and at least minimum hardware standards in line with published requirements for the network

  • An operator should implement technologies and procedures that provide redundancy and failover to limit downtime while in the active collator set

  • When a collator fails to produce blocks for multiple consecutive rounds, reasonable efforts of proactive communication should be initiated by the operator to the community, including actions that are being taken to resolve the problem

The community may use on-chain governance when any of the guidelines described in Part I or Part II of this on-chain remark are not adhered to. Specific actions that may be taken (but not limited to) include:

  • Removal of an individual collator or set of collators from the active set

  • Slashing of collator self-bond

  • Permanent ban of the entity from participating in the collating function on the network

Part III
Over the past three months, the community has engaged in active discussions on strategies for maintaining a diverse collator set. The discussion can be found in the link provided at the end of this proposal.

This proposal requests that changes are made in the next Moonbeam runtime upgrade such that a new potential collator must have a bond of at least 2,000,000 GLMR in order to be considered eligible and become a collator candidate, and this figure will be reviewed as deemed appropriate by the community. Additional information on the minimum bond requirement can be found in the link at the end of this proposal.
Some benefits of making this change include:

  • It is expected to discourage the use of a strategy where an operator self-stakes tokens to become active in the set, and then gradually reduces their self-stake while gaining community delegations, only to use that self-stake to add additional nodes.

  • The increase in bond rebalances the amount of capital lock-up required to run a collator, closer to the original levels at network launch, which have been skewed due to current market conditions.

  • This change can be complemented by other measures, such as reducing rewards on bond, which may further increase the stability of the collator set and decrease instances of mass un-bonding where delegators do not receive rewards.

Links
Forum discussion on ways to maintain a diverse active collator set

Collator Bonding Requirements

6 Likes
2

I support this proposal because I very often hear concerns from delegators that their collator does not produce blocks because it has some technical problems or it has been knocked out from the active set and they cannot contact it to clarify collator plans. we also noticed that large entities have started running a large number of collator nodes, thereby knocking the small community collators out of the active set, which, in turn, creates a big problem for delegators, since they stop receiving rewards, and they need to suffer from this. by supporting this proposal, we can provide a more stable and secure collator set that will benefit both delegators / collators and the community as a whole :slight_smile:

6 Likes
3

I agree with your words

2 Likes
4

The Moonbeam collator set has been run over by large organizations that have access to VC funds and/or customer deposits in exchanges. These orgs advertise “non-custodial staking” (in some cases, it is obviously custodial), “no slashing” (there is no slashing in Moonbeam) and maximum APRs to their clients, all while they fail to:

  • stay consistently online
  • stay consistently in the active set
  • not miss blocks (poor performance when online)
  • allocate capital efficiently

The problem with these orgs is that they are not incentivized to look after their nodes. Their access to funds allows them to slack and not care because they can always refill. This deteriorates the experience of delegators. In some cases, these operators perform so badly they would be better off themselves not running nodes and simply delegating their capital to well-performing collators. This is a lose-lose situation, for them, the network, other collators, and delegators.

At the same time, these operators always take multiple nodes (sometimes more than they are allowed to while trying to hide their tracks). As a result of this, half of the community collators that worked hard to offer all of the above, have now been replaced by anonymous nodes and a few large operators.

Something’s gotta give, and I believe this proposal is in the right direction.

7 Likes
6

Agree with this proposal, this has been discussed at length. We, Brightlystake are in full support of this proposal. We believe this will bring a greater good.
Cheers

3 Likes
7

Thanks for moving this forward @blackk_magiik. I fully support the proposal. Having a documented set of guidelines will give delegators assurance that collators understand and have clarity on what is expected of them. It also leaves no room for doubt that collators must meet minimum standards to operate on the network. Overall it should strengthen the Moonbeam network if approved by community vote.

3 Likes
8

TrueStaking is 100% supportive of this proposal for the reasons articulated by @turrizt and @stakebaby.

2 Likes
9

thanks for putting this up @blackk_magiik - well done
as has been previously mentioned and discussed at length - pathrocknetwork fully supports this proposal - hopefully being a step in the right direction to maintain a diverse collator set. It does however keep other community oriented collators out, as for them 2,000,000 GLMR is a lot.

2 Likes
10

Does this mean all Collators would require 2,000,000 GLMR bond?

11

no, this is just a draft proposal, then, after collecting feedback and, if there are any suggestions, adjustments will be made to the proposal, then the proposal will be put to an on-chain vote, where the community will decide by voting whether they agree with this proposal or not. If this proposal passes, then all new collators will need to have a self bond of 2M in order to run the collator node and get into the waiting set

1 Like
12

Thanks @turrizt ! As Turrizt explained the new minimum bond will only affect new collators joining the pool. Existing collators will be exempted in.

@paddyson We did discuss this in another forum and yes it could prevent some potential new community collators but there is the Orbiter pool as an alternative solution. This proposal is more to align with the initial bond requirement at the launch of Moonbeam and adjust to current market conditions.

1 Like
13

the minimum bond amount for new collators to 2,000,000 GLMR in a future Moonbeam

Are you talking about self stake for collators?

14

yes, this is the proposed minimum amount of tokens staked (self-bonded) to be considered eligible and become a candidate

2 Likes
15

First, thank you for your suggestion.
And second, I want to say that if this proposal is put to a vote, as it looks now, I will definitely vote against it.

I don’t think that having a 2 million threshold doesn’t help the issue at all. Instead of creating an opportunity to attract good collators with a team of experts who know what it is to validate a network, you create an additional hurdle. The large threshold of self-stake has already resulted in large companies being among our collators. As practice shows on other networks, the largest validators are not interested in managing the network. Who will we attract by setting such a high self-stake? A big company, a rich person, a foundation that wants to run a miner that will mine money for them while they do nothing? Of course, there are also those among foundations and companies who are useful to the network. But it is very rare. For most validators who really do their work and develop their validator, it’s not an affordable amount. And they will never validate Moonbeam or Moonriver. Even though they could do a lot of good for the network.
2 million GLMR its are almost $800 000.
We still have a high threshold for hitting the active set today.

Validators/colliders who can afford that amount almost never do it:

They don’t need it. Because they can afford to validate the network with their tokens. And the reward system for delegates is such that they will pick the ones with the best percentage of awards. So we have a fairly small difference in steak size among collators. In other ecosystems, the system of delegations from foundations and the project team helps stimulate collators to be active. But large validators are still not interested.
If you observe how updates happen on the another networks, you will also find that small validators are updated before large ones. In the first minutes. They latter may remember it the next day. This is because the former are more motivated in their work.

Such an initiative looks like an attempt from the community to get someone to buy more tokens, to raise the value. This amount helps protect against something. But it also creates other problems. For example, Moonbeam/Moonriver has ambassadors. Who have both the technical and humanitarian knowledge to run a collator. Who better to run a collator for a network than an Ambassador? And I know there is such a desire among my colleagues. But they will simply never be able to afford to do so with such demands.

I agree that we need a kind of red button.

One of the main problems is that at the start of the network we didn’t do enough community outreach regarding collators. And various collators started showing up promising drops for their delegates. Thus many genesis validators dropped out of the active set. Among them were indeed those who were interested in the network. I helped one such validator with collecting delegations. But he still couldn’t keep up. A system with reward payments based on steak concentration certainly allows you to keep the network decentralized. But also with this system, most delegates are not interested in supporting any particular collator. They will choose the ones with the highest rewards, while having less risk that the collator will leave the active set. Banning a second collator will only help combat the fact that there will not be a collator with the same naming. If he has the means, he will start the second collator under a different name.

Finally, I would like to say that I am also concerned about the problem of collator passivity in the network. I validate some networks in the Cosmos ecosystem. So I have some vision of how active a collator/validator should be. And some work is also being done in relation to this issue. Unfortunately I can’t share it yet. But hopefully in the near future, this will also form into a full proposal.

P.s. And I also agree that we need to work with current collators. If it has a bad result, then get rid of them and get better ones.

2 Likes
16

That’s what I’m talking about, but small validators will never be able to get into an active set with the proposed bond.

17

Hey man, please read the following discussion from head to tail

The idea behind increasing the bond is fairly ingenious and it is not in isolation. I understand why you might think it favors big players, but if you do a little bit more homework by reading the above you will see this is not the case.

18

In what way? I don’t see this quote as an answer.

19

In the way that it protects the current community collators who have been largely disseminated.

Please read the entire discussion though.

20

You need to understand that in the current situation, when the minimum to become active is about 3.5m GLMR, it’s much easier to whales who don’t really care about the network to become active rather than ambassadors and people with less capital or access to capital who do care.

If you check the recent activity in the last months, you’ll see that this exactly what happened - many whales, big entities joined and not little ones.

The whales easily raise the minimum to become active and then they usually kick community collators who been there from the first day, who really had a comminity behind him. The moment we increase the self bond (and make it in $ value quite similar to what it was when GLMR price was few bucks) and remove the self rewards, we let them think twice before they do that. Of course we make it harder to other good people who want to become a collator, but they aren’t our target, and for them there is also the Orbiter program (where you can find ALL the community collators from day 1 who were kicked out by whales)

In the future, we can adjust it back (depend on GLMR price), but now if we really want to keep the collator set decentralized, robsut with collator who are totally into Moonbeam (and not just 18 entities with 4 collator each), then I would recommend you to vote Aye

(p.s I’m not a community collator like the others from day 1, my self bond is 100k and I’ll definitely going to suffer from removing the self reward but I’m totally fine with that because I know it’s the right thing to do)

3 Likes
21

Hi Everyone,

Greatly appreciate all the feedback and comments on both sides of the debate! Plan is to submit for proposal based upon the general feedback of support. So far seems the suggested proposal is in favor of being submitted. Plan to submit come Friday March 17th, unless the community disagrees otherwise.

3 Likes