No redelegation cooldown after validator is Jai!ed

the word Jai!ed is not allowed in agora so I am using Jai!ed instead
I propose to change the redelegation cool down from a validator is Jai!ed to no cooldown (cooldown meaning the 21 days you have to wait after you redelegate to a validator)

recently I noticed that after you redelegate to a validator you have to wait for 21 days before you can redelegate from the said validator to another one, this becomes a problem when the validator is Jai!ed and your coins are stacked either in the undelegated period or the time that has to pass since you redelegated to the Jai!ed validator

I will start by properly explaining the problem:
example: I recently re-delegated from validator X to validator Y 1,000,000 coins and validator Y didn’t update to v2 and is now Jai!ed after this I have 2 options either undelegated and wait for 21 days or let the 1,000,000 coins sit there and wait for 21 days to redelegate to another validator.
this current situation punishes me: the guy who wants to delegate and help the network (and also make %APY) and makes me lose 3 weeks’ worth of reward on my delegated coins and all because the validator didn’t update to the latest version. It’s a lose-lose situation and there is no way out of it without waiting for 21 days.
I propose a change that will remove all redelegation cooldown from the Jai!ed validators to allow stakers to move their coins to another validator without waiting for 21days and losing 3 weeks of rewards

redelegating coin to stake with small validators becomes safer because even if they diced to quit for some reason you can just move your coin in seconds and keep getting the staking rewards

I apologize for spelling mistakes or grammar problems English is not my first language thanks for understanding<3


I propose putting this work into the L1 task force for the q2 work (open to discussion)

Everything in here is open to discussion plz feel free to give opinions and feedback.

And re-delegating from validator Y to validator Z doesn’t work? Normally, it’s re-delegate to the old one (validator X) where you have to wait 21 days

1 Like

No, once you re-delegate from validator X to validator Y you cant re-delegate from validator y until 21 days pass so re-delegating from Y to Z also doesn’t work.
thanks for asking tho<3

just did another test to make sure I am correct and I am correct once you re-delegate to a validator you cannot re-delegate from said validator until 21 days passed.

I have pitched this around a few times. I’d refer to it as “delegator liveness.”

Likely needs some kind of minimum thresholds to determine it. For example, how long does the validator need to be [shut down] before redelegation is allowed?

Here are a couple edge cases where this kind of feature hits a bump:

  • An important vote goes live – such as a spend proposal
  • Some server attacker perceives that the largest validators (by % voting power) will cast a vote in favor or against it (the opposite of the attacker’s interests)
  • The minimum [shutdown] time to instantly redelegate is 5 minutes.
  • The attacker DDoS’s (or similar) the nodes that could swing the vote in either direction for >=5m.
  • Users reroute voting power before the final votes are tallied to swing in favor of the attacker.

Again, this is an edge case, but it is important – additionally so because voting power also determines the delegators’ yield via the Oracle.

Also, [shutdown] is a punishment to the node and its delegates for the reasons related to security as it relates to Proof-of-Stake. If your validator does not maintain liveness, then there is mutual fault. However, I understand that edge cases like this happen (considering I had to rapidly shut down due to costs and poor planning).

On this note, the tl;dr = what’s the threshold for [shutdown time] to allow instant redelegation?

1 Like

How long a validator needs to be jai!ed before re-delegation is allowed:
the time that should pass from the moment the validator is jai!d to the moment that you can re-delegate from the spoken validator would be a at least couple of hours so that this edge case that you mentioned will not be allowed

shutdown is a punishment to the node and its delegates
this statement is correct but I think in the scenario that we are in we can waive the punishment to the delegator
here are the reasons:

1: We have a really centralized chain, we have a Nakamoto Coefficient score of 3 (that means that the 3 biggest validators have more than 33.3% of the voting power) in compression cosmos (atom) chain have a Nakamoto Coefficient of 8
this creates a situation that can lead to a scenario where a few large validators control the chain and can pass any prop that they want whether the prop is good or bad for the chain, and even shut the chain down. we want delegators to delegate to smaller validators so we can have a more decentralized chain, to achieve this need to make it safer to allow delegator to move their coins to smaller validators without being scared for their reward (after all this is the reason they delegate at all).

2: We have an unstable chain, in the current state of things most validators are currently losing money (a validator need to make more than the power and the operating cost of the node if anyone has the formula feel free to drop it here) that means that many small validators (which are the majority)
are losing money and are operating out of pocket, which means that many validators can go down any minute when the operator runs out of money and can’t cover the bills.
this causes the validator set to be under 130 that the chain need. the validator set changes almost every week (because validators are going down) and that creates unstableness and fear among delegators, this makes it more appealing for delegators to delegate to bigger more stable validators

I hope this makes it better sorry for any misspells and grammar issues English is not my first language and plz replay with any questions and problems you might encounter!

Why not just automate interim redelegation randomly amongst the active set during shutdown?

How long do you expect lack-of-liveness to be there? If it’s a few hours to a few days, then auto-redelegation diversified amongst the random set will work well.

Here’s an example:

  • delegating to Validator ABC
  • Validator ABC experiences downtime of 3 days
  • Validator DEF, GHI, JKL, and XYZ receive those delegations after 3 hrs of downtime
  • Those delegations are re-routed back to Validator ABC after 6 hours of uptime

I was working on something like this for Onyx. Or at least, I wanted to. Theoretically, it would be transferable to a “machine” node.

1 Like

to be honest this is a really good idea, its good to have a “killswitch” that triggers delegator coins to scatter across the validator set we can set this to the default option and add an “expert” option that allows the user to re-delegate to a specific validator. but the idea that a person with no prior knowledge and experience will automatically be taken care of and will now lose the delegation rewards is awesome
I will work on a new and detailed page that will condense all of the things that we talked about and then will be able to continue to make this better