Allow the account with permission to mint an asset to transfer this permission to a different account, or to disallow future mints forever.
- Account: A simplification used to represent a spend key and it’s derived key parts.
- Asset Creator: The account used to create the first mint of asset. This account’s public address is used to derive the asset identifier, and is by default, the first owner.
- Asset Owner: The account that may mint an asset. There can only be 1 owner per asset at a given time.
- Freezing an asset: Make it impossible to mint any more tokens of an asset. Has no effect on the circulation or transfer of the existing tokens.
MintDescription of a
Transaction to allow changing the asset owner. This is accomplished by adding a new optional field to the
transferOwnershipTo which would contain the public address of the account to transfer ownership to.
This allows the key responsible for minting an asset to be rotated. This also allows an asset to be “frozen” by transferring ownership to a throw-away address like ‘000…000’. This brings IF a step closer to supporting NFTs.
Nodes would be responsible for storing this new owner field in the asset database as well, so verification can be done at the consensus level. This new owner would be passed in as a public input to the mint description proof for verification. This would not require any changes to the zero-knowledge proofs.
The current field known as asset owner would be renamed to asset creator, for clarity. The creator’s only purpose once the creator transfers ownership is to be used as part of the asset identifier pre-image.
When an asset is minted for the first time, the creator is by default the owner, unless the initial mint also contains a transfer of ownership.
Due to changing the format of the MintDescription, this would require a hard-fork since outdated nodes would only validate mints by the creator, regardless of whether the owner has changed or not.
The reason this is important is that, currently, there is no way to change the owner key of an asset. This is a security problem, because if the key is leaked, the asset is now useless and can no longer be used or trusted since an attacker could mint an arbitrary amount forever-more. This would defeat the purpose of bridged assets from other networks, NFTs, etc.
With this change, asset owners can practice good security practices by regularly rotating their keys, and keeping a fresh key ready to transfer ownership to in the event of a suspected issue.
This could be implemented by separating the asset owner into 2 pieces: an asset “master” key, and an asset “mint” key. The master key’s purpose would be to modify the mint key or the master key, but would probably have no power to mint an asset itself. The mint key would be responsible for minting or transferring mint permissions to another key.
- This approach is more robust, but also would require greater complexity to add. It would likely require 2 separate descriptions, one for the “master” key operations, and another for the “mint” key operations. Combining them into 1 description is probably possible, but feels like it would lead to overly complex implementation logic, leading to greater possibility of bugs.
- This initial proposal does not exclude pursuing this implementation at a later time.
- In the effect of a mint key leak, the asset owner could rotate the mint key leak without the risk of the asset being frozen by the attacker.
- This would require an explicit mechanism to allow freezing of an asset since the master key could override the mint permissions at any point