To begin with, What exactly are TOKENS ? In simpler terms, a token can be seen as a representative of value within a particular platform that has the capability to be traded for services, currency, time, or even shares in a company, etc. The entire concept of tokens in the Blockchain space is mostly inspired by the use of tokens in our real lives. Imagine a MOVIE HALL The best way to understand a token is to take a real-world example like a Movie Hall. Before you enter a movie hall you need to exchange your to receive tickets. Those tickets can actually be seen as tokens. Inside the Movie Hall, the real money doesn’t really hold any value ( )  but the ticket does. unless the manager inside is corrupt These tickets now have enough value to be exchanged for a seat inside the hall. In fact, almost everything or services you might want inside this hall, completely depends on the kind of tickets you have. The more tickets you have, more the quantity of seats you have access to. Also the costlier your ticket is, the better the quality of your seats. Tickets are TOKENS and HALL is DAPP Now simply swap the entire idea of the Movie Hall with a Decentralized Application(Dapp) and the movie tickets with the crypto tokens allowed in that DAPP. That’s it. You just got the gist of what Tokens actually are. Hence, it can undoubtedly be said that Tokens play an imperative role as they let you access certain features or services provided by the DAPP and act as a medium of exchange within that particular platform. The Concept of FUNGIBILITY Before understanding even the basic idea of ERC721, it's literally imperative for us to understand the 2 most crucial kinds of TOKENS. Fungible tokens This represents the simple type of tokens that we are quite familiar within our everyday life. A Fungible token may be defined as those that are equivalent as well as easily interchangeable. For example, A 100 Rupee note can be exchanged for any other 100 Rupee note since all of those are the same and hold the same amount of value. There is no uniqueness in Fungible assets as they are already available in a large quantity. A 100 Rupee that you have is quite similar to the note I have in every aspect, i.e., size, shape, color as well as value. Therefore there isn’t any uniqueness in Fungible assets. Moreover, these fungible assets are divisible into smaller units and it doesn’t really matter since the value of all the smaller units together still remains the same. For example, a 100 Rupee note can be divided into two 50 Rupee notes or even into ten 10 Rupee notes. It doesn’t really matter since all these smaller notes together bring the same value as the 100 Rupee note. However, the same is not true for Non Fungible Tokens. 2. Non Fungible Tokens Unlike Fungible assets, Non Fungible Tokens(NFTs) are not at all interchangeable and equivalent. NFTs can simply be understood as all those assets whose value exists because of its uniqueness, usefulness as well as rarity. NFTs can simply be understood as all those assets whose value exists because of its uniqueness, usefulness as well as rarity. The best example of Non Fungible assets are paintings or unique artworks. Each Painting is one of a kind and is unique in its own way. Now, these Paintings come under the category of Non Fungible assets because all are different, rare, and most importantly unique. This means unlike  Fungible tokens, NFTs can’t be exchanged simply. Moreover, they aren’t divisible like Fungible assets because once divided they lose their real value. Therefore, while Fungible assets deals with the quantity(how many)of the tokens you own, Non Fungible assets is more about the quality(which ones) of tokens you possess. Enters ERC721 In late 2017, Dieter Shirley introduced an Ethereum Improvement Proposal called ERC721. Why ERC721 and not ERC20? The Ethereum community already had an effective standard called ERC20 tokens, to represent and track fungible tokens on the blockchain. However, it was beyond the capability of ERC20 to track NFTs because unlike fungible tokens, each NFT is distinct. ERC721, although being inspired by the ERC20 protocol, provides a modified and effective standard interface for non-fungible tokens. While ERC721 tokens can be used in any exchange, their value however is quite not similar and largely depends upon their uniqueness and rareness. Moreover, unlike ERC20 tokens, the value of non-fungible tokens in ERC721 token standard largely depends upon their uniqueness as well as rareness. Diving Deep into ERC721 Contract The fact that makes ERC721 different from ERC20 can actually be found within its smart contract. Although ERC721 follows the basic procedure of ERC20, certain functions within ERC721 allow us to track non-fungible assets as well. Let’s dive in and understand more about the ERC721 contract and those functions that make it one of a kind. Imperative Functions in ERC721 balanceOf(owner), ownerOf(tokenId)
safeTransferFrom( , to, tokenId), transferFrom( , to, tokenId),safeTransferFrom( , to, tokenId, data)
approve(to, tokenId)getApproved(tokenId), setApprovalForAll(operator, _approved), isApprovedForAll(owner, operator) from from from Important Events in ERC721: Transfer
Approval
ApproveForAll In-Depth Analysis of ERC721 Functions and Events ERC721 Interface pragma solidity ^ ; ;


interface IERC721 is IERC165 {

    event Transfer(address indexed , address indexed to, uint256 indexed tokenId);


    event Approval(address indexed owner, address indexed approved, uint256 indexed tokenId);


    event ApprovalForAll(address indexed owner, address indexed operator, bool approved); 0.6 .2 import "../../introspection/IERC165.sol" from ( ) ( ); ( ) ( ); ( ) ; ( ) ; ( ) ; ( ) ( ); ( ) ; ( ) ( ); ( ) ;
} function balanceOf address owner external view returns uint256 balance function ownerOf uint256 tokenId external view returns address owner function safeTransferFrom address from, address to, uint256 tokenId external function transferFrom address from, address to, uint256 tokenId external function approve address to, uint256 tokenId external function getApproved uint256 tokenId external view returns address operator function setApprovalForAll address operator, bool _approved external function isApprovedForAll address owner, address operator external view returns bool function safeTransferFrom address from, address to, uint256 tokenId, bytes calldata data external ownerOf Syntax: ( ) ( ); function ownerOf uint256 _tokenId external view returns address r: Function Paramete _tokenId -the unique ID assigned for each NFT. Simply looks for the owner of a particular NFT. What it does: Returns the address of the owner who owns the NFT. What it returns: If the passed as parameter doesn’t have any owner, then such NFTs are invalid. Throws an Error: tokenId safeTransferFrom Syntax: ( ) ; function safeTransferFrom address _from, address _to, uint256 _tokenId, bytes data external payable Function Parameter: _from -the current owner the NFT
_to -address the owner
_tokenId -unique ID the NFT to be transferred.
_data -Additional Data. of of new of Its main task is to transfer the ownership from one address to another. What it does: This function can throw errors in 5 crucial conditions. Its really imperative to understand each of them. Throws an Error: a. It throws an error if the msg.sender is not the current owner, an authorized operator or an approved address for the NFT to be transferred. b. If the _from parameter doesn’t contain the address of the current owner, then an error will be thrown. c. If the _to parameter is a zero address(invalid address). d. If the _tokenId is not a valid NFT. Note: This function can throw an error even after the transfer is complete. e. One of the most imperative part that must be understood is that as soon as the transfer is complete, this function checks if the _to address passed in the parameter is an Externally Owned Account(owned by a person) or a Contract Address(owned by a contract). If the _ address is a contract address(code size>0), then it calls an function on address. to onERC721Received _to It then checks if the return value is equal to: . `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))` If the return value is not the same, then it throws an error. transferFrom Syntax: ( ) ; function transferFrom address _from, address _to, uint256 _tokenId external payable Function Parameter: -the current owner the NFT
to -address the owner
tokenId -unique ID the NFT to be transferred. from of of new of What it does: It also transfers the ownership of an NFT from one address to another. However, there is a crucial difference in this function and the function. safeTransferFrom In this function, the Caller is the one responsible to confirm that the receiver of the NFT is capable of receiving NFTs. Otherwise the NFTs may be lost as soon as the execution of this function is completed. Throws an Error: a. It throws an error if the msg.sender is not the current owner, an authorized operator or an approved address for the NFT to be transferred. b. If the _from parameter doesn’t contain the address of the current owner, then an error will be thrown. c. If the _to parameter is a zero address(invalid address). d. If the _tokenId is not a valid NFT. approve Syntax: ( ) ; function approve address _approved, uint256 _tokenId external payable Function Parameter: _approved -the New Approved address a particular NFT
tokenId -unique ID the NFT to approve. for of This function is used to change or reaffirm the approved address for an NFT. What it does: Throws an Error: a. It throws an error if the msg.sender is not the current owner, an authorized operator or an approved address for the NFT to be transferred. b. If the _tokenId is not a valid NFT. setApprovalForAll Syntax: ( ) ; function setApprovalForAll address _operator, bool _approved external Function Parameter: -the address of the operator who will be approved for control over the NFTs _operator -True if the provided operator is to be approved or False if the approval is to be revoked. _approved What it does: This is one of the most imperative functions as it allows the owner of the NFT to allow or prevent certain third parties, i.e., operators to manage all of his/her NFTs. Throws an Error: a. It throws an error if the msg.sender is not the current owner, an authorized operator or an approved address for the NFT to be transferred. getApproved Syntax: ( ) ( ); function getApproved uint256 _tokenId external view returns address Function Parameter: -unique ID of the NFT to approve. tokenId This is a simple function that provides us with the approved address for a single NFT. What it does: Returns the approved address for a particular NFT. It returns zero address if there is not approved address for an NFT. What it returns: If the _ is not a valid NFT. Throws an Error: tokenId isApprovedForAll Syntax: ( ) ( ); function isApprovedForAll address _owner, address _operator external view returns bool Function Parameter: -the Owner of the NFT _owner -The address of the third party that acts on behalf of the owner. _operator This function provides us with the information that whether or not an operator is authorized for another address. What it does: Returns True if _operator is an approved address for the owner, else returns False. What it returns: Important Events in ERC721: Transfer Event: event Transfer(address indexed , address indexed to, uint256 indexed tokenId); from This event is emitted whenever the ownership of any NFT is changed from one address to another. 2. Approval Event event Approval(address indexed owner, address indexed approved, uint256 indexed tokenId); Whenever an approved address for a particular NFT is converted or reaffirmed, the Approval Event is emitted. 3. ApprovalForAll Event event ApprovalForAll(address indexed owner, address indexed operator, bool approved); This event is fired only when a third party or an operator is allowed or prevented to use the NFTs of a particular user on behalf of the user. Once allowed, the operator can manage all the NFTs of the owner. Best Use Cases of Non-Fungible Tokens NFTs have a completely distinct set of properties that makes it quite different from the traditional fungible tokens. Therefore, before using NFTs or starting to develop your own NFTs, there  is a very strong need for you to understand the best ways a non fungible tokens can and should be used. Some of the most renowned applications of NFTs are as follows: 1. Gaming 2. Collectibles 3. Licensing NFTs in Gaming One of the most renowned use cases of NFTs in Gaming can undoubtedly be seen as Cryptokitties. In fact, this was one of the first best use cases of the NFTs that drew enormous attention towards NFTs and ERC721 token standard. With the use of NFTs, this game expanded its boundaries enormously and people have spent more than $6.5 million for these unique cryptokitties. NFTs in Licensing Software Licensing is yet another best use case of NFTs. It is widely believed that using NFTs in licensing can reduce not only reduce piracy but also allows people to earn profit by selling their licenses in the open market. Well, I guess now You are all set to get started with the ERC721 token standard and NFTs. Good Luck!

Dapp

ERC721 Token Standard & The Fungibility of Assets - A Developer’s Perspective

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Another Re-entrancy Attack - What's Stopping Us from Being a Better Smart Contract Developer?

8 Basic Blockchain Terms Every Beginner Needs to Know

Building A Stone-Age Blockchain

Revising The Basics of Blockchain Part 1: Introduction

Revising The Basics of Blockchain Part 2: Blockchain Consensus Mechanisms

Another Re-entrancy Attack - What's Stopping Us from Being a Better Smart Contract Developer?

8 Basic Blockchain Terms Every Beginner Needs to Know

Building A Stone-Age Blockchain

Revising The Basics of Blockchain Part 1: Introduction

Revising The Basics of Blockchain Part 2: Blockchain Consensus Mechanisms

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps