- Author: anon_real
- Status: Proposed
- Created: 10-May-2022
- License: CC0
- Forking: not needed
NFT collections play a central role in the nowadays NFT ecosystem on all blockchains. It gives the ability to artists to organize their artworks and present them in a more meaningful way. It also can facilitate the use of other NFT features such as traits. As we'll present in this proposal, it can also enable more advanced features such as artist collaborations. These advanced features can get arbitrarily complex with the use of smart contracts.
We consider collection NFTs as tokens! Following the design pattern in artwork standard, we store the collection information in the issuer box rather than the issuance box so that this information is verifiable in smart contracts. The issuer box will contain all the collection information. Moreover, the issuance box will also contain some overlapping information for readability reasons.
An NFT will be considered as part of an already created collection if it follows the artwork standard and the collection NFT is present in the first input of the issuance transaction, also known as the royalty box or the issuer box.
There is no limitation on the number of issued tokens for a collection. One possible interpretation of such a feature is that artists can come together and create a collection. Each one of them will have one collection token which gives the right to them to add NFTs to that collection. We believe that with the use of smart contracts, more advanced usage of this flexibility will be discovered in the future.
One of the main goals of this proposal is for the standard to be as future-proof as possible. To achieve that, some of the features we introduce here may not contain an extensive explanation of how to use them. This enables NFT developers to participate in the EIP and also plan for their tools. However, it comes with the downside that this EIP will be prone to backward-compatible extensions in the future. The following sections must be present in the issuer box of the collection.
Collection standard version must be present in R4 as Int. This current standard version is 1. This will enable future radical changes depending on the state of the NFT ecosystem.
Collection info must be present in R5 of the issuer box as Coll[Coll[Byte]]. The following is the needed info:
["URL_TO_COLLECTION_LOGO", "URL_TO_COLLECTION_FEATURED_IMAGE","URL_TO_COLLECTION_BANNER_IMAGE", "COLLECTION_CATEGORY"].
Name and description of collection must be present in the issuance box which follows eip-004.
The above structure must be encoded as Coll[Coll[Byte]].
Socials may be present in R6 of the issuer box as Coll[(Coll[Byte], Coll[Byte])]. There are no restrictions on what socials to include. However, the name of the socials must be in lower case. The following is an example of socials that needs to be encoded as Coll[(Coll[Byte], Coll[Byte])].
[ ("twitter", "TWITTER_PROFILE_URL"), ("instagram", "INSTAGRAM_RPOFILE_URL")
R7 of the issuer box must contain the expiry timestamp of minting in the collection as Long. After this timestamp is reached, no NFTs should be minted in the collection. Because tokens by default are not tied to smart contracts, this timestamp can not be forced. However, it can be verified by marketplaces. Moreover, the collection tokens can be locked within some smart contract that forces this feature. If there is no expiry, this must be set to -1.
R8 of the issuer box is reserved for additional information that might be needed in the future. The type of this register is Coll[(Coll[Byte], Coll[Byte])] and it is supposed to represent a json with the following format:
{
"key1": "value1",
"key2": "value2",
"...": "..."
}Auction houses should add the information (i.e., "key", "value" and what it is intended to show) to this part before using it. Otherwise that piece of information is not considered to be part of the standard.
Unlockable contents are files or other types of information that the artist reveals to the buyer when an NFT is sold (and/or some other conditions are satisfied). At the time of proposing this EIP, there are no known decentralized solutions to have unlockable contents. However, it is more than likely that we'll have solutions soon. So we anticipate that this EIP will get updated by using the remaining registers to have this feature.
Following the asset standard, R4 of the issuance box will contain the collection name and R5 will contain the collection description.
Just like EIP-24, the artist of a collection is determined with the first P2PK input in the chain of transactions leading to the artwork issuance.