Part of this series:
- Fungible and Non-Fungible Tokens in Blockchains
- Fungible Tokens in Ethereum: ERC-20
- Non-Fungible Tokens in Ethereum: ERC-721
If 2018 was the year of ICOs, 2021 seems to be the year of Non-Fungible Tokens, or NFTs. What are they, and how can we use them?
I have answered the first question in the first post of this series, where I describe analogies to Fungible- and Non-fungible tokens. In this post, I want to focus on how they are created in Ethereum.
The ERC-721 Standard
Fungible Tokens were created on the Ethereum platform and eventually evolved into the amazing DeFi landscape we have today. Likewise, Non-Fungible Tokens appeared and evolved on Ethereum, and have strong technical support there.
The standard underpinning NFTs is known as ERC-721, and as the number suggests, it took a considerable span of time (2 to 3 years) to jump from the idea of Fungible to Non-Fungible tokens.
The first real-world demonstration of the power of Non-Fungible tokens was CryptoKitties, which surprised and for some time totally clogged the Ethereum network, with a craze of collecting computer-generated pieces of art: pictures of cats that could evolve in genetically-inspired fashion.
Although people have been collecting things in the real world for a long time, (eg coins, football player cards, trading card games), CryptoKitties demonstrated that people could be equally obsessed by collecting virtual goods, without physical existence. NFTs had found a market.
Key Aspects of Non-Fungible Tokens
The key aspect of Non-Fungible tokens is in their name. Tokens are non-fungible, which means each one of them is unique and irreplaceable. Each token can be owned, and although there may be other similar or even related tokens, they all are essentially different and may have different values.
This paragraph points to the main 3 characteristics of a Non-Fungible Token:
- Identity
- Owner
- Value
When we talk about collectible items, like rare out-of-print comics, vintage toys or similar niche products, we find that often each of these was originally an undistinguished thing that you could buy in a store among hundreds of others just like it. (for example, a Star Wars miniature from the 80s). At that point, it looks like there is nothing special about such an item.
It is the passage of time that gives it value. Many of those things get lost, thrown into the rubbish, destroyed by careless hands, or kept in poor conditions. The ones that survive well preserved are the ones that become valuable. Even if there are 10 survivors out of an initial run of 100,000 of these items, for example, all of them will have their individual history, a unique condition, and therefore a different value.
Each develops its unique identity.
An Overview of ERC-721
The avowed goal of ERC-721 is to represent Non-Fungible Tokens that can be tracked and transferred, as well as consigned to third parties. This standard is based on ERC-20, and for that reason keeps some things for compatibility. Coming a few years later, it also introduces some new ideas.
Just like ERC-20, ERC-721 tokens are organized by smart contracts. Each ERC-721 contract manages and tracks a collection of tokens. This division naturally organizes tokens in different groups, or namespaces. For example, all Crypto-kitties are maintained by the same ERC-721 contract, but there are many other types of NFT tokens.
We can think of a single ERC-721 contract as defining a Token Type, and all tokens of that type are managed and contained by that contract. This is similar to how all “coins” of an ERC-20 token, together with their owners and transfers, are accounted for in their respective single ERC-20 contract.
Unlike Fungible Tokens, Non-fungible tokens have a unique identity inside their contract, but different contracts could use the same identifiers. Therefore, the absolutely unique identifier of a token is their contract address plus their token id.
As expected, owners of tokens must be Ethereum addresses.
ERC-721 Mandatory Functionality
- Token Id: a unique identifier for each token within this contract, represented by 32 bytes (commonly a hexadecimal string with 64 characters). It must remain immutable for the life of the token.
- Token’s owner: which address owns this token.
- Account’s balance: how many tokens each owner has. Unlike in ERC-20, where a token can be thought of as 1 base unit, this balance has nothing to do with value. Each token of an owner can have wildly different values. This field is only a simple count.
- Token’s controller: a token’s owner can specify a single other address to control that token.
- Account’s operator: an account holder can specify one or more Operators for all tokens held by that account.
ERC-721 Allowed Operations
- Transfer token: Gives ownership of the token to another account.
- Approve address: Sets or removes the NFT Controller.
- Set Approval for All: Defines or removes an Operator address.
ERC-721 Optional Functionality
ERC-721 contracts can provide some standardized, but optional, information:
- Name: a description of the token type defined by this contract.
- Symbol: a short name for all the NFTs in this contract.
- Token URI: a function that returns a Uniform Resource Identifier for each token. Unlike the token Id, this can vary with time.
- Total Supply: the number of tokens managed by this contract
- Token by Index: a function to retrieve the token Id of the nth token in the collection, where n is the argument passed to the function. This provides the ability to enumerate all the tokens even without knowing their individual token Ids.
- Token of Owner by Index: a function to retrieve the token Id of the nth token owned by a specific address. The required index n and the owner’s address are the arguments for this function.
Using ERC-721 Tokens
Metadata
NFTs can be many things, not just a unit of account like a Fungible Token. Therefore, the huge variety of what they can be and do cannot be represented on-chain.
On the one hand, blockchains are not efficient enough to store and execute all the needed information. But most importantly, it isn’t even possible to predict all the use cases in a generic enough way.
This information is kept off-chain in some external location, and the reference to this is stored in the token’s URI. This could be a cloud location, IPFS or even a traditional server. It doesn’t matter, as long as it is publicly accessible and the URI uniquely identifies it.
The data itself is commonly described in a JSON object, possibly with further links to non-textual properties of the token (images, videos, or even credentials to access some interactive experience). The token’s metadata can vary with time, for example, to track its history, but its identity will remain the same.
Operators and Controllers
The ERC-721 standard allows the specification of entities, other than their owner, that can act on tokens. These allow the Owner to delegate the ability to transfer them to an external entity that effectively becomes a second owner. Practical use cases include: entrusting the Token to a broker, storing the token in a wallet, letting an attorney or auctioneer sell the token, for example, to pay a debt.
These entities come in two categories:
- Controllers: these can transfer a single token, and receive that permission from the token’s owner. A Controller is also known as the approved address for a token.
- Operators: these represent another account, and can move all of the tokens owned by that account.
At any one time, a given Token can have only one Controller, but an account can have multiple operators. The token’s controller is reset once it is transferred, since only the new owner should be able to grant secondary ownership to its tokens.
Safe Transfers and Receiver Contracts
ERC-721 enables two types of transfers: normal and safe.
Normal transfers can give ownership of a token to a new account, and can be called by the token’s owner, a token’s controller, or an operator.
Safe transfers additionally verify that the receiver of the token (if it is a contract) is able to receive and own NFTs. If this is not the case, sending a token to such an address may render it irredeemably lost, as the new owner will not be able to transfer it back again.
To enable this, the standard requires that contracts that may receive ERC-721 tokens must implement the interface ERC721TokenReceiver. This defines a single function onERC721Received that must return a well-known value (aka “magic constant”) to confirm this contract is aware of the ERC-721 standard.
A Safe Transfer always queries the result of this function and will be cancelled if the value it receives is not the magic constant. This prevents sending a token by mistake to a contract that cannot handle it and might lose the token forever.
This mechanism also allows the contracts to implement additional logic, beyond that mandated by the standard. For example, the contract could have a switch and reject transfers while it is disabled; or it could enforce payments from the receiver, enabling a transfer’s expenses to be shared by both parties. It is another way of enriching the user experience around NFTs.
Conclusion
Despite the simplicity of the idea of NFTs, there is surprising complexity and variability associated with their use. The ERC-721 standard is a first step in taming this and bringing a uniform way to use them on the Ethereum blockchain.
The seeds were planted in 2018, but now in 2021, we are seeing them sprout and flourish in a startling way. It is testament to the usefulness of this standard and the foresight of its creators.
I hope this article has helped you understand more how to use these tokens, but there are more token-related standards in Ethereum. Stay tuned for more posts as I cover the most important ones.
Farewell, and don’t forget to like and share if you’ve enjoyed this post.