Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

staking: allow nominator to bail out of the automatic reward payment #458

Open
kianenigma opened this issue Jun 11, 2022 · 3 comments
Open
Labels
I5-enhancement An additional feature request. I10-unconfirmed Issue might be valid, but it's not yet known.

Comments

@kianenigma
Copy link
Contributor

For accounting purposes, a nominator might prefer to receive their rewards exactly when they wish. I have not looked too much yet, but it seems like this is not trivially possible. Nonetheless, I think it is an avenue worth exploring.

@Szegoo
Copy link
Contributor

Szegoo commented Jul 1, 2022

Currently, the rewards are paid out for every era one by one using the payout_stakers function. If I understand correctly you want to make it so that the nominator doesn't get paid out in every era, but so that they can withdraw their rewards whenever they want. This would be of course optional.

Could there be another incentive to bail out of the automatic reward payment other than accounting?

For doing this there should be made a function that could probably ideally make a payout for multiple eras at once because it would be impractical to withdraw the rewards from multiple eras one by one.

@kianenigma
Copy link
Contributor Author

Could there be another incentive to bail out of the automatic reward payment other than accounting?

Not that I know of, accounting is the main one that I can think of.

For doing this there should be made a function that could probably ideally make a payout for multiple eras at once because it would be impractical to withdraw the rewards from multiple eras one by one.

Indeed, there needs to be a feasibility study here as I think a lot of the current payout system is based on the assumption that a validator is paid out at once. Namely, I think in the StakingLedger of each validator we store some information about this.


If you happen to look into this and have more findings, to let us know. Then we can decide if this is worth doing or not.

@Szegoo
Copy link
Contributor

Szegoo commented Jul 7, 2022

For this, to work we cannot store information about the payout type(i.e automatic or manual) in the StakingLedger. Every nominator should have a similar field to claimed_rewards like the one inside the StakingLedger. Also, we need to keep information about the payout type for the nominators.

There should probably be a new struct for the nominator similar to StakingLedger, that would store the additional information we need.

Something like this could be made:

staking/src/lib.rs
pub enum PayoutType {
	/// The nominator gets paid out whenever someone makes a call to `payout_stakers`
	Automatic,
	/// The nominator receives the rewards when he requests so.
	Manual,
}
pub struct NominatorLedger {
	/// List of eras that the nominator has claimed the rewards for.
	pub claimed_rewards: Vec<EraIndex>,
	/// The type of payout the nominator has chosen.
	pub payout_type: PayoutType,
}
staking/src/pallet/mod.rs
/// Map from nominators `stash` account to the info regarding the nominator.
#[pallet::storage]
pub type NLedger<T: Config> = StorageMap<_, Blake2_128Concat, T::AccountId, NominatorLedger>;
/// It is possible to access the NominatorLedger from the `payout_stakers` given that we have
/// the nominators `stash` account.

It is possible to achieve this, but as you mentioned the current payout system is based on the assumption that everyone is paid out at once, so there would need to be some code and logic change.

When storing all this information about the nominator it should be easy to make a function that could collect all of the rewards from the unclaimed eras.

@juangirini juangirini transferred this issue from paritytech/substrate Aug 24, 2023
@the-right-joyce the-right-joyce added I5-enhancement An additional feature request. I10-unconfirmed Issue might be valid, but it's not yet known. and removed J0-enhancement labels Aug 25, 2023
claravanstaden pushed a commit to Snowfork/polkadot-sdk that referenced this issue Dec 8, 2023
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 8, 2024
…ch#458)

* integrate message-lane RPCs into Millau and Rialto runtime

* fmt

* use instance in InboundLanes

* moved RialtoMessageLaneKeys/MillauMessageLaneKeys inside rpc_extensions_builder to ease Substrate refs update
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 8, 2024
…ch#458)

* integrate message-lane RPCs into Millau and Rialto runtime

* fmt

* use instance in InboundLanes

* moved RialtoMessageLaneKeys/MillauMessageLaneKeys inside rpc_extensions_builder to ease Substrate refs update
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
…ch#458)

* integrate message-lane RPCs into Millau and Rialto runtime

* fmt

* use instance in InboundLanes

* moved RialtoMessageLaneKeys/MillauMessageLaneKeys inside rpc_extensions_builder to ease Substrate refs update
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
…ch#458)

* integrate message-lane RPCs into Millau and Rialto runtime

* fmt

* use instance in InboundLanes

* moved RialtoMessageLaneKeys/MillauMessageLaneKeys inside rpc_extensions_builder to ease Substrate refs update
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
…ch#458)

* integrate message-lane RPCs into Millau and Rialto runtime

* fmt

* use instance in InboundLanes

* moved RialtoMessageLaneKeys/MillauMessageLaneKeys inside rpc_extensions_builder to ease Substrate refs update
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
…ch#458)

* integrate message-lane RPCs into Millau and Rialto runtime

* fmt

* use instance in InboundLanes

* moved RialtoMessageLaneKeys/MillauMessageLaneKeys inside rpc_extensions_builder to ease Substrate refs update
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
…ch#458)

* integrate message-lane RPCs into Millau and Rialto runtime

* fmt

* use instance in InboundLanes

* moved RialtoMessageLaneKeys/MillauMessageLaneKeys inside rpc_extensions_builder to ease Substrate refs update
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
…ch#458)

* integrate message-lane RPCs into Millau and Rialto runtime

* fmt

* use instance in InboundLanes

* moved RialtoMessageLaneKeys/MillauMessageLaneKeys inside rpc_extensions_builder to ease Substrate refs update
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 10, 2024
…ch#458)

* integrate message-lane RPCs into Millau and Rialto runtime

* fmt

* use instance in InboundLanes

* moved RialtoMessageLaneKeys/MillauMessageLaneKeys inside rpc_extensions_builder to ease Substrate refs update
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 10, 2024
…ch#458)

* integrate message-lane RPCs into Millau and Rialto runtime

* fmt

* use instance in InboundLanes

* moved RialtoMessageLaneKeys/MillauMessageLaneKeys inside rpc_extensions_builder to ease Substrate refs update
jonathanudd pushed a commit to jonathanudd/polkadot-sdk that referenced this issue Apr 10, 2024
…ch#458)

* integrate message-lane RPCs into Millau and Rialto runtime

* fmt

* use instance in InboundLanes

* moved RialtoMessageLaneKeys/MillauMessageLaneKeys inside rpc_extensions_builder to ease Substrate refs update
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I5-enhancement An additional feature request. I10-unconfirmed Issue might be valid, but it's not yet known.
Projects
Status: ⌛️ Sometime-soon
Development

No branches or pull requests

3 participants