We need to re-write the asset module to accommodate more features and improve its token management mechanism:
Details:
We'll go into details of the new features/changes to be included in the module
System of privileges
Asset module should support a system of privileges, each with its own logic to manage token created by the module. We want our privilege system to be scalable, meaning that our code base should be extensible for adding new type of privilege (easy to upgrade, simple migration process). In the first version, we decide to include the following privileges:
-
Mint/Burn:
-
Transfer admin privilege
- Whitelist addresses to allow them to transfer token of said asset
-
Clawback
- Clawback feature to withdraw token
-
Freeze privilege
- Freeze assets in case of emergency incident
Gov token
Right now, all the asset module token is created and managed by an on-chain accounts which covers most business use cases for a token model. However we could utilize the gov module to allow for a token that is created and managed by the community. This could open up many possible use cases for our asset module where decentralization is needed.
Allocations at creation
After creating a token, the token manager should be able to allocate balances of that token by providing a genesis-like file that specifies all the balances (also allow vesting balance). This action can only be triggered once.
Expand token namespace
The denom of an asset token should be prefix with the creator address so that we expand the namespace of asset module tokens. Now token creators can freely choose any name for their token without conflicting with tokens (that has the same name) created by other creators.
Remove transfer message
Transfer message does the same things as bank send message. We should remove it so that we only use bank send message, following cosmos-sdk standard.
Creator verification via gov
Only addresses that is approved via gov have the right to create an asset. This is to prevent spamming or scamming asset tokens.
Tasks
We need to carry out these tasks in the following order:
We need to re-write the asset module to accommodate more features and improve its token management mechanism:
Details:
We'll go into details of the new features/changes to be included in the module
System of privileges
Asset module should support a system of privileges, each with its own logic to manage token created by the module. We want our privilege system to be scalable, meaning that our code base should be extensible for adding new type of privilege (easy to upgrade, simple migration process). In the first version, we decide to include the following privileges:
Mint/Burn:
Transfer admin privilege
Clawback
Freeze privilege
Gov token
Right now, all the asset module token is created and managed by an on-chain accounts which covers most business use cases for a token model. However we could utilize the gov module to allow for a token that is created and managed by the community. This could open up many possible use cases for our asset module where decentralization is needed.
Allocations at creation
After creating a token, the token manager should be able to allocate balances of that token by providing a genesis-like file that specifies all the balances (also allow vesting balance). This action can only be triggered once.
Expand token namespace
The denom of an asset token should be prefix with the creator address so that we expand the namespace of asset module tokens. Now token creators can freely choose any name for their token without conflicting with tokens (that has the same name) created by other creators.
Remove transfer message
Transfer message does the same things as bank send message. We should remove it so that we only use bank send message, following cosmos-sdk standard.
Creator verification via gov
Only addresses that is approved via gov have the right to create an asset. This is to prevent spamming or scamming asset tokens.
Tasks
We need to carry out these tasks in the following order:
AppModulerequirements