Introducing Staking Flow V3

When someone is slashed, they are penalized by not earning, which is what happened to me. I fixed the one bad node with a reboot. Then had my 25ish epoch wait. Fair enough… no way for me to “cheat that”.

I see the point that someone could unstake and re-stake to earn more faster. Why not add some kind of flag/penalty specifically for people CHOOSING to unstake that adds another 50 epoch wait. Or doesn’t allow to be restaked until waiting 2 days, or some mechanism like that.

That will prevent unstake/stake abuse without increasing the sync/wait time for people who get slashed to something more unreasonable. Just an idea… I personally don’t plan to unstake or get slashed again any time soon.

The newest deployed staking flow does not create any incentive for validators to stake/unstake frequently.

1 Like

Are you saying to only apply the penalty towards people who choose to unstake and not have any wait time (25 epoch sync) to those that get slashed for poor performance?

It’s each validators responsibility to ensure a well functioning node. Slashing is the deterrent and the 25 epoch wait ensures ample time to sync all the data. The whole purpose is to ensure nodes that are selected perform their role properly.

Ok, I think I understand it better now. I recently staked 3 nodes at the same time, they all got 27 epochs wait-cycle. After that, they ended up with 5, 51, and 50 epochs in the pending pool. Since the pending time after staking is randomized (to make it harder to sync up all your nodes for security reasons), you can end up with a short queue if you’re lucky. This explains why I benefitted from staking a new node last time. But you might as well end up with a long queue, like my 27+51 epochs node. So unless you like gambling, it’s quite pointless to re-stake your nodes. :slightly_smiling_face:

2 Likes