Feature: after change-consensus-key gets applied place the validator in a temporary time-out phase or automate the key swap.

[zenodeapp]

Don't know if this is already happening, but coincidentally my validator got below the threshold-set in the 2 epochs after I did the change-consensus-key command (or atleast this is what the CLI tells me).

It might be great (well great is a big word) to timeout the validator for one more epoch to get the switching of consensus keys sorted; though automation would of course be the most ideal solution. (not so much in hindsight, see the next comment)

Also giving a note in the validator-state command so that validators are aware of the change that is going to take place, or needs to be done, that epoch would help.

[zenodeapp]

For automation: I dunno to what extend the ledger is able to locally schedule a system operation like swapping keypairs. Edge cases to consider is when someone deletes, moves these keys or renames them. But I'd think thrice before automating that particular portion to prevent this whole change-consensus-key jailfest occurrence 😅. Automating this is a dangerous operation to consider, should preferably be the responsibility and in the hands of the validator itself.

I'd go with safety and keep it manual (the generation of the new key-pair could be automated and stored under a new name though), but have that extra epoch to get things sorted. Or just leave it as is, but it's difficult to sometimes time an epoch change.

[brentstone]

@zenodeapp thanks for bringing this up. I'm assembling all the issues related to consensus key change UX under one issue #2664, so I'll close this one for now.

I agree that automation may be difficult and tricky, so at first I think we will aim to give some thorough instructions at the CLI output after a consensus key change. Feel free to comment further suggestions on #2664.