Stale Nomination Reward Curve

[shawntabrizi]

Would like to start a conversation, pre-RFC, about an idea that was brought up while at Sub0 Asia 2024.

The high level goal is to create some incentive / pressure for nominators to re-nominate in some regular frequency, with the hope that we can better identify the best validators for Polkadot at any given time.

The problem is that many nominators have stale nominations, that is they nominated some of the OG validators back when the network first launched, and perhaps have not updated their nominations for months / years.

The NPoS process will better identify high quality validators, and allow new validators into the set, when nominators are updating their nominations.

A proposed solution to this problem is to create a decreasing reward curve on nominator payouts based on the last time they submitted nominations.

For example:

Imagine a simple curve which is flat at 1.0 until 6 months. Then linearly decreases to 0 for the next 2 years.

A nominator will receive their full staking rewards for the first 6 months after their original nomination. However, after 6 months, if they do not submit a new nomination extrinsic, they will start to receive slightly lower rewards. For example, at 1.5 years since their original nomination, they will only receive 50% of their potential rewards.

The first important detail to note is that this mechanism does not force anyone to do anything. It is simply an economic pressure to incentivize a behavior. I also want to note that this mechanism cannot force nominators to pick different validators. In fact, we might expect some nominators to pick the same exact set of validators every 6 months. This is okay, and allowed by this mechanism. We do NOT want to force the selection of random new validators when a nominator feels that a certain set of validators are best.

However, this pressure to at least submit a new nomination extrinsic I believe will be enough pressure for people to evaluate if their current selection can be improved. There are new dashboards and metrics every day which are telling us more information about the quality of validators, and validators have had more requirements to perform as of recently (with beefy, parachains, etc...). My guess is that some pressure like this would be a strong net benefit to the security and quality of the network.

Second to note is that this curve should be easily configurable. I suggest above some values just for the sake of illustration. Whether we tune the curve to start decreasing at 3 months or 6 months, whether we tune the curve to go all the way to 0 or stop at .5, and how long it takes to get there are all things which can be easily updated. The curve could also not be linear. Thankfully with OpenGov code, I believe all the logic needed for many curves are already part of the Polkadot-SDK. I think my suggested curve is not so bad as a starting point, but would not push back on less or more aggressive configurations.

Finally, I want to note that I believe this features adds little overhead to the staking system, and can be easily implemented in a fully scalable way. The only thing we need to introduce here is:

• An additional field in the storage of nominators which tracks the block number the last time they submitted a nomination.
  • The additional value will be a field on an existing storage, not a new storage, thus the overhead to weights and benchmarks is nominal.
  • This value will be updated when they next call nominate, and requires no changes to the end user experience.
• A static and configurable nomination reward curve that defines a global behavior for all nominators.
• A single lightweight calculation, during payouts, which will adjust the final payout to a nominator based on their last nomination block and the nomination reward curve.

A potential migration would be needed to update the storage of all nominators to include the new "last block nominated" storage field. There are probably methods we could use to migrate to this lazily, since things won't affect end users for 6 months anyway.

From an economics perspective, it is possible that this curve decreases the rate of inflation of the network where stale nominators are not getting their maximal possible payouts if their nominations are stale.

Not included in this write up is brainstorming on how we can expose this new feature to end users and UIs, and how we can make the experience better for everyone. But open to those discussions below.

Overall, I think this is a simple but high quality improvement we can make to our network.

[bkchr]

Don't you think that this will just bring up people to write bots for doing this?

IMO we need to improve reporting to nominators. I mean we have already seen on Kusama that some validators are getting less rewards. So, there is already economical pressure, but nominators don't seem to care. We should rework the reward points to ensure they are rewarding better actual work that matters for the chain.

[shawntabrizi]

Don't you think that this will just bring up people to write bots for doing this?

I don't think the average of the 22500 nominators (i.e. a random DOT holder) is the kind to write scripts.

But if they wanted to, then sure, let them. Perhaps they will write a script which finds the best nominators based on some API metrics.

I do NOT think the average nominator will run a long term VM, so that a simple script can run once every 6 months. I think most people will go to a UI like Polkadot Staking Dashboard, and ideally go through their selection process again.

If this was targeted at the validators, I would say that the likelihood of scripting would be high enough that it is not useful.

IMO we need to improve reporting to nominators. I mean we have already seen on Kusama that some validators are getting less rewards. So, there is already economical pressure, but nominators don't seem to care. We should rework the reward points to ensure they are rewarding better actual work that matters for the chain.

I think this is also a good idea, but does not need to be one or the other. We can have both. I like this suggestion because it places a regular frequency for users to interact with the staking system (which is already a sensible behavior), and can be implemented easily and efficiently.

I think that also adjusting reward points, along with this suggestion will allow users to see every 6 months that they are being under paid, versus right now, they probably fire and forget.

[SimonKraus]

I absolutely love the fact that we think and talk about these things. The stickyness of stake is insane and I bet many nominations are around from pre-redenomination.

My concern is that most of these sticky i-don't-care-nominations are from large holders which don't actively care for their nominations or the network. Might happen easily that they just never realize why their rewards go down and therefore the whole thing might not have big effect.

I would rather think about turning around that mechanism and instead of lowering the nominators rewards over time make the nomination less effective for the validator.

For example: A fresh delegation has 1.0 x delegated_DOT backing-power and after 6 months that backing-power goes down until a point where the delegation has 0 x delegated_DOT backing-power after 2 years. This way the validator would lose backing and might be phragmen'ed out for an active validator that has responsive and caring nominators.

[gavofyork]

Rather than burning the rewards of less active nominators, did you consider handing it to the more active nominators? There should be even more incentive this way as not only is there a stick, but a carrot too.

[burdges]

We definitely want nominators to do the work of nominating, but we should avoid nominators carrying their stash keys with them. We'd one good story for this with controller keys aka free staking proxies, but they're already depricated. Afaik, our proxies are not so expensive, but folk still complain, which makes me worry, so..

We'd ideally have some cheap zero-storage certificate based replacement for our current storage based proxy systems before doing this.

In essence, your stash would create & sign a certificate that delegates some staking powers to a delegee key aka proxy key, but this delegee key need not exist anywhere in storagem and thius requires zero ED itself. Instead, delegee keys post their full certificate on-chain with each tx, but the certificate would be shorter than the extra merkle proof required by controllers/proxies.

This certificate has the size of the delegation statement, including the 32 byte stash and 32 bytes delegee keys, plus a 64 byte signature. In principle, the certificate could live entirely in polkadot.js, so then the delegee key could live in vault like a normal key.

As an alternative, we could employ implicit certificates, which schnorrkel supported from day one and closely resemble segwit. Implicit certificates are 64 bytes shorter, so just the size of the delegation statement plus 32 bytes, so maybe 70 bytes with everything. Implicit certificates would require vault itself understand the certificate format though, and delegee keys cannot be exported via words like other keys.

All certificate schemes need expiration dates and a revokation path, meaning a stash can revoke a certificate within its own record.

We started with on-chain controllers instead of certificates only because folks obsesse over blocksize, but nobody realized how overpriced the ETH trie is. We'd ideally have moved directly form controllers to certificates, and never implemented proxies, but path dependence exists everywhere.

Anyways..

I kinda suspect re-nominating often indicates nominators who optimize their own rewards over the interests of polkadot.

You cannot "write a script which finds the best [validator operators]" from polkadot's perspective, because that means not byzantine now or in the future. As an approximation to this, we should really ask nominators to assess the character, competence, and independence of validator operators.

We've little chance they'll access sysadmin competence unless validator operators start speaking publically about operational security topics. Just fyi, Tor achieves this via their extensive outreach and relay operator meet ups, but those discuss many concerns like "how to talk to cops."

We could push nominators towards assessing validator operators character and independence though. Again meetups help here, especially if one believes you should never nominate a validator operator unless you've met them in person.

Actual ideas..

We should do more outreach about what being a good nominator from polkadot's perspective means, including commants that this minimizes slashing risk. In this, we could organize validator-nominator meetups at conferences, primarily our conferences, but really any where we've some presense. This would make our ecosystem look (and be) more competent.

As I think @bkchr suggests, we could make your nominated validators appear more prominiantly in polkadot.js and other staking platforms, including direct links to validator operators blogs, twitters, etc.

We could try our own centralized off-chain channel through which validators send signed message to their nominators. We've many messangers in the world today, so one could imagine many options, but probably a simpler "validator blog" interface serves our interests better. Assuming validators appear promenently, recent blogs by validators you nominate could show up in your staking interface.

We've designed a rewards scheme that captures the critical activities, even availability. We suposidly have too many validators run crappy machines, probably cloud VMs, so correct rewards should result in them missing some backing jobs. We simply promote this reality once rewards work correctly, so then everyone slowly learns from our outreach.

[shawntabrizi]

@SimonKraus If I understand your suggestion, a curve on the nominated dot would basically cause the same effect of lowering the rewards the nominator gets, but also cause effects on who is in the nominated set.

I think this might actually align with what @gavofyork is also suggesting by creating both a reward for those who are updating their nominations, and punishing those that are not, since those with updated nominations will now get a bigger chunk of the rewards than their stale counterparts.

I am not sure if we can implement it just as easily as the payouts, but I will certainly look at it, and if lowering of delegation itself is a desired behavior, then we can do it.

@burdges

We definitely want nominators to do the work of nominating, but we should avoid nominators carrying their stash keys with them.

I think on the order of one transaction per 6 months is not that scary, and should be doable with proxies as you mentioned. Perhaps we could make it so that anyone staking gets a free staking proxy. In any case, not updating their nominations once per 6 months is probably certainly bad (on average) for the overall security of the network.

Actual ideas..

I think all of these are great, but work even better once you have nominators periodically interacting with the network. We can create all of these channels and outreach and whatever, but if they are not seeing them, it makes no impact. Having users interact with the chain on some reoccurring time period at least ensures that they can see these kinds of things.

But yeah, ultimately a mechanism like this would not need to exist on chain if most nominators truly understood their role in the security of Polkadot. But unfortunately they think of it mostly as passive income, and thus I think we need to bring these kinds of mechanics in.

[burdges]

We definitely want to break the idea that staking is passive income, and yes once every six months feels harmless, but we should not make checking nominations all the time some sacrement either. In fact, interacting too much on-chain actually provides evidence of reward chasing that harms security.

Attach scenario: Attackers controls DOTs for k validators, which they spin up, nominate themselves, set commission to zero, and engage with community to attract nominators who actively chase rewards. After these validators recieve enough nominators, then attackers launches another k validators using their own take. After n iterations they control k*n validators, so they sell their DOTs, and engage in an attack with nothing at stake. This is one of the reasons we want a minimum commission.

In fact, they could simply get themselves slashed, report the slash themselves, and walk away with some of their their nominators money. This is why the rewards for slashing reports must be kept low, like maybe 1%.

We might say six months, but if we promote this as "check your nominations more", then some precentage starts optimizing weekly, which worsens this vulnerability. It's our outreach that matters more than our code change here.

work even better once you have nominators periodically interacting with the network

It's kinda the opposite of what you imply here. They already interact regularly, by selling DOTs to price average to pay their taxes.

The actual regular work of nominating is in the nominators head, aka they should assess if they like their nominations. The simplest "gameification" of this is just making their nominations more prevelent in the staking interface, meaning they see them when they connect to do anything else. Afaik incentives matter relatively little without this interface change, aka gameification is about interfaces, not incentives.

[kianenigma]

This suggestion is pointing out a real issue: NPoS works the best with (possibly) fewer but more active nominators than the opposite, we all agree on that, and I believe it is pretty uncontroversial.

I do have worries about people deploying a "bot" of some sort as @bkchr mentioned, but at the same time, since there is no better alternative, I am in favor of implementing this, and letting the network play with the parameters to see if it is useful or not.

IMO we need to improve reporting to nominators. I mean we have already seen on Kusama that some validators are getting less rewards

I don't think we can get much better at this. Staking dashboard and other UIs are already pretty encouraging towards nominators to be active, but you can't do anything about someone who doesn't even open any dashboard. We don't have any way to reach the 22500 nominators of each network either, so it is hard to "inform" them that there are economic incentives for them to chose different validators.

Finally, I want to note that I believe this features adds little overhead to the staking system, and can be easily implemented in a fully scalable way.

Correct.

Moreover, I would add a few more points that could be bundled with this initiative to make it more successful:

• Ideally we want fewer nominators, and more pools. Therefore, we should make pools equally convenient to participate in even for big holders. The only major disadvantage of pools at the moment compared to direct nomination is https://github.com/paritytech/polkadot-sdk/issues/445. In other words, switching pools is costly (you lose 28 days of staking rewards), but switching nominations is free.
• Moreover, pools have the benefit of claiming rewards when the nominator wants, which may be beneficial for accounting and tax reasons
• Both the UI and the protocol should allow a smooth transition whereby a nominator is prompted about their inactivity, and are suggested to either:
  • be more active
  • join a pool with 1 click.
• Moreover, active nominators should be prompted to "upgrade" themselves (similarly with 1 click) to a pool, and possibly claim an extra pool commission for their good choice and allowing others to subscribe to them.

Side note, the fact that we have pools and nominators now is a technical debt on the implementation side. Conceptually, all nominators should be "delegate-able" i.e. all 22500 nominator slots should be used by pools, and end users who wish to be less active should just join a pool. @ank4n is already working on the refactoring needed for this, but it will be a more long term effort. Code wise, you can imagine something like:

[jonasW3F]

Shawn and I recently discussed this during our meeting in Singapore, and I am very much in favor of such a mechanism. Polkadot is paying their nominators 15%+ APY to actively curate the set of validators and optimize their nominations, but empirical data shows that a large share simply “sets and forgets.” I recall examining the actual data and found that, of those active in the last six months, 77% did not update their selection. I am sure their staleness extends even farther into the past. I highly doubt that any of them actually checked on their selection. In short, Polkadot gives nominators a huge reward for a job that many of them do not properly perform.

Here are some additional thoughts:

• We should find a feasible implementation that not only reduces the rewards for stale nominators but also extends this effect to the backing of their respective validators. While this “stale backing” will always be fully slashable, it should not contribute to the NPoS election calculation of those validators. This has the benefit of exerting pressure on validators to keep engaging with nominators, trying to “regain” them. For the network, it has the benefit of potentially removing some of the old validators that were added at the beginning. This could lead to a well-deserved rotation in the validator set. Or maybe not, but at least there will be some pressure for nominations to be reconfirmed.
• Once word about this gets out, people who are only remotely interested in interacting with Polkadot but still want to hold their DOT in their own custody will have the best interest in joining staking pools. I’d say this would be a good development.
• I think we should use a mechanism that redistributes the rewards deducted from stale nominations to those that are not stale. Given that we might soon see lower inflation on Polkadot, which would necessarily lower staking rewards for all nominators, we should allocate more rewards to those nominators who actively perform their tasks. I am sure there is some smart technical way to achieve this without too much complexity.

The point about bots is valid, of course. But I don't think a whole lot of people would do that and even if only a few people are nudged to spend more time looking at the validator set and making their selection, it’s already worth it.

[burdges]

Polkadot is paying their nominators 15%+ APY to actively curate the set of validators and optimize their nominations, but empirical data shows that a large share simply “sets and forgets.”

Again, actively changing suggests worse nominator behavior: A nominator who nominates only their friends provides the highest quality nomination information, but might never change their nominations. A nominatior who changes frequently likely chases yield, which makes them easily manipulatable, which makes the nomination information they provide almost worthless.

It's possible a "set & forget" nominator did their job. It's basically impossible a nominator who actually changes does their whole job.

Again, some simple reaffirm after 6 months would not be too problematic, but we definitely send the wrong message by doing this. If we do an RFC for this, then we should explain that this is a harmful feature, but we want more engagement, and really helpful engagement features are much much harder.

An example of a helpful engagement feature: All validator operators have a MOTD which their nominators read. We decreates rewards if you do not read some MOTDs from your nominations for 6 months. It's harder to assess reading messages though. Also, doing a MOTD requires much more work than this feature.

[jonasW3F]

Polkadot is paying their nominators 15%+ APY to actively curate the set of validators and optimize their nominations, but empirical data shows that a large share simply “sets and forgets.”

Again, actively changing suggests worse nominator behavior: A nominator who nominates only their friends provides the highest quality nomination information, but might never change their nominations. A nominatior who changes frequently likely chases yield, which makes them easily manipulatable, which makes the nomination information they provide almost worthless.

It's possible a "set & forget" nominator did their job. It's basically impossible a nominator who actually changes does their whole job.

Again, some simple reaffirm after 6 months would not be too problematic, but we definitely send the wrong message by doing this. If we do an RFC for this, then we should explain that this is a harmful feature, but we want more engagement, and really helpful engagement features are much much harder.

An example of a helpful engagement feature: All validator operators have a MOTD which their nominators read. We decreates rewards if you do not read some MOTDs from your nominations for 6 months. It's harder to assess reading messages though. Also, doing a MOTD requires much more work than this feature.

I assume a "reaffirming extrinsic" that does nothing but to reset the counter is strictly planned for this mechanism. Then, reaffirming is much less costly than finding a new set of validators, so I don't see how this drives people not to nominate their friends anymore.

[shawntabrizi]

@burdges I hear your line of reasoning, but I strongly disagree with it given the timelines proposed in this idea. If my proposal suggested an update once a week, I could agree with you that this is pretty useless. But it feels to me impossible that over the course of 6 - 12 months, that nothing relevant has changed which would influence the majority of nominators from making better selections for the network.

1. Each nominator is given 16 people they can nominate. Even if they have super strong selections for the top 10, you can imagine once you get to the bottom 6 people, it is likely that higher quality validators could appear which would be a better choice for these nominators.
2. There is nothing that requires the nominator actually change any of their selection. If they have selected 16 friends, all of which are the highest quality, then a simple single extrinsic call to have the nominator confirm this selection is super relevant to let the network / community know that they are still actively making a decision. We could even introduce a super minimal extrinsic which is just renew_nominations and has no inputs, low fees, and selects the same set. However, simply the action of making that call is I think the right catalyst for those who are not 100% certain to simply rethink their selection.
3. Tooling for selecting validators is getting better and better each month in the Polkadot ecosystem. I think where we are at today with the Staking Portal is leagues better than where we were when we first launched the network. Similarly, I think we still feel there is a lot of room for improvement, so we should expect a few years from now, it will again be an order magnitude better for nominators to select the highest quality validators for Polkadot. This kind of periodic update also brings our community to these new staking resources, exposes them to new information, and allows them to make better informed decisions.
4. Your argument includes the idea that nominators nominate their 'friends' whom they know in person and are the highest quality choice for them, but from a data standpoint, we absolutely know this is not the case. Most nominators have no tangible relationship with their validator, and have pretty much picked the set based on lowest commission, or some auto-ranking from a UI. I have already had the experience where a validator that I nominated increased their commission after I selected them, and until I went to renew my nominations, that change was pretty much unknown to me.

Again, some simple reaffirm after 6 months would not be too problematic, but we definitely send the wrong message by doing this. If we do an RFC for this, then we should explain that this is a harmful feature, but we want more engagement, and really helpful engagement features are much much harder.

I would like you to clarify what "message" we are sending, and what about it is "harmful".

An example of a helpful engagement feature: All validator operators have a MOTD which their nominators read. We decreates rewards if you do not read some MOTDs from your nominations for 6 months. It's harder to assess reading messages though. Also, doing a MOTD requires much more work than this feature.

As you know, with the tools in available by blockchains, we cannot really force any behavior, just encourage it at a high level through economics. If validators have to continue to stay relevant in the eyes of prospective nominators, then behaviors like creating daily messages / updates / metrics / etc will happen. There will not be voiceless non-participatory validators who got into the set just because they had connections to Web3 Foundation at genesis. People will be constantly re-evaluate which validators are doing the best for their nominators and are having the best interests of Polkadot in mind.

[burdges]

We pay nominators to judge the character, competence, and independence of validator operators. We do not pay nominators to judge their payouts because 33% attackers can easily manipulate nominators who judge by payouts.

If the validator operator has little public presence, and no personal relationship with the nominator, then payouts are their only communication, so alone this feature sends the message that nominators should listen to their payouts, which is incorrect.

It's not that nothing changed, but that no communication channel exists. This feature does not alter any communication channels. It's magical thinking if you believe this feature results in more communication. It doesn't touch the available communication channels, does not incentivize listening to existing ones, etc.

We already de facto require nominators interact regularly with polkadot.js because they must sell dots regularly. If you're worried that's false, then alright maybe we need them to interact more with the interface, so then that becomes the justification for this feature. Afaik, that's simply a question of tax law around the world though.

If nominators do not even login, then yes positive synergies could exist between this feature plus MOTD or whatever. Alone, this feature is still harmful though.

I do not object to two steps forward preceeded by one necessary step backwards, but alone this feature is only the step backwards.

[jonasW3F]

We pay nominators to judge the character, competence, and independence of validator operators. We do not pay nominators to judge their payouts because 33% attackers can easily manipulate nominators who judge by payouts.

How does the mechanism of reaffirm your nomination change that? You implicitly assume that their first selection was well-informed and this mechanism drives them away from that and chase yield? I doubt that.

We already de facto require nominators interact regularly with polkadot.js because they must sell dots regularly. If you're worried that's false, then alright maybe we need them to interact more with the interface, so then that becomes the justification for this feature. Afaik, that's simply a question of tax law around the world though.

Being a nominator does not entail any costs, so I don't see how they "must sell" dots regularly. But even if, their interaction with Polkadot does not lead them to engage with their selection again.

I do not object to two steps forward preceeded by one necessary step backwards, but alone this feature is only the step backwards.

I agree that the topic is not solved with this mechanism and that we should find more ways to make it easier for nominators to properly inform themselves if they chose to (or nudged to by this mechanism). One obvious idea would be to leverage the 1kv more in that regard and help to make a connection between well-performing (not only in yield but generally) validators and nominators looking for new validators.