I’ll try to paraphrase your words, please correct me if misunderstand anything, coz some of the terms are not as straightforward to outsider like me. :))

There should be a way such that if the contribution (in terms of stake) of a member somehow goes below the existential deposit (however much on that network), they’ll be reaped, meaning to be removed from the pool. Correct?

I’ll try to paraphrase your words, please correct me if misunderstand anything, coz some of the terms are not as straightforward to outsider like me. :))

There should be a way such that if the contribution (in terms of stake) of a member somehow goes below the existential deposit (however much on that network), they’ll be reaped, meaning to be removed from the pool. Correct?

We need to add a permissionless call to Nomination Pools to reap a pool member. Reaping should be only possible if member contribution is below ED (can happen in case of slashing). When you reap a pool member, it should do some additional cleanup,

Reap delegator in pallet-delegated-staking
reap part of the staked balance in pallet-staking. This should never exceed ED.

Don't hesitate to ask any more clarifying questions if you end up taking this issue. :)

Hi @Ank4n , is this still open? I will have a go at it then.

Hi @Ank4n , is this still open? I will have a go at it then.

Yes, this can still be picked up. :) @eagr has already started working on this.

sorry I kinda forgot about this. I just have something drafted up. not sure if it's on the right direction though

sorry I kinda forgot about this. I just have something drafted up. not sure if it's on the right direction though

@eagr ahh okay didn't realise you have started working on this. I will have a look shortly.

sorry I kinda forgot about this. I just have something drafted up. not sure if it's on the right direction though

@eagr I have put some additional context in the description. I am also realising it has some subtle logic that requires knowledge of pool and delegation system. The issue is probably not as straight forward anymore but happy to help you if you are still keen to fix it. :)

@Ank4n Sure, sounds like a great opportunity to learn about staking/delegation! I'm going through the docs and codebase and accumulating questions. Will get back to you soon. Btw, have a nice weekend. :)

If <ED contribution is to be reaped, then it seems inappropriate to allow withdrawing certain amount of fund such that it’s leaving >0 && <ED behind. Then I guess the only way for a member’s contribution to go <ED is slashing? Curious why does this need to be an extrinsic, rather than a part of some post-slashing transition?

When one joins a pool,

• for pool of StakeStrategyType::Transfer
  • transfer fund from member account to pool account
  • update pool account ledger
• for pool of StakeStrategyType::Delegate
  • create delegation
  • "hold" fund in place
  • update agent ledger
  • update pool account ledger
• increase TVL

I suppose we kinda need to do the opposite in the reversed order.

I could see the pallets in question are loosely coupled via the composition of the traits below. Below is a very rough idea for the extrinsic to trigger actions in those staking pallets.

impl StakingInterface for pallet_staking::Pallet {
  // with `dust_bonded()` added to the trait
  fn dust_bonded() {
    // update account ledger
    // burn (drop) balance
  }
}

impl DelegationInterface for pallet_nomination_pools::Pallet {
  fn dust_delegation() {
  }
}

impl StakeStrategy for TransferStake {
  // with `member_dust()` added to the trait
  // going along with other names in the trait:
  // member_withdraw, member_slash
  fn member_dust() -> DispatchResult {
    // ...
    Staking::dust_bonded();
    // ...
  }
}

impl StakeStrategy for DelegateStake {
  fn member_dust() -> DispatchResult {
    // ...
    Staking::dust_bonded();
    Delegation::dust_delegation();
    // ...
  }
}

// the extrinsic
fn dust() {
  // ..., if member active balance < ED
  T::StakeAdapter::member_dust();
  // ...
}

Any suggestions?

Hey @eagr ,

If <ED contribution is to be reaped, then it seems inappropriate to allow withdrawing certain amount of fund such that it’s leaving >0 && <ED behind. Then I guess the only way for a member’s contribution to go <ED is slashing? Curious why does this need to be an extrinsic, rather than a part of some post-slashing transition?

absolutely correct. this will only happen in the event of slashing.

This shall not be included in the regular slashing operation itself because we want to minimize the amount of computation it needs to do in one block. We basically clean up after the slash. We want to do it this way to make sure that we don't exceed the limits of computation that can be done within one block in case a slashing event occurs.

Curious why does this need to be an extrinsic, rather than a part of some post-slashing transition?

You raise a good point. The extrinsic was probably needed for members with the legacy transfer adapter. There are two scenarios where we need reap:

• Members with transfer strategy and migrate_delegation fails because their pool contribution is too low. These members can be reaped when calling migrate_delegation.
• Pool members are slashed lazily with Delegate adapter. These members can be reaped when apply_slash is called if their contribution goes below ED.

Not sure about the trait definition you shared. From StakingInterface point of view, these are not dust bonded. Infact staking does have a way to reap staker when balance falls below ED. The pool knows if contribution is below ED, and it should then trigger something like force_unbond in StakingInterface, withdraw that delegation from DelegationInterface (I don't think you need new functions here), and then clean up the pool member.

Updated the PR to achieve what you described here to the best of my knowledge. Still not quite sure if I'm on the right track tough. I left a few questions in the code prefixed by FIXME eagr. Could you take another look? @Ank4n @PieWol And a couple more questions.

In the PR, for legacy pools with Transfer adapter, the reaped deposit simply vanishes, that is, not transferred back to the member account. For pools with Delegate adapter, the reaped deposit is subtracted from the pool staking ledger, but remains available to the member account. What are the expected behaviors respectively?

Can the pool creator be reaped if their active stake goes below ED? If so, what should happen to the pool?

In the PR, for legacy pools with Transfer adapter, the reaped deposit simply vanishes, that is, not transferred back to the member account. For pools with Delegate adapter, the reaped deposit is subtracted from the pool staking ledger, but remains available to the member account. What are the expected behaviors respectively?

We should try to keep the same behaviour for both adapters. I can think of two choices (it can be configurable as well)

• Burn the amount force withdrawn.
• Transfer the force withdrawn amount to reward pool. This then just gets distributed to other pool members.

Either of the options are fine, with a little higher preference for burn.

Can the pool creator be reaped if their active stake goes below ED?

If pool is not in Destroying state or has other pool members this can never happen. Pool Creator is always the last member to be removed from the pool.