The answer is in the name of the token : SuperRare
.
There is a negative correlation between the value of an asset and its total supply, even when the tokens are non fongible.
That's why we see some NFTs being sold for 100 ETH.
Holders can be both creators and collectors :
- creators when the NFT is minted, it can then be put in auction for exemple
- collectors when the NFT is traded.
For the submit token burn details
info I believe this is an option for the contract owner who can communicate to Etherscan the token’s burn history.
UPDATE
The SuperRare smart contract implements ERC721Enumerable
. In this contract we have the array _allTokens
counting the number of NFTs :
// Array with all token ids, used for enumeration
uint256[] private _allTokens;
Then we have the totalSupply
function which returns the length of the previous array :
/**
* @dev Gets the total amount of tokens stored by the contract
* @return uint256 representing the total amount of tokens
*/
function totalSupply() public view returns (uint256) {
return _allTokens.length;
}
Note that (unlike ERC20), the totalSupply
method is not part of the base ERC721 standard, but is implemented by ERC721Enumerable which is an enumeration extension smart contract for ERC721.
Finally the mint function :
/**
* @dev Internal function to mint a new token
* Reverts if the given token ID already exists
* @param to address the beneficiary that will own the minted token
* @param tokenId uint256 ID of the token to be minted by the
msg.sender
*/
function _mint(address to, uint256 tokenId) internal {
super._mint(to, tokenId);
_allTokensIndex[tokenId] = _allTokens.length;
_allTokens.push(tokenId);
}
We can see the _allTokens
array is incremented after a mint
. Conversely, it is decremented after a burn
.
The totalSupply
is therefore not fixed, which is logical given the ambition of the project to create an art marketplace.
There's a few ways to do it that I've seen.
- Use attributes
All the attributes are stored succinctly into one variable of 256 bits. If you can create a repeatable process to create an image from attributes and you can guarantee that every different valid input creates a separate image then you're good. It is trivial for the smart contract to validate non-duplication. (See CryptoKitties)
- Precalculate
You can precalculate all possible images. Then as tokens are minted the guaranteed-unique image is available. The entire set can be committed up-front, even if not publicly known. (Related to CryptoPunks)
- Trust
As new tokens are minted they do not have any image at all. Then, asynchronously, you will create and publish those images. The smart contract does zero validation here and people must trust you.
Best Answer
Yes, it can be done by creating a contract that inherits from
ERC721PresetMinterPauserAutoId.sol
preset. Then you can use the internal_mint(address to, uint256 tokenId)
function to specify the id. If the preset is not needed, the plain ERC721 contract can also be used. Same is true for the ERC1155 standard. You can find these contract standards in the OpenZeppelin repo.Sample code in solidity: