Add max-supply param to mint module

[anilcse]

Summary

Currently a number of Cosmos based chains are announcing max-supply for their tokens but practically there's no hard-limit configurable in cosmos-sdk

Proposal

Introduce a new genesis param max-supply for mint module.
Newly minted tokens should consider this limit

[tac0turtle]

teams that have a max supply are not using the cosmos-sdk mint module, they have forked. We should see what they have added and upstream (evmos, osmosis are two that come to mind)

[alexanderbez]

What would adding this parameter do exactly? Say we add it, we don't actually use or enforce maximum supply? Or are you suggesting that we add this param and limit minted tokens?

[anilcse]

What would adding this parameter do exactly? Say we add it, we don't actually use or enforce maximum supply? Or are you suggesting that we add this param and limit minted tokens?

Yes, this param will limit minting

[alexanderbez]

I mean I'm not necessarily opposed to it. But also, there really isn't any chain I know of that uses x/mint and has a capped supply.

[akure]

This is a good feature to be added to the mint module. This is actually an invariant though.
What should be the default behavior of the chain after it reaches the max_supply value? Maybe it can continue running and validators will stop getting the inflation part as there will not be any inflation. The rest of the logic should be dependent on chains about what solution they bring to incentivize delegators and validators.

[anilcse]

I mean I'm not necessarily opposed to it. But also, there really isn't any chain I know of that uses x/mint and has a capped supply.

Akash and Passage have capped supply (on paper), they are planning to adjust the inflation (based on estimated timeline)

[tac0turtle]

would the interaction with the cap be effected by token burns?

[anilcse]

would the interaction with the cap be effected by token burns?

Hmm, not sure. But I think it should consider burned tokens or they should be sent to a burn address (such that IBC mint/burn doesn't get effected with this)

[akure]

I think - Effectively, It should be like.

current_total_supply = total minted so far + total burned so far

Two cases should be handled -

1. Case 1 -
   If current_total_supply + expected_new_minting > max_supply then mint the diff ( max_supply - current_total_supply) and set the current_total_supply = max_supply
2. Case 2 -
   If current_total_supply = max_supply, don't do anything.

Though this should be checked continuously on each block due to the possibility of burning. Whenever sufficient burn will happen, current_total_supply will be less than max_supply.

[tac0turtle]

Im open to adding this feature. We can add it in the simplest form of only a max of supply + burned and later one refactor it base of better calculations of mint and burn