Also, +1 on minting & burning tokens.
I.e., would you just require some fixed operation (such as rewards in the NNS) that can mint, or are you looking for something like a method “mint X tokens now” that can be called by the governance canister, or even something that just automatically mints a certain number of tokens per time period to some account ?
I think both are valuable. In fact, the heartbeat “cronjob” feature of the IC is pretty unique and could lead to interesting tokenomics.
At least for me, I’d like a variable token supply mostly for token rewards. The alternative is a fixed token supply, where token rewards (e.g. for posting valuable content on a social dapp) are provided by a treasury account. I think that’s much more limiting and even risky, as you can’t predict how many users and thus rewards your dapp will have to give out. With a variable token supply, you could vary inflation based on user activity, time, etc.
Just like NNS rewards, I expect a variable token supply to be more useful for most dapps. After all, it’s a generalization of a fixed token supply.
or are you looking for something like a method “mint X tokens now” that can be called by the governance canister
I think this is an interesting question.
Let’s say a dapp wants to algorithmically reward a user with X tokens for something they’ve done. Which approach is better?
The SNS ledger canister exposes a “mint token” method that only the dapp canister can call. (The governance canister wouldn’t call it because the tokens are minted as a result of some business logic algorithm, not a governance proposal.) The dapp canister then calls that method, which mints X tokens and directly deposits the tokens into the specified user’s account.
The SNS ledger canister exposes no custom method, and instead algorithmically mints tokens, depositing them into the account of the dapp canister (i.e. the reward pool or “treasury”). The dapp canister can then choose to transfer X of the newly minted tokens to the user.
Approach 1 is less safe, as the dapp canister could get hacked and then mint a bunch of tokens into the account of the hacker by calling the “mint token” method.
Approach 2 is less flexible, as the SNS ledger canister now needs to implement the algorithm to decide which users get how many tokens. What if that algorithm needs to be updated? Upgrading the ledger canister is possible via SNS governance proposals (the same way the dapp canister would be upgraded), but it’s arguably more risky to upgrade a highly sensitive ledger canister than a dapp canister.
What do you think? I’m not sure which is better.