Directly stake staking rewards to some nominator, RewardDestination::AccountTryStaked<AccountId> #282
Labels
I5-enhancement
An additional feature request.
T1-FRAME
This PR/Issue is related to core FRAME, the framework.
Directly stake staking rewards to some nominator, RewardDestination::AccountTryStaked<AccountId>
Currently we can send a staking reward to an AccountId. It would be useful in multi-account management scenarios to stake rewards directly to another nominator. In the event the reward-receiving account is not currently a nominator stash, then the variant logic can fall back to
RewardDestination::Account
. (hence the name AccountTryStaked). Doing this semi-automates the process of delegating additional staked funds across a pool of managed accounts.Scenario: Imagine a multi-account management setup where a user wishes to actively maintain 3 nominators.
Account 3
is lacking funds and urgently requires additional staked DOT to meet reward targets.Account 1
andAccount 2
are well-funded and are comfortably above their reward targets.Reward target here can refer to a minimum payout threshold the user wants to achieve for their managed nominators.
Application Side: A “Stake All Rewards To” button alongside an account within an account list will initiate extrinsics that will update all selected accounts in the list to stake their rewards on behalf of the destination account (assumed to be a nominator stash). This can tie in with in-app announcements or notifications pertaining to reaching a target payout limit for such accounts.
• This strategy becomes more effective the more active nominators the user has under their control.
• This feature allows a more automated approach for applications to bolster, bootstrap or maintain a nominator, and could be offered as a service at the “enterprise” level.
Limitations: The main downside to this approach from a user’s perspective is having to sign a separate
set_payee
extrinsics for each account'sRewardDestination
to be updated. However, callbacks can update UI as soon as an extrinsic is signed, and can add spinners, in-progress labels etc to the already-signed accounts. Beyond the scope of this Issue though, we could abstract some form of account group on-chain to give permissions to organise such reward delegation.Proposal
RewardDestination
variant,AccountTryStaked<AccountId>
that allows staking rewards from one account to be automatically staked to another account, or fallback toRewardDestination::Account
if that account is not a nominator stash.make_payout
to account for the new variation.The text was updated successfully, but these errors were encountered: