The ERC-721 standard has been around for a while now. Originally made popular by blockchain games, it's more and more used for other applications like Defi.

But what exactly is it?

A non-fungible token (NFT) is a uniquely identifying token. The word non-fungible implies you cannot just replace one NFT with another one. Every NFT is unique and different. In contrast to any fungible token like Bitcoin or ERC-20 where it doesn't matter which specific coin/token you receive, they all have the same value.

On Ethereum Cryptokitties helped to make this into the now popular 721 standard.

Let's explore the exact definition of the standard, all features and functions that are part of it.

At the core we have a mapping from uint256 => address. This is the reverse of a fungible token (e.g. ERC-20) mapping which is from address => uint256.

Why this reverse mapping?

In the fungible tokens we map from owner to balance. While in 721 we actually also do this in a second mapping (see balanceOf below), we more importantly need a way to uniquely identify tokens. By mapping from uint256 to address, we can give every minted token an id and map this id to exactly one owner. When creating a new NFT token, you create a new id (most commonly you just start at id 1 and count + 1 any following id) and set  the owner as ownerMapping[id] = receiverAddress.

Let's look at the actual 721 functions:

Returns the owner of the NFT token with the given id. In the 721 implementation we would just return ownerMapping[id] here.

Returns the balance of an owner, meaning the total amount of how many NFT tokens this address owns. In our implementation we will need to keep track of this when minting or transferring an NFT.

The transfer function comes in three forms. This one here is probably the most commonly used one. It will transfer the token with the given id to the receiving address. It will only work if the from address is the owner or approved (see below for approvals) and if the receiver is either not a smart contract or a smart contract that implements the 721 receiver interface (see below for ERC-165 and how to receive tokens). Otherwise the call will revert.

The other two variants for the transfer functions are simply one with an additional bytes data field to pass to the receiver hook and another non-safe transfer function that doesn't invoke the transfer hook.

The approval functions allow someone to approve another address for either one specific token or all tokens. Think of the approve for all functions as something where you would approve a trusted smart contract, so it cannot just steal all your tokens. Once you approve another address, it has full transfer control over it.

The metadata extension is optional for ERC-721 smart contracts. It includes a name and symbol just like they exist in many other token standards including ERC-20. Further a tokenURI can be defined for a token. Each unique token should have its own URI.

This tokenURI links to a metadata file. In the case of a game, the file could just be hosted on the servers of the game provider. In the spirit of decentralization, in many cases IPFS is used to store this file. Just make sure to use IPFS pinning not to loose the file. The metadata file has a defined name, description and image. It might look like this:

Another additional optional interface is the enumeration. It contains functions for counting and receiving tokens by the index.

With the totalSupply function you can determine how many NFT's in total exist currently, excluding the burnt ones of course. The other two functions will return the n'th token from the list of all tokens (tokenByIndex) or from the list of the tokens of that owner (tokenOfOwnerByIndex).

You might have noticed, if you never burn tokens and count token ids from 1 incrementally, the first two functions would just reflect the token ids.

If you don't know what EIP-165 is yet, see my tutorial here. In short it's a way for smart contracts to define what interfaces they support. So for example, does the smart contract support receiving ERC-721 tokens? If it does, the respective supportsInterface function must exist and return true for that contract.

In the ERC-721 a smart contract receiver must implement the onERC721Received function. You could use the onERC721Received function to implement some further receiving logic or just confirm the receiver supports the 721. But be aware that in the case of the non-safe transfer function, the hook is not called! In the hook you always need to return the magic value as confirmation.

Now let's see how you would implement a 721 token contract. We will be using the Openzeppelin contracts to help us.

This is a basic NFT example contract which allows the owner to mint new tokens. The syntax for the imports assumes using Remix, adjust it in case you installed the Openzeppelin contracts via npm.

Consider using some other minting mechanism depending on your use case. The _setTokenURI is of course optional.

You can also choose to use the Preset available here. A simple contract MyContract is ERC721PresetMinterPauserAutoId will be all you need to get an NFT contract that is preset to have

• minting, pausing and admin roles using the Openzeppelin Access Control mechanism
• enabled pause and unpause functionality

I highly recommend checking out the Openzeppelin 721 contracts and documentation for further details.

• Documentation
• ERC-721 implementation
• ERC721PresetMinterPauserAutoId

As mentioned before, if you use the safeTransferFrom function to send an NFT to a smart contract, it will revert unless the contract specifically added support for receiving 721 tokens

 Let's see how you would add this kind of support:

The available ERC721Holder is implementing a basic onERC721Received function which returns the magic value to confirm the support for receiving 721 tokens. Make sure to actually implement a function that can handle the token accordingly.

Most commonly people use the standard for blockchain games like the original Cryptokitties. It's well suited for this case as you can easily have in-game items represented as NFT. The additional metadata file is particularly useful to add more in-game information to the NFT.

But the usage goes beyond just games, and we are seeing it come into existence more and more now. Take a look at Rarible to see many other use cases. Digital art seems to be a major driver for NFT's at this point. Domains can be purchased or utilities, e.g., something that gives you digital access rights. More marketplaces include OpenSea, SuperRare, and Axie Infinity.

I find those in the space of Defi very interesting. For example you can purchase certain insurances, e.g., using yinsure (from yearn). The NFT gives you the permission for the defined insurance and claims are handled and paid out by the decentralized governance.

We even considered using the 721 standard for our derivatives as tokenized positions at Injective Protocol, however we ultimately decided against it as it wasn't a perfect fit. In theory it would have been possible though and might be something to add later on if people show interest.

In general any uniquely identifying possession could be turned into an NFT. We will see much more use cases in the future.

As mentioned we will probably see much more use cases for NFT's in the future on Ethereum and other blockchains. There is a new standard in the making called Interchain NFTs. The Interchain Foundation from the Cosmos universe is developing this standard for multiple networks dealing with 721 NFTs. It will be a useful standard for any blockchain once they have working bridges.

What are you looking forward to? Do you own any NFT's? Have you developed your own?

Let me know in the comments.