It is essential to allow validators to change (rotate) their public KIRA controller addresses as well as validator signing keys in the case where there exists a suspicion that the underlying private key or password which is securing the encrypted key-file was compromised. Since keys are often kept online alongside Tendermint signing keys the risk of being stuck with a compromised address is high, especially when scripting tools such as KM are used. Currently, if the keys are compromised validator has no other option but to create a new address and request governance to allow him to be a node again, this would result in the validator losing access to his staking pool as well as any other incentives accumulated, not to mention delegations and corresponding revenue.

In this proposal, we present a method for the secure migration of KIRA addresses that can be used by both validators, delegators, and users to secure their accounts. The method will utilize a “one-time recovery code” that can be stored offline and used in case of emergencies.

With KIP-76 we introduced a collaborative custody module that made it possible to limit transaction amounts, whitelist withdrawal addresses, password-protect transfers, and collaborative token transfers allowing for the implementation of 2FA. In this KIP we will utilize a very similar scheme where the double hash of a secret combined with nonce can be used to identify the real owner of the account in the case where the address needs to be rotated.

When the user sends recovery-rotate-address-tx full control over the old address benefits should be given to a new one. Once the new address is registered it should NOT be possible to modify it by sending consecutive rotate tx and it should NOT be possible to modify the recovery secret by using the old address. It is really important that the recovery address is unique and never used as recovery for any other account in the registrar, furthermore, the recovery-rotate-address-tx must only be possible to be sent by the recovery address itself. To make things simpler for the user CLI MUST automatically query nonce and combine it with user-supplied “string” secret before propagating tx.

Immediately after recovery-rotate-address-tx is sent the Recovery Module should ensure that all existing modules such as Identity Registrar, Staking, Governance, Collective, Spending Pools, and so on re-map values address -> recovery. If it happens that the address is a validator address then the node status should immediately change to jailed and the moniker re-mapped to the new recovery account. The new recovery address will have to send a claim validator seat tx again to be able to start producing blocks and newly re-mapped governance roles and permissions should enable that.

An alternative implementation would be to create a remap-tx for each module that will communicate with Recovery Registrar and allow a new recovery address to remap the old address into a new one.

It is not really possible to prevent anyone from selling their validator nodes OTC after accumulating delegations, trust, and maintaining good statistics of the performance counters. This phenomenon takes place in the case of large data centers and validators who often sell their businesses. Since the sales executed OTC are not transparent and threaten the security of the network, we propose a model in which users can transparently sell their account to others by representing them as 10'000'000 shares of an rr_<denom> token that can be issued by the account owner through Recovery Registrar and where the <denom> is the lowercase mnemonic as defined in the Identity Registrar. The number of decimals for the RR tokens should be 6, the same as for KEX and the mnemonic should NOT be possible to be modified in IR afterward.

The account that possesses > 50% of the remaining “RR” tokens, MUST have the ability to rotate the account in the Recovery Registrar to his own without the need for proof of the recovery challenge. Furthermore, if RR coins are issued, recovery without the majority of RR tokens should NOT be possible. To make things simpler, the moment RR tokens are issued, the recovery challenge should be removed and not possible to be created unless all tokens are returned to redeem the underlying KEX. This mechanism enables the creation of a market for accounts that generate revenue through staking and other profit-bearing modules in the future.

To prevent spam, initially, only validator accounts should have the ability to issue RR tokens and the Network Properties MUST define a validator_recovery_bond property that will specify the amount of KEX that must be bonded to the Recovery Registrar by the validator in order for him to issue RR tokens (the default should be set to 300'000'000'000 ukex - 300k KEX).

Any user who holds the RR token should be able to redeem the remaining KEX bonded in the Recovery Registrar at the exact amount of total_locked_ukex * (amount_RR_returned/total_RR_supply). The RR tokens should be burned upon KEX redemption. Additionally, we must create a mechanism that will create incentives for people to acquire RR tokens. The simplest method is to modify the Staking Pool module to deposit all block and fee rewards when claimed to the Recovery Registrar, that way the amount of KEX backing RR token will grow over time and the only way to redeem the KEX will be to burn RR tokens. Only KEX should ever be deposited to the Recovery Registrar and no other tokens, even if fee rewards are paid in other assets; all of those other tokens should be redeemable by the validator and not by RR to make implementation simpler.