Proposal to Optimize the Commission Setting Mechanism in Polkadot Staking

Tech Talk
1

Proposal to Optimize the Commission Setting Mechanism in Polkadot Staking

Background

In Polkadot’s staking system, validators can freely set their commission rates, and these changes take effect immediately. This mechanism allows validators to set commissions to 0% for extended periods to attract nominators, only to increase the commission just before reward distribution, thereby securing disproportionate profits. For instance, examining the reward history of a validator account (e.g., 16ccn3xe5tAeR8kvzCRTcqHZjMJHvuF2pnLfTqyF1EmMusCU) reveals behavior that may confuse nominators and lead to unexpected returns. Such practices not only obscure transparency for regular users but also undermine the fairness and stability of the Polkadot ecosystem.

Problem Analysis

  1. Information Asymmetry: Most nominators lack the tools or resources to monitor real-time commission changes, making it difficult to detect last-minute adjustments by validators.

  2. Erosion of User Trust: Frequent or manipulative commission changes can result in nominators receiving lower-than-expected rewards, discouraging participation in staking.

  3. Impact on Ecosystem Fairness: This behavior allows some validators to attract nominations with “bait” low commissions, only to raise rates later, which disadvantages honest validators.

Proposed Solutions

To address these issues, the following optimizations are proposed to enhance transparency, fairness, and nominator protection in the staking system:

1. Introduce a Commission Adjustment Lock Period

  • Proposal: Implement a lock period (e.g., 7 days or one epoch) during which validators cannot modify their commission rate again, with changes taking effect only after the lock period ends.

  • Benefits:

    • Prevents validators from making last-minute commission hikes before reward distribution.

    • Gives nominators sufficient time to understand and react to commission changes, reducing information asymmetry.

    • Enhances predictability and stability in the staking system.

  • Implementation: Add a parameter to Polkadot’s on-chain governance to restrict commission adjustment frequency and record the effective date of changes.

2. Enhance Transparency of Commission Changes

  • Proposal: Require validators to announce commission changes via on-chain events or notifications, with historical commission data clearly displayed on blockchain explorers like Subscan.

  • Benefits:

    • Nominators can easily review a validator’s commission adjustment history to assess reliability.

    • Increases validator accountability and encourages honest behavior.

  • Implementation: Integrate a “Commission Change History” tab in Subscan or similar explorers, showing a validator’s past commission adjustments, triggered by on-chain events.

3. Cap Commission Adjustment Magnitude

  • Proposal: Limit the extent of commission changes within a single epoch or time period (e.g., a maximum change of 5% per adjustment). Significant changes would require multiple gradual adjustments.

  • Benefits:

    • Prevents validators from exploiting large commission hikes for excessive profits.

    • Protects nominators from extreme commission fluctuations.

  • Implementation: Enforce commission adjustment limits at the protocol level via on-chain logic.

4. Implement a Nominator Alert System

  • Proposal: Develop an on-chain or off-chain alert system to notify nominators of commission changes (e.g., through Polkadot.js or Subscan push notifications).

  • Benefits:

    • Enables nominators to promptly review commission changes and reassess their nomination choices.

    • Improves user experience and strengthens trust in the staking system.

  • Implementation: Integrate notification functionality into Polkadot.js or Subscan, allowing users to subscribe to alerts for commission changes by specific validators.

Expected Outcomes

These optimizations aim to address the shortcomings of the current commission mechanism:

  • Improved Fairness: Restrict manipulative commission adjustments to protect nominator interests.

  • Enhanced Transparency: Public commission histories and alert systems reduce information asymmetry.

  • Healthier Ecosystem: Encourage validators to adopt stable, long-term strategies, boosting overall trust in Polkadot’s staking system.

1 Like
2

I found this relevant.

3

Hi there, I am a validator operator on both Polkadot and Kusama, so I will reply to this suggestion from that perspective.

In general, while there have been a few high profile incidents in the past, I believe that the issue you bring up is relatively uncommon. With that in mind, I think proposed solutions should be relatively limited, at least for now. So here are my thoughts on each of your proposed solutions:

I do agree with this, although I think it should be very short – i.e. it should be long enough that nominators have the opportunity to reject the change by updating their nominations, but no longer than that. So, I feel one or two epochs should be sufficient. There may be legitimate unforeseen circumstances that would justify a quick change in a validator commission rate, and I wouldn’t want to get in the way of that.

Commission changes are already announced on-chain, but I agree there should be better visibility of these events on Subscan or on the staking dashboard. I would suggest the staking dashboard could show recent commission changes, or allow filtering based on them.

I’ve long had an idea for a nominator monitoring tool that would send alerts to nominators when their validators change commission, get chilled or slashed, or other important events. As a validator I use a tool called SubVT to monitor my own validators and it alerts on those events. It is designed for validators though, not nominators. I don’t think it would be hard for someone to create something similar for nominators to track the validators they have nominated. There is also https://www.dozenodes.com/polkadot which, again, is more geared for validators than nominators, but it contains a wealth of information that could be useful to nominators including history of commission changes (click on a validator on that page to see the history for that validator).

I don’t like this one as much. I think there are potentially valid reasons for a validator to significantly change their commission structure and I don’t want to create unnecessary obstacles for that. For example maybe a brand new validator that is intended to be 100% commission accidentally set their commission to 0%. A rule like this one would make it very difficult for them to fix the mistake.

What I think could be a reasonable compromise here is something like, if you want to make a change greater than x% (whatever limit is agreed upon), then you must start over by losing all existing nominations. I’m not sure how technically feasible this would be (since nominations are associated with the nominating account not the validator, and there could be thousands of nominators for a given validator), but having some mechanism for a validator to reject nominations (or in this case forced to reject nominations) could be useful in some cases. We already allow validators to not accept new nominations, but as far as I know there is no way to remove existing ones.

Yes, I totally agree with this. I’ve wanted to do this myself, but simply haven’t had the time to. A bot on Telegram or Element could also serve this purpose. The information exists on-chain already, so such a tool just needs someone to decide to build it.

2 Likes
4

I thought there already was a delay in implementation? My understanding was that it took an era or 2 for some changes to be applied. If not, it should be that way at minimum.

5

I’m not entirely sure about this because I’m not a developer and can’t verify it through code, but I believe some nodes operate as follows:

They set a high commission before the end of the fifth epoch in each era, then lower the commission to near 0 in the sixth epoch.

My understanding is that adjustments made within an era only take effect in the current era if they are made before the end of the fifth epoch (and actually apply in the next era). If the operation is performed in the sixth epoch, it will take effect in the next era, and thus be applied in the era after that.

The speculative aspect of this process is that validators lower the commission to 0 in the sixth epoch of the first era, but this operation is only considered effective in the second era. At this point, the actual commission in the second era is the high commission set in the fifth epoch of the first era. However, in the fifth epoch of the second era, they set a high commission again, which effectively overrides the commission of 0 that was recorded for the second era. As a result, the second era’s effective commission is also high and takes effect in the third era.

Ultimately, for most of the time (from the sixth epoch of the previous era to before the commission is increased in the fifth epoch of the current era), the on-chain query shows a low commission setting, but the actual effective commission is always the high commission that exists briefly but is applied.

6

A simpler solution to address this issue: when querying the commission on-chain, return the actual effective value instead of the latest operational value.

7

Thanks for raising this! The issue is indeed real; atm validators can change their commissions at the very end of an era. Later on, this new commission is used when claiming the rewards.

To explain the thinking behind this; Nominators are meant to be active agents who scan validators for misbehavior, and un-nominate them if they see such behavior. This is the main reason we have not addressed this with high urgency. Being a nominator is not meant to be free money, but rather doing exactly such jobs.

That being said, I am not against for example delaying the validator commission update by 1 era. It will be a rather easy change.

Quite the contrary, nomination pools are meant to be a “simple solution for new joiners“ (often with small amounts of DOT). Deliberately, we baked a number of commission restrictions into nomination-pools to protect new users from such behavior. In other words, in Nomination Pools, if you choose a pool “wisely”, it is expected that you “stake and forget”.

More info on the nomination pools commission options:

2 Likes
8

I think this is an interesting proposal that addresses a real issue.

This is indeed the theory and expectation, unfortunately I fear many nominators do not monitor the validators they select for staking (or at least not often), not only in terms of commission but also in terms of performance and downtime. Sadly, some validators take advantage of this situation.

Note: I am also a validator and I use SubVT and Turboflakes to keep track of my validator nodes.

Having nominator specific tools available would facilitate their responsibilities and would encourage them to change their nominated nodes if they observe foul play or bad performance, in their own interest of receiving more rewards.

Additionally, I would hope it also encourages validators to be honest and transparent about commission changes, as well as motivated to keep their nodes up to date and aim for good performance in order to keep their nominations.

This would be a win-win, improving also the security of the network.

I don’t think these two changes are necessary (lock period & limit commission changes). I do support your other ideas of using alerts and transparency of historical commission changes as well as nominator specific tools as described above.

2 Likes
9

What is the sentiment on forcibly removing misbehaving validators from nominator bags and slashing their self stake via governance?