Transfer Validator Permissions
Replace the consensus public key
If the server is hacked or the consensus public key is leaked, the validator's consensus public key can be replaced by updating the consensus public key transaction.
Before sending the replacement consensus public key transaction, it is best to start the node with the new public key first, so that after the replacement, the validator node will immediately participate in the block generation, and there will be no missing blocks
The val argument should be the validator’s address, for example: fxvaloper1a73plz6w7fc8ydlwxddanc7a239kk45jnl9xwj. In order to get the argument for new-consensus-pubkey, set up a new node and run the following:
Addr/granter: addr is the address controlled by the validator, such as fx1a73plz6w7fc8ydlwxddanc7a239kk45jmwcesj; granter is the address authorized by the validator, which is the address after transferring permissions using the transaction 👇 below, but It is strongly recommended to update the consensus public key first, and then transfer address permissions, because after transferring permissions, the old validator private key cannot control the validator
Transferring Validator Permissions
Transfer permissions
If the validator's private key is leaked, the current validator's authority can be transferred to another address by transferring permission transactions. At this time, the validator's private key will not be able to send any transactions on the chain, and the authorized address can send any transactions for the validator's address
After transferring permissions, any transaction needs to be authorized before the transaction can be sent! If the private key is not leaked, it is not recommended to transfer permissions
After transferring permissions, the old validator address cannot send transactions , and the new permissions must be used to send transactions on behalf of the old validator
The transfer transaction can be executed multiple times, for example, by validator val-1, transferred to addr-1, then the next transfer transaction sent is sent by addr-1, transferred to addr-2
Do not transfer permissions back to the validator addr.
val: Validator address, for example
fxvaloper1a73plz6w7fc8ydlwxddanc7a239kk45jnl9xwjnew-addr: new permissions holder, such as
fx1a73plz6w7fc8ydlwxddanc7a239kk45jmwcesj,addr: Old permissions holder, for example
fx1a73plz6w7fc8ydlwxddanc7a239kk45jmwcesj
When transferring permissions, new-addr and addr signatures are required, as visa permissions and signature transactions are required
Sending Transactions After Transferring Permissions
Authorization
Transfer
Last updated