Split vault keys into control and stash about interbtc HOT 1 OPEN

Changes

I am expecting the VaultId to contain the AccountId for the stash key, the control key will be defined separately.

• Add control: AccountId to the Vault struct
• Ensure origin of register_address is signed by the control account
• Ensure origin of accept_new_issues is signed by the control account
• Ensure origin of request_replace is signed by the control account
• Ensure origin of withdraw_replace is signed by the control account
• Ensure origin of accept_replace is signed by the control account
• Ensure origin of cancel_replace is signed by the control account

Since the VaultId will comprise the stash account (to minimize changes and since the control account may change) any function which checks the validity of the origin for the control account should require either a stash_id parameter for lookup and comparison or we may decide instead to define a separate storage map in the vault-registry.

Migration

Follow this implementation to iterate through all Vaults in storage and set the control key as the stash (VaultId) key.

Other Notes

Extrinsics which target nomination / staking & rewards will use the stash key by default, if we want a running Vault (signing with the control key) to be able to claim rewards on behalf of the stack account we may want to consider an alternate approach.

Related reading: https://docs.substrate.io/v3/concepts/account-abstractions/

Client Changes

I would expect the client changes to be largely incidental to most users. That is for auto-registration, the current Vault should use the same key for both control and stash. The front-end Vault dashboard should allow advanced registration for the stash account to explicitly set the control key.

from interbtc.