Nomination Pools: ClaimPermission suggestions to decrease unclaimed payouts

[rossbulat]

I would like to suggest some changes to nomination pool claim permissions (a permission configuration that allows any account to claim rewards on a member's behalf) to tackle the issue of growing unclaimed pool rewards, and to increase the rate at which members receive rewards.

Last year we introduced a ClaimPermission enum, that allows permissionless claiming of pool rewards, categorised by withdrawing, compounding, or both. Although this was a positive step, only 1282 (out of 34.7k members at time of writing) have used the feature on Polkadot. It is my suspicion that the feature is out of touch with member expectations, has the wrong default, and a PermissionlessAll variant (which can also be achieved via a proxy) that is too ambiguous. In short, users either do not know about the feature, or are confused on how to use it.

All the while, unclaimed pool rewards are building up at a quickened rate:

With that said, the following suggestions am to:

• Stop the build up of unclaimed rewards, allowing pool admins to batch call all the unclaimed rewards for their members *unless members explicitly disallow.
• Increase the rate at which members receive pool rewards, by giving pool admins the tools to expedite reward claims.

Suggested Changes

1. Remove PermissionlessAll variant from ClaimPermission

PermissionlessAll allows anyone to claim for a member, both withdrawing and compounding. There are currently 550 entries of this variant (1.6% of pool members) on Polkadot. This variant is not giving the claimer any guidance as to what to do - it is ambiguous and can cause confusion when pool members check up on their balances. Furthermore, this can be done with a Staking proxy.

To streamline options, PermissionlessAll can be removed completely, with existing configs migrated to PermissionlessWithdraw or PermissionlessCompound.

Revised. Amend ClaimPermission variants to also consider pool admin roles.

2. By default, allow permissionless withdraw of unclaimed rewards

When a pool member joins a pool, have PermissionlessWithdraw as default. Compounding could also theoretically be by default, but this implicitly will lock the member's rewards for 28 days, something they might not want to happen - let's avoid this scenario. If members wish to opt for another config, UIs can submit a batch call along with join to change the claim permission at the time of joining.

If PermissionlessAll still existed, perhaps this would be unreasonable, as we'd be giving any account the freedom of whether to withdraw or compound rewards, rendering them unpredictable. But with an explicitly set reward location at the time of joining (and amendable onwards), things become predictable and controllable by the pool member.

3. Migrate PermissionlessAll to PermissionlessWithdraw

In order to deprecate PermissionlessAll, a migration can update existing records to PermissionlessWithdraw to allow a fall back to withdrawing. Since we do not know what pool members actually intended with PermissionlessAll, it is safer to not migrate to an option that will lock their funds for 28 eras.

I'd be interested to hear suggestions or shortfalls with this approach.

[liamaharon]

Dumb question: am I right in understanding the motivation to decrease unclaimed payouts is because unclaimed payouts don't compound, and we want to maximise compounding for users in nom pools?

what is the motivation for permissionless withdrawal?

[rossbulat]

Dumb question: am I right in understanding the motivation to decrease unclaimed payouts is because unclaimed payouts don't compound, and we want to maximise compounding for users in nom pools?

what is the motivation for permissionless withdrawal?

There are a few benefits; from the network's perspective compounding those rewards will further secure the network & total supply staked. From a member's perspective they are getting more bang for their buck by increasing their bond / free balance, that'll increase satisfaction and perception of Polkadot staking, and hopefully follow through with word of mouth referrals. Which then means more stakers, more security, and the loop continues.

From a pool admin standpoint it gives them another tool to differentiate themselves by auto claiming for their members from day 1. It is important to note that many members are not used to manually claiming, manually withdrawing after undbonding, etc.

From a competitive standpoint we don't want to be seen as the protocol that does not reward stakers, which is a stigma we've unfortunately inherited from early-day NPoS UI.

I think also from our core values (at least personally speaking), we should strive to improve shortfalls of the current Polkadot staking system for our users if we do indeed see them. If we do not iterate and improve then we will inevitably fall behind more attractive staking solutions.

[rossbulat]

I'd also point out that this 140k DOT figure is at a point of a market cycle where we are just gaining momentum again. This figure, which the graph has already started to show, is no longer increasing at a linear rate. It will likely become an exponential problem if we just leave the system be. Then all the gains we sacrifice will become exponentially more impactful, & the opportunity cost exponentially larger as time goes by.

Another issue the ecosystem voices a lot is the lack of liquidity for DeFi protocols. So 6 - and eventually 7 - figure DOT being unclaimed in pools just exacerbates this, and all the while could contribute to the solution.

[liamaharon]

Thanks for elaborating.

My first impression is I'm not convinced that modifying permission defaults will do much to resolve this problem, and a proper solution requires some collaboration with pool operators. e.g. even if a user has allowed permissionless compounding for their account, it won't do anything to reduce unclaimed payouts if their pool operator doesn't have the infrastructure running to trigger the auto-compounding for them.

If an effective solution will require buy-in and effort from pool operators anyway, I don't think it's a huge deal for them to also update their UIs (and the ecosystem to update neutral UIs like staking dashboard) to make joining a pool always a batch extrinsic where the user is prompted to enable either permissionless withdrawal or compounding at the same time as they join the pool.

Over time, market share should accumulate to pool operators who offer higher APY by making auto-compounding as frictionless and frequent as possible.

So, it may be that providing a tool for periodically autocompounding user funds and publishing examples for how to construct the appropriate batch tx in the ui that enables autocompounding is more effective at resolving this issue than making changes to the pallet.

LMK what you think.

[rossbulat]

Oh yes, buy in from pool operators is definitely needed. But it is not possible to do this right now due to limitations on the protocol level, e.g. members don't allow pool admin permission by default.

Having the exposure to stakers day to day I am convinced the suggested amendments are a crucial first step. UIs are not obliged to support pool claim permissions - and it is evident from what I am seeing - the poor uptake - that they are not pushing it.

The staking dashboard has displayed permission configs when joining a pool since its inception, with the default being disabled. Again it's evident that other UIs have little interest in doing similar things. This has always been the case - controller deprecation, proxy support, pool commission & role management are all aspects that are away from the majority of app's concerns. They prefer to focus on their core value props.

The solution outlined in this issue is purely for the protocol side, that will enable pool operators to act and claim rewards. The logistics of the comms needed thereafter can be considered later.

But indeed, I'm in full agreement that a comms effort will be needed, amongst other things like Polkadot Wiki inclusion of the feature.

[Ank4n]

Is it possible to nudge delegators to achieve this without any pallet change/migration by providing better tooling? Few things that come to my mind:

• UI allowing delegators to setup automatic monthly claim rewards (or when their reward balances reaches a threshold) via oak network.
• Something like ryabina bot or kian's notification system for user where they can get weekly/monthly notification of how much reward is pending to be claimed.

Not all that against this and let me know if you think something like above would not work/have already been tried. In general though, I think it is a better goal to try to get more user activity on the chain by improving our tooling instead of relying on pool operators and bots. If we make it damn easy but user still do not want to claim often, that is okay maybe.

[Ank4n]

Oh yes, buy in from pool operators is definitely needed. But it is not possible to do this right now due to limitations on the protocol level, e.g. members don't allow pool admin permission by default.

Having the exposure to stakers day to day I am convinced the suggested amendments are a crucial first step. UIs are not obliged to support pool claim permissions - and it is evident from what I am seeing - the poor uptake - that they are not pushing it.

The staking dashboard has displayed permission configs when joining a pool since its inception, with the default being disabled. Again it's evident that other UIs have little interest in doing similar things. This has always been the case - controller deprecation, proxy support, pool commission & role management are all aspects that are away from the majority of app's concerns. They prefer to focus on their core value props.

The solution outlined in this issue is purely for the protocol side, that will enable pool operators to act and claim rewards. The logistics of the comms needed thereafter can be considered later.

But indeed, I'm in full agreement that a comms effort will be needed, amongst other things like Polkadot Wiki inclusion of the feature.

If a particular UI/dashboard provides better usability and features, aren't users incentivised to use that dashboard?

I think though an easier (and uncontroversial imo) change is simply making PermissionlessAll PermissionWithdraw the default, i.e. anyone can claim rewards for you unless you explicitly say you don't want to. I am totally in support of that. This should still achieve all your goals I think? Not sure if user cares that a pool operator claims their reward or anyone else.

[liamaharon]

e.g. members don't allow pool admin permission by default.

UIs could easily make joining a pool a batch action where permissionless compounding (or withdrawal) is granted atomically. If pool operators haven't done that already, or pressured community dashboards to enable it (pretty straight forward), I hesitate to believe they'll go the lengths to develop and maintain infrastructure for auto-compounding (more complex task) if something like this is implemented. Hence I'm still not sure this will be solved with changes to frame and is better solved improving staking uis and making it easier for pool operators to auto-compound on behalf of their users.

Not sure if user cares that a pool operator claims their reward or anyone else.

👍🏼

[rossbulat]

Is it possible to nudge delegators to achieve this without any pallet change/migration by providing better tooling? Few things that come to my mind:

• UI allowing delegators to setup automatic monthly claim rewards (or when their reward balances reaches a threshold) via oak network.
• Something like ryabina bot or kian's notification system for user where they can get weekly/monthly notification of how much reward is pending to be claimed.

Not all that against this and let me know if you think something like above would not work/have already been tried. In general though, I think it is a better goal to try to get more user activity on the chain by improving our tooling instead of relying on pool operators and bots. If we make it damn easy but user still do not want to claim often, that is okay maybe.

There are upcoming UIs like Polkadot Live that will notify users on pending pool rewards. The simple notification system was a good proof of concept but it is not too viable as a consumer app. But again, I would rather that app notify a user that their rewards have been paid out, not that they have to do it themselves.

The issue with relying on UIs is that every UI would need to have this permissionless claim batch support, which we have just not seen. Like I said in a previous comment, UIs strictly follow their core value props; they will not support every network feature if they don't deem it valuable.

My proposed suggestions would give us leeway to reach out to pool operators - and essentially all stakeholders - from day 1 and with 1 batch call an account could draw down unclaimed rewards dramatically. Talisman alone would be a big chunk as they are the largest pool operator. Operators would actually be interested in doing this as it looks good for them to unlock rewards for their users. This simple action versus a campaign to support the batch call is not a contest IMO. It is also amending an unused feature to a used feature on chain and making the pallet more efficient, in what is actually quite a simple refactor with no breaking changes.

[rossbulat]

If a particular UI/dashboard provides better usability and features, aren't users incentivised to use that dashboard?

I think though an easier (and uncontroversial imo) change is simply making PermissionlessAll the default, i.e. anyone can claim rewards for you unless you explicitly say you don't want to. I am totally in support of that. This should still achieve all your goals I think? Not sure if user cares that a pool operator claims their reward or anyone else.

Most users will not be aware that permissionless claiming actually exists. As I've eluded to in prev comments, UIs are not incentivised to educate users on all chain features.

The issue with PermissionlessAll is that the user is allowing both compound and withdraw, which is unpredictable and gives no guidance to the claimer - and only 1.6% of pool members actually use it. It was a mistake to have this in the first place IMO. Pool members should explicitly choose whether they want compounding or withdrawing. If they want both, I believe a proxy would work better as the delegate would have full control over their staking position.

[Ank4n]

I apologise I actually misunderstood what the current enum variants are in the code (I was assuming we are adding two new variants).

Removing the PermissionlessAll seems reasonable to me. I understand the unpredictable nature of it and we should get rid of it.

About setting default to PermissionlessWithdraw: Also seems reasonable. It is equivalent to automated reward payouts from the end user's pov.

I can see though some users not wanting PermissionlessWithdraw for taxation reasons since in many jurisdiction, any payout to your account is considered a taxable event. Ideally we should ask this explicitly when user joins a pool (the join extrinsic could take an extra param similar to staking::bond). But this will be a breaking change.

There was I think a suggestion earlier to make it permissionless only for pool admin, which is removed now so I believe we are on same page about it that it does not matter.

[rossbulat]

I can see though some users not wanting PermissionlessWithdraw for taxation reasons since in many jurisdiction, any payout to your account is considered a taxable event. Ideally we should ask this explicitly when user joins a pool (the join extrinsic could take an extra param similar to staking::bond). But this will be a breaking change.

I completely agree, users should indeed be explicitly asked by the UI when they are joining. I think this is where the batch call can come into play to cater for the subset of users who want to opt out of permissionless claiming. This way we ensure unclaimed rewards can remain low & expectations from the masses are met, but also catering for taxation concerns, that would be a concern of a smaller subset of users. I think this is where UI pressure from users would be effective, not the other way around as it is now.

There was I think a suggestion earlier to make it permissionless only for pool admin, which is removed now so I believe we are on same page about it that it does not matter.

Ah yes, after some feedback and PermissionlessAll removal considered, the original description was pushed back on pool admin configs - not really needed!

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/nomination-pools-make-permissionless-withdraw-the-default/6766/1