Account Transfer

As mentioned above, transferring an account to be controlled by a new signer is accomplished in two steps: naming the new account holder and then completing the transfer from the new signer. In addition to this transfer there are some other details to know about account transfer. First, a new account owner cannot be named if the account is staked for any datasets. Second a new account cannot be named if a new account was named too recently. Third, a signer can only control one account at a time. Fourth, after a new account signer is named, the account cannot be transferred if the account was transferred too recently. Additionally, the account cannot stake for datasets for a period of time.

The purpose of not being able to transfer accounts while staked is because the datasets don’t work with accounts, but rather signer addresses, so a user has to complete their ongoing datasets in order to transfer the account and not lose track of the staked-for datasets. If the private key of a signer is compromised and the user does not want to lose their ODO account, then the user should withdraw from any datasets, and switch their account. The reason for there being a cooldown on naming a successor is because if someone’s account is compromised, then the attacker could change the account to their own address if they knew how. With the cooldown, as long as the original user can change the account successor first, the attacker will not be able to prevent the user from saving their ODO account by changing the account to another address before the account owner can make the transfer. The last condition is simply a deterrent that slightly devalues transferring an account. In an emergency when keys are compromised, the protocol shines. If someone simply wants to sell their account, that’s less the intention of the feature, hence the deterrent.