Hitherto, the flow of releasing NFTs to users is mostly based on pre-minting Data objects and then allowing for the launchpad to mint the Nfts to the user (currently, embedded NFTs are pre-minted themselves and transferred them to the Launchpad, but this will be changed and will follow the same flow as the loose NFTs).
Whilst the launchpad is useful for great deal of use cases (mainly all that require some custom primary market solution), there are some use cases that would benefit from not having to use the launchpad. In order to better understand which use cases may not require a launchpad, let us define all the use cases and their release flow pattern:
The data is pre-minted on-chain and Users come to the protocol to mint the NFTs (e.g. Digital Art with on-chain attributes can be pre-emptively minted in preparation for the launchpad - similar flow to Solana's Candy Machine)
The data is pre-minted on-chain and Creators send the NFTs to users (e.g. For more asynchronous release flows such as the minting of gaming assets which happen when players are playing games)
The data is minted on the fly with the NFT and sent to the users where:
a. The data is defined by the NFT module itself (e.g. for Simple NFTs where the data still remains off-chain, the NFT can be a simple URL where each time a NFT is minted a counter is increase and thus generating a URL for the corresponding image - see this issue for more)
b. The data is defined by the users themselves (e.g. for Domain Names, the creators cannot possibly pre-emptively mint every single domain name, therefore users are the ones minting the data on the fly with the NFT and there should be a registry implementation that checks if a certain domain name already exists)
For the 1st pattern:
MintAuthority → Must be a private object owned by the creators
Launchpad → Must be a shared object
For the 2nd pattern:
MintAuthority → Must be a private object owned by the creators
Launchpad → There is no such thing as launchpad, the NFTs are minted directly by the MintAuthority
For the 3rd Pattern:
MintAuthority → Must be a shared object
The way data mint must be decided via:
some code logic (a)
or by the user, subject to set ownership test (via registry which is a probabilistic data structure)
Hitherto, the flow of releasing NFTs to users is mostly based on pre-minting
Data
objects and then allowing for the launchpad to mint theNft
s to the user (currently, embedded NFTs are pre-minted themselves and transferred them to the Launchpad, but this will be changed and will follow the same flow as the loose NFTs).Whilst the launchpad is useful for great deal of use cases (mainly all that require some custom primary market solution), there are some use cases that would benefit from not having to use the launchpad. In order to better understand which use cases may not require a launchpad, let us define all the use cases and their release flow pattern:
For the 1st pattern:
MintAuthority
→ Must be a private object owned by the creatorsLaunchpad
→ Must be a shared objectFor the 2nd pattern:
MintAuthority
→ Must be a private object owned by the creatorsLaunchpad
→ There is no such thing as launchpad, the NFTs are minted directly by the MintAuthorityFor the 3rd Pattern:
MintAuthority
→ Must be a shared object