[Feature request] Add max supply cap for cw721

[wrjanan]

To distinguish a limited NFT collection, we will need a supply cap for the minting process.

In order to allow new created contracts upon this 721 base to achieve variability, it might be useful for us to set this state upon instantiation of the contract.

To add:

• max supply attribute in State & InstantiateMsg
• error handling & checking in mint function
• tests

[ethanfrey]

This sounds useful. We have moved those contracts to https://github.com/CosmWasm/cw-nfts where they are being maintained by a number of projects building NFTs. I am sure they would be happy to give feedback on this idea.

[iLoveBusinessDevelopment]

I agree with this wholeheartedly, will makes PR when I get some bandwidth

[sascha1337]

up up, im wondering why max supply cap not yet implemented!

[PFC-developer]

imho, this should be added to the extension, not the base.
not all NFT use cases are the 'collectables' we are currently seeing, and we are making the 'generic' cw721 non-generic anymore

[sascha1337]

gotcha

[the-frey]

100% agree, this should not be in base, it should be an extension, possibly in the -plus repo @JakeHartnell was discussing WRT burning

[JakeHartnell]

100% agree, this should not be in base, it should be an extension, possibly in the -plus repo @JakeHartnell was discussing WRT burning

Yeah, maybe a cw721-plus repo might be nice. A more fully featured base to extend from. See #25 for context.

[wrjanan]

imho, this should be added to the extension, not the base. not all NFT use cases are the 'collectables' we are currently seeing, and we are making the 'generic' cw721 non-generic anymore

Disagree.
Max supply should not be part of extension, as the extension are attributes pegged to the individual NFToken. It would not make sense to have NFTokens with multiple max_supplies under the same collection as it might end up being prone to errors.

Nonetheless, it is a good point to ensure that the functionality of none collectibles NFT are still held true.

As such, maybe we can consider an max_supply with a type of Option, this way, when the attribute is not in the instantiation request of the contract, we can always by default set the max_supply as 1, resulting in a non-collectible NFT.

Though this will force new NFTs to be created only through instantiation which will be costly.

[the-frey]

When we say extension here, there's two meanings. One, the token-granularity Extension, and one, an extension of cw721-base with different functionality, i.e. -plus which we are discussing. I am arguing for the latter, and I guess like you say the param should probably be at contract level.

[PFC-developer]

my meaning when I said 'extension' was more in the programmatic sense.

My first (naïve probably) approach of building extra functionality into my own contract was painful, and I had to fork the base contract and modify it.

I would have preferred to just have the ability to add Exec, Query, Init, & Migrate messages and the ability to add fields (like max-supply) without having to hack the base.

[the-frey]

Good point.

There is actually a broader design issue, which I think as a functional programmer irks me the most... I don't know that all the structs/traits stuff is the best pattern versus just using a standalone bag of functions in a namespace that can be exported and used as/when desired in a very granular way.

I too have found extending the contracts here to be quite painful, see #24 which is quite a simple query extension, but requires wrangling to work.