feat(dAppStaking): Move actions for bonus rewards #1418
Conversation
|
@ipapandinas please check the concept. |
Minimum allowed line rate is |
| let entries: Vec<StakeAmount> = stake_amount_entries.into_iter().collect(); | ||
| match entries.as_slice() { | ||
| [single_entry] => { | ||
| let amount = single_entry.total(); | ||
| self.current_stake_amount.subtract(amount); | ||
| self.next_stake_amount.subtract(amount); | ||
| } | ||
| [entry_current, entry_next] => { | ||
| self.current_stake_amount.subtract(entry_current.total()); | ||
| self.next_stake_amount.subtract(entry_next.total()); | ||
| } | ||
| _ => {} // Ignore cases with more than 2 entries or empty input - this should never happen | ||
| } |
There was a problem hiding this comment.
Shouldn't eras in the iter be matching with the ones in owned fields at this point?
I'm asking this since it's weird to see different approach compared to the one in pub fn unstake(.
There was a problem hiding this comment.
I am not sure to understand this one, could you rephrase it?
There was a problem hiding this comment.
Sure - I meant to say that in the other unstake method (which takes era_and_amount_pairs: Vec<(EraNumber, Balance)>, as argument), we iterate over the received values, and subtract the value from either self.staked or self.staked_future, whichever matches the provided era argument.
My suggestion is to apply the same approach here, instead of making positional assumptions.
| let expected_dest_staking_info = SingularStakingInfo { | ||
| previous_staked: StakeAmount { | ||
| voting: 100, | ||
| build_and_earn: 150, // TODO: should it not be 0 here? |
There was a problem hiding this comment.
Yes, it should remain unchanged.
| @@ -460,6 +460,7 @@ impl pallet_dapp_staking::Config for Runtime { | |||
| type MinimumStakeAmount = MinimumStakingAmount; | |||
| type NumberOfTiers = ConstU32<4>; | |||
| type RankingEnabled = ConstBool<true>; | |||
| type MaxBonusSafeMovesPerPeriod = ConstU8<0>; | |||
There was a problem hiding this comment.
General question for all runtimes - did you try to test the migration extrinsic yet?
Pull Request Summary
Closes #1379
This PR introduces enhancements to the bonus reward eligibility mechanism and implements robust handling for stake movement, particularly during the
build&earnsubperiod.The approach aims to first adapt existing pallet to easily support
movefunctionality.Pallet has a lot of tests covering stake & unstake functioality, and in case
MAX_BONUS_MOVES = 1, every legacy test must work same as before.Changes
stake,unstakeandunstake_from_unregisteredis moved to separate functions, with minimal modificationsunstaketo return more comprehensive information of what was unstakedmoveextrinsic, usinginner_unstakeandinner_stakefunctions (orunstake_from_unregistered) as the building blocksBonus Reward Eligibility
The previously used
loyal_stakerflag is replaced with abonus_statusu8type.The number of allowed move actions is defined by a config parameter (
MaxBonusSafeMovesPerPeriod); bonus is forfeited if move actions exceed this value.Move action
A move action is defined as either:
If a move action is performed during the
build&earnsubperiod, thebonus_statusattached to the relevant singular staking info is reduced until it is forfeited.Stake Movement Enhancements
A new
move_stakeextrinsic is implemented. It is similar to an 'unstake' followed by a 'stake'. Existing safeguards are extended additional checks to:When moving stake from unregistered contracts, the bonus status is always preserved.
Migration
This PR introduces the
update_bonusextrinsic, which updatesloyal_stakerflags from the previous 0 move actions limit to the new value set byMaxBonusSafeMovesPerPeriod. The change will take effect in a future runtime upgrade when the config parameters are updated.Check list