feat(bank): extend bank keeper by providing a convinient funtion to mint tokens to an account.

[robert-zaremba]

Summary

Current minting function is designed only for minting tokens to a module. For further adoption of the x/bank module we need a function to mint to any account.

Problem Definition

In the NFT ADR discussions we were proposing to use x/bank to manage assets. People were afraid that it will require additional refactoring. In fact we don't need much to make token minting more usable for wider usage. For minting, we need a dedicated method to mint for any account with appropriate event.

Proposal

• add bank keeper method to mint to any account
• extend the mint event by adding an optional attribute: recipient

Followup

Design better minting permission mechanism.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[robert-zaremba]

cc: @aaronc , @haifengxi , @alexanderbez , @fdymylja , @jgimeno

[fdymylja]

Which component decides who/what has the authorization to mint a certain asset?

[alexanderbez]

I imagine it would be up to the module(s) in concern to decide who/when gets minted coins. I can definitely think of certain use-cases where this would be useful. Today, if you wanted to to this, you'd have to mint to a module account and then send those tokens from the module account to a regular account. So this proposal just seems to save us one step?

[robert-zaremba]

yes, directly mint to an account and emit appropriate event.

[Tectract]

Hello, my team is looking at this issue right now because we have a chain with "security tokens" and we need the ability to mint the tokens (increase token supply) for a non-staking token, to correspond to security share issuances.

In our case it would be fine to have one authorized account be able to "mint" tokens by adjusting token supply, and it would also be nice to have the ability to REDUCE the token supply also, to help deal with share splits or warrant transfers.

Another feature here that would be AMAZING is the ability to issue dividends to everyone who holds one asset, while the dividends would be paid in another token (dividends cannot be paid in the same token or it is legally considered a share "split") and we could choose the dividend payment rate and token to pay the dividend in, and the dividend would be paid to all token-holders proportionally depending on their balance.

It would also be nice to have the validators be able all vote to increase/reduce a given token supply at a given block-height. In our case we have a private blockchain where all the "staking" tokens are held by us, essentially, so in a normal / public blockchain you maybe (probably) wouldn't want the stakers to be able to vote to increase the token supply, normally... It might be in their interest to be able to reduce token supply though and in that case maybe there should be a way to reduce supply by getting rid of UNALLOCATED (owned by the authorized address) tokens versus a proportional reduction in every token-holder balance and a proportional reduction in the unallocated supply also.

In the case of a security share issuance and an increase in the total token supply:

1. in the case of a normal issuance you would increase the token supply and issue new UNALLOCATED shares, and the new tokens would need to be owned by / issued to an authorized address in this case, so they can be then sold as securities to new investors and transferred from the authorized account to new accounts

2. in the case of a share SPLIT you would increase the token supply and every shareholder's balance proportionally at the same time and no new unallocated shares would be created

So there actually may need to be a way to increase token supply in these TWO ways, to deal with security token issuances and splits.

[Tectract]

Sorry my last post was a little rambling, here's an important note for dealing with security tokens:

1. For normal share ISSUANCES we need to be able to increase the token supply by adding tokens to the balance of an authorized account. Probably this would be the same account authorized to adjust the token supply, so that would likely go in the genesis config.yml

2. for share SPLITS we would want to increase token supply and increase all token-holder balances PROPORTIONALLY

[tac0turtle]

closing in favour of #17579. We plan on redesigning bank and possibly introducing a reserve module to handle minting