Unstaking deposits doesn't require a 14-day wait.

[AurevoirXavier]

Deposited RING is already locked for at least 1 month.
It's reasonable to unstake it immediately.

In the Darwinia 1, users can redeposit immediately if a deposit is expired.

[hackfisher]

Deposited RING is already locked for at least 1 month.
It's reasonable to unstake it immediately.

I disagree, RING in deposit is locked for the return of KTON interest, not for staking.

The deposit is a NFT holding the deposit, staking/unstake deposit is just like stake/unstake a NFT token.

[hackfisher]

14-day wait is for slash purpose, if the collator staking is not going to support slash anymore, the RING token in staking can remove the wait too, it is not different with deposit NFT.

What is NFT inner status is opache to staking by design.

And the deposit and collator staking will be moved to application level implementation, I would rather give it low priority and discuss in the next design of collator-staking.

[hackfisher]

stake and unstake rate limiting can prevent sudden fluctuation to the collators, which might be better. Rate limit, in a period, only specific amount of staking tokens can be staked/unstaked at most.

[hackfisher]

I've given it some thought, and since there's currently no slashing mechanism in collator staking, we could remove the unstaking wait (for RING and deposit).

1. This would require writing an RFC forum post, followed by a transition to a DIP for easier engineering implementation and future migration to a contract.
2. At the moment, I don't want to spend too much time changing the protocol within the runtime. If a user stakes and unstakes before and after a session, they wouldn't need to lock up funds but could still interfere with collator election.
3. We might consider a measure, such as requiring a minimum stake duration of one session before unstaking.
4. Consider the side effects for account-migration.

Considering we haven't fully researched item 3, my current recommendation might still be to avoid any changes.

[SasoLithops]

Hi! If I may add the main problem for community is when our (3 year) locks are expired we all have to unbond each lock and wait 14 days so we can rebond again. In V1 you could use Lock Extra to immediately continue bonding again.
Would be good if we had that option back.

[hackfisher]

Hi! If I may add the main problem for community is when our (3 year) locks are expired we all have to unbond each lock and wait 14 days so we can rebond again. In V1 you could use Lock Extra to immediately continue bonding again. Would be good if we had that option back.

For simplicity and security, different modules typically implement secure isolation to prevent abnormal calls. For example, the staking module should not be able to handle deposit logic for users, especially in the next design. If such operations are supported now, it would add unnecessary complications to future migration designs.

Ref: #1395

In short, I don't want to introduce more mechanisms in the process of defusing a bomb.

[SasoLithops]

You were to fast in reply😀I wanted to post some examples:

[SasoLithops]

If you find to not use Lock extra for technical reasons I understand. I have no knowledge there.
I am trying to be as objective here as I can, as I have also many locks expiring as I bonded weekly/biweekly, but I can take the wait of 14 days. I think from user perspective this is still very time/rewards consuming.

[hackfisher]

Before we reach full consensus, or before we figure out how to completely cancel unstaking period, shall we reduce this period to 7 days or 3 days? Keep it simple and minimal in terms of protocol modification.

[SasoLithops]

If it doesn't hurt the network and I guess it doesn't now I am all for simplicity.
I am fine with either options. Although we all know what community would vote on if both options were presented😉

[hackfisher]

For the technical research:

https://ethresear.ch/t/rate-limiting-entry-exits-not-withdrawals/4942

[hackfisher]

https://github.com/orgs/darwinia-network/discussions/1455

[SasoLithops]

Maybe I still don't understand well. Just to be 100% sure we are talking about same thing I was talking about continuation of bonding not exiting staking.

My example is:

Let's say I always lock Ring for 36 months.

So in past I locked Ring for 36 months and it expires today.

In V2 I have to wait for 14 days to unbond and then I need to withdraw to lock again for 36 months.

In V1 all I needed to do was click on "Lock extra" and I could immediately rebond for 36 months.
*I still had to wait 14 days to unbond and withdraw, but that is not my intention in example above.

So "Lock extra" was not about withdrawal or unstaking at all, just imediate relocking for another time frame to mint Kton.

[hackfisher]

Maybe I still don't understand well. Just to be 100% sure we are talking about same thing I was talking about continuation of bonding not exiting staking.

My example is:

Let's say I always lock Ring for 36 months.

So in past I locked Ring for 36 months and it expires today.

In V2 I have to wait for 14 days to unbond and then I need to withdraw to lock again for 36 months.

In V1 all I needed to do was click on "Lock extra" and I could immediately rebond for 36 months.
*I still had to wait 14 days to unbond and withdraw, but that is not my intention in example above.

So "Lock extra" was not about withdrawal or unstaking at all, just imediate relocking for another time frame to mint Kton.

Yes, using this RFC can eliminate this issue you mention:

Unstake deposit right way, claim from deposit, deposit as you like, stake again. 4 txs, no wait.

Why not support those in 1 extrinsic call in collator staking?

In protocol, currently the collator staking is not designed to operate deposit, better to keep it simple, especially before we are going to re-implement it using smart contract, marking this more like a technical debt instead of being an improvement.
(There is possibility that in the future collator staking contact, a re-deposit call can be introduced to claim from deposit & and burning deposit NFT, re-deposit & minting new NFT, put the NFT under the user's account in collator staking again, But better way should still be using a separate re-deposit contract to manage this for user if they want this and no withdrawal period , and keep collator staking contract simple, reducing the security audit burden for the the protocol and core contracts)

[SasoLithops]

I understand now. Thank you for your time and patience in explaining.
Agree. Simple and no need for any potential security issues.

[hackfisher]

Ah, you are talking about adding an extra lock period in deposit?

That is some advance feature deposit can have, I understand now, it is not related with collator staking, I am fine with it... though I still give it low priority since the RFC can eliminate this issue you mentioned, maybe need to raise priority if we still want to keep withdrawal period because in that case the RFC can not resolve the UX issue perfectly.

(in the smart contract version of staking, the deposit NFT is hold by the collator staking contract, it still need to do that though staking module, if the deposit is staked.)

[SasoLithops]

Yes. Please check the pictures I posted from TG about community members asking about this. Also many of us early stakers have same issue.
We all have to wait 14 days to unbond then withdraw and bond again. Lock extra would be great if it could be added.
That is why I thought we maybe don't understand each other.