The SRC3 standard currently requires passing a SubId to the mint function.
While this increases flexibility for developers to reserve specific IDs etc., it does come at the expense of easy minting and potential collisions for DApps implementing minting.
This requires DApps to know which SubIds have already been minted, especially in the case of NFTs.
Common practice in other e.g. EVM for a ERC721 mint function is to always mint the next available token ID and store the last minted SubID on the contract.
What’s the reasoning behind the current design choice and what would be your recommendation here?
ERC721 does not require you to mint the next tokenId either. As you said, its just common practice. Regarding a recommendation, just store the next token id in storage and use it for mints, just like the ERC721 implementations do
However, as opposed to the ERC721 (which doesn’t define a mint function), the current SRC-3 contains a mint function that requires passing a SubId, hence not allowing for token sequentialization without external decision-making.
So currently, if you want to make a contract with sequential token minting, similar to ERC721, you’d need to break the standard aka not use SRC-3.
While we see this practice in something like NFT profile pictures with a mint limit of 10,000, this is quite limiting. We wanted to ensure the SubId could contain some data.
As a SubId is just a b256 hash, anything could be encoded here. In the case of profile picture NFTs, perhaps the SubId is some data such as the URI which can then be verified against. Or the sha256 hash of the ID number I.e. sha256(token_id).
If you desire to increase the SubId sequentiality, this functionality can be baked into the function or done by hashing the token id. The SRC3 standard only defines the ABI, and not the underlying implementation.
Yes I understand that this is one of many use cases.
Let’s assume the following:
NFTs would be minted not just on one platform, but on other 3rd party platforms as well, allowing for greater ecosystem adoption
Having whoever is using the contract and its mint function be responsible for knowing/deciding which Asset / SubId to mint here seems like a recipe for unnecessary complexity - WDYT?
So basically regardless of the use case, if we want to allow multiple platforms to mint from a specific contract to allow for ecosystem spread - not putting the onus of deciding the SubId on the implementor could be beneficial.
Are you suggesting to basically pass anything into that function so basically any random value as SubId and have the implementation of the function increment?
(This was what I was going to do anyway, felt like a hacky way to use the standard though tbh - hence I wanted to raise that conversation)
I can also think of various use cases besides 10.000 profile pictures here such as Gaming Assets or other RWA where not putting the onus of knowing the SubId to mint can be beneficial to unlocking ecosystem adoption.
You are more than welcome to apply the payable attribute to your own definition of the SRC-3 standard. Attributes are not specified by the standard Sway Standards | Fuel Docs
Having whoever is using the contract and its mint function be responsible for knowing/deciding which Asset / SubId to mint here seems like a recipe for unnecessary complexity - WDYT?
I could see the case for having the sub_id argument be an Option to open the door for this.
That’s exactly what I did, basically a SRC3PayableExtension
The Option would be a great change in the standard, so that you know we don’t have to veer of the standard for something like this, but can still contain our contracts within your set standard.
Thx for talking at through, let me know where you guys land.
