In my previous post, I described the extensions of the most used token standard — ERC20. Now it’s time for the second most popular token standard — ERC721. All extensions come from the OpenZeppelin library.
The core interfaces
The main and also the only obligatory interface is ERC721, which is the simplest implementation of ERC721 standard. Except this, there are two core implementation: ERC721Metadata and ERC721Enumerable. To the most important interfaces, we could also count IERC721Receiver, which is different from the rest I mentioned.
ERC721Metadata
This interface allows us to add the name and symbol to our tokens. Moreover, it implements a public function tokenURI, which concatenating the base Uri and tokenId. So we can attach some off-chain information to our NFT.
ERC721Enumerable
Every minted token has its own unique uint256 tokenId. The most frequently, tokenId increase from zero, and it’s easy to find which token is older. But it is not a rule. The tokenId could be set by totally random mechanism. Therefor, this interface creates from all tokenIds list that simply increase from zero. Furthermore, except one list for all token, there is creating one list for each owner of tokens. This solution make the lives of user easier.
ERC721Full
The interface which is connected to ERC721, ERC721Metadata and ERC721Enumerable. The token created by this implement is a fully featured token.
IERC721Receiver
The interface that has to be implemented by contract that want to support safeTransfer function from ERC721. By using safeTransfer we minimize the risk the tokens will be locked in any smart contract forever. How does it work? If the target of safeTransfer is the contract, the function will call IERC721Receiver.onERC721Received and the called function has to return value equal bytes4(keccak256(“onERC721Received(address,address,uint256,bytes)”)). Otherwise, the transaction will be reverted. By using this solution, we won’t send tokens to the contract that is not created to handle ERC721.
Extensions
Except the main interfaces, the OpenZeppelin library gives us access to additional feature contract, that extend vanilla ERC721.
ERC721Burnable
The name of this extension is the clue, what it makes — burning the tokens. To be more precise, if we implement this extension, we will be able to irreversible destroy a specific token. The function to that is public and called burn. The only requirement to use it is msg.sender has to be the owner of token that he want to burn, or he has to be approved to this contract.
ERC721Consecutive
This extension allows to mint the large batches of token, but only during contract construction. By default, the upper limit of amount of batch is 5000 of tokens. When the batch is minted, the address of the account that will possess these tokens is not checked by the aspect of the IERC721Receiver implementation. Except that, this extension change one more thing — in the constructor we are not able to use traditional function mint, to create single token. This function we could use only when the constructor function is totally executed.
ERC721Pausable
This extension implement to the standard ERC721 contract the emergence stop mechanism, that could be fired by authorized address. It’s made by adding two new modifiers: whenNotPaused, whenPaused and by modifying the _beforTokenTransfer function from ERC721. This modifying pause the work of the _transfer, _mint and _burn.
This extension is useful in the scenario when we would like to stop all transfer of tokens during the evaluation process or when will be found a critical bug in the code. It’s just an emergence big red button, that pause working everything.
ERC721Royalty
Implementation of ERC2981 (NFT Royalty Standard). When NFT will be sale, then with every sale the creator gets a percentage of the sale price — this percentage is mentioned royalty. Unfortuantelly, every marketplace had their own system of royalty, therefor when the NFT was sold on the different marketplace, the creator didn’t get money. To standardize this aspect of NFT it was created ERC2981. This ERC specifies a way to signal the royalty information. But it’s only standard how to save this information, so it doesn’t enforce marketplace to payment. As a result, there is expectation that marketplaces will voluntarily pay royalties together with sales. For this moment, this extension is not very popular, and frequently the marketplaces don’t want to pay royalties.
ERC721URIStorage
As a said in the ERC721Metadata paragraph, we could add the string variable to the specific token. But this string is always the concatenating of the base URI and tokenId. This solution is gas efficient, because the URI of each token doesn’t have to be storage on-chain. But the problem is when the URI we would like to add is not connected with the tokenId or when different tokens need different base URI. To solve this problem, we could use this extension. It allows us to storage specific URI on-chain.
ERC721Votes
The extension thanks that we could use ERC721 to vote and create one of the element of the own governance system. One token is equal to 1 vote unit. This extension support voting and delegation of somebody to that. The important aspect of this extension is the token does not count as a vote until they are delegated, because the vote must be tracked. It’s a very popular restriction, which we could find e.g. in the ERC20Votes extension.
Additional mostly used interface
A lot of smart contracts I mentioned in this post use one contract — ERC165. Therefor, I think we should possess some information, about it, even if it is not the ERC721 extension. During my research I found a great post about ERC165, and I’m sure I won’t explain it better, so here is the link. I think it’s really worth to read it.
I hope you find this post useful. If you have any idea, how could I make my posts better, let my know. I am always ready to learn. You can connect with me on LinkedIn and Telegram.
If you would like to talk with me about this or any other topic I wrote, feel free. I’m open to conversation.
Happy learning!
New to trading? Try crypto trading bots or copy trading
