Since the open staking launch less than a week ago, there have been numerous threads expressing their frustrations around the 7 epoch wait-time to undelegate from any validator. The discussions often stem from the time where early delegators realize in hindsight when some validators that they’ve staked with became un-electable due to the rising tide of the median EPoS surpassing the minimum requirement to be qualified into the top 320 slots.
I’d like to propose to introduce the concept of “Re-delegation” (borrowed from Cosmos) to help boost the confidence of delegators to be early adopters and to earn rewards sooner rather than later. We could throttle the re-delegation assignments to not allow for more than one re-delegation every 7 epochs for the same amount of tokens secured with the newly redelegated validator.
This was also discussed on the Weekly call today. Rongjian expressed that the team is taking a hard look at this, and are evaluating how best to fix the issue, should they choose to fix it.
Unforunately, it will not be simple or fast to fix, as the current 7 epoch undelegation is in part, designed to hold the unelegated ONE as slashable, to ensure that a malicious actor doesnt undelegate all their ONE just prior to an attack on the network. Having to follow the tokens from one validator to the next in order to be able to slash them, in the event of malicious action is difficult.
That being said, I love Jacksteroo’s solution, as it eases complexity of implementation a bit (The tokens only need to be tracked to one other validator) with the “Once in 7 epoch” redelegation rule, and looks after the community as well, giving them a “Do-Over”. If they don’t learn their lesson, and research their second choice more thoroughly, or better yet, diversify their delegation, then in my mind, that is on them.
I support this implementation. I was thinking technically, the network should not be concerned about where the stack is unless it leaves the network and unstaked. This re-delegatiion might even help to more decentralization and more competition in nodes to adjust their bids and also uptime and other parameters which impacts the rewards. the more entropy, the more decentralization.
I totally agree with re-delegation feature implementation but, only for delegators who want to redelegate when their validator goes not elected, else I don’t see the need of re-delegate feature… Why I don’t see this, bcoz most of the validators often start validator with minimal amount of tokens and make the biggest delegations from different wallets not the one used for validator creation, so they also should have the ability to redelegate their tokens staked only when they can’t keep anymore the validator elected and want to stake… But re-delegate feature should not be implemented for faster restake on other validators… Only if validator can’t stay anymore elected…
It can have a filter, like for non-elected validators or as they said, once every X epochs.
It is painful to see how i tried to run my own validator with the coins i bought through the CSA one year ago, got elected just for the first two epochs (3 days), and now i have for about 10 days my coins waiting because I got kicked out of the elected group.
Thanks for the input @C10NU7 … I see your point here. But we’re forgetting another factor about keeping Validators accountable. Besides election, what if that delegated validator
decides to pump the fees all of the sudden?
does not run their service well with low uptimes (while everyone else is fine)?
performed a malicious act on the network and gets banned / slashed?
IMO, the re-delegation functionality will keep validators accountable even more. Happy to hear more feedback, community gathered ideas are the best!
Max Fee Change: 10.00% (per day) it’s the maximum fee that the validator will ever be able to set for their services. This it can only be set once at the creation of the validator and it cant be changed later ,main reason why is very important to look at this “Max Fee Change” .It has effect from next epoch and it cant be higher than it is displayed on the dashboard only if the user/entity/group starts from scratch a new validator with new rates and changes.
It’s a risk assumed by delegator (delegating ,trust,etc) and also by validator if he doesn’t handle well his validator ,it will have some losses and of course bad repo !
Even if you perform re-delegation ,your wallet/address/previously delegation it will still be 7 epoch under the risk of slashing. And let me explain why. Bcoz like i have said in previously message ,most of the validators start with minimum amount the validator and delegate from different wallets the higher amounts of tokens. So, if this validator is a bad actor, it’s impossible to track his wallet used for delegations and not only the one used for validator created. And because of this all the delegations or re-delegations will be forever 7 epoch under slashing even if you moved your tokens from this malicious actor. I hope my answer has logic and it’s a good explanation.P.S. sorry for my english ,not a native language, thank you !
I think I get what you mean. Extending this a bit.
The “Max Fee Change” is the “max-change-rate” and NOT the “max-rate” the validator can impose over time. So if the “Max Fee Change” is 10%, over 10 days, it could be at 100%, the “max-rate” is not displayed on the Staking Dashboard
As for the risk, the re-delegate is an option that delegators can pull the lever, to help de-risk their stakes. Make delegators “feel safer”, if you will
There’s a programmatic way to put the newly re-delegated tokens through the new “cooling period”. It’s up to Harmony to impose the rule on the slashing or not for a malicious node at this time, for the validator’s self stake and whether or not to include the delegators who “ran away” which may include the validator’s own personal wallet. I’m not sure which direction to take here.
I vote for re-delegation. It will build trust from a delegator’s standpoint, and I also like to see the value of my current holdings presented when I login with my wallet.
