As you might notice, all basic functions now have a single argument instead of their traditional signature. The one reason for that is the same old encapsulation, and the other is that each
update method now supports batch requests. This means that if you need to perform multiple
transfers, you could to them all at once, during a single function invocation. The same goes for
mints. This would help with cost efficiency of this token.
query methods do not support batches right now, but I believe they should, since one day queries will also charge cycles, so it is reasonable to optimize them as well.
Other thing you might see in the candid above is several “controller”-related methods. Yes, a canister has a controller, but what are these methods for?
A token itself has several permissions. A token could be minted - this is a permission not everyone should have. So, there is a list of principals which should. In the candid this list is referred as
mint_controllers. Only principals from this list are able to mint this token. If the list is empty - no one could mint it anymore.
Current controllers are able to modify their controllers list. So, if you’re a
mint_controller of this token, you can also add your friend to it, so you both could mint tokens for everybody else. This is done via
update_mint_controller function. Or you could pass an empty vec to this method, letting go the control over minting the token.
The same goes to token info - there is an
info_controllers field also. Yes,
decimals can also be changed at runtime, if there is a need for such a thing.
Why do we need such a thing? As the title says, it lets you (and potentially, your token holders) to control your token with better granularity. For example, the
info could be controlled by some trusted person, while minting could be performed via third party canister.
Fun fact: being in the
mint_controllers list you could say “I have a mint controller token of this token”