Before you go, check out these stories!

0
Hackernoon logoERC721 Token Standard & The Fungibility of Assets - A Developer’s Perspective by@zaryab2000

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

Author profile picture

@zaryab2000MD Zaryab Afser

BLOCKCHAIN DEVELOPER |with a Vision to DECENTRALIZE the WEB

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 (unless the manager inside is corrupt ) but the ticket does.

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(from, to, tokenId), transferFrom(from, to, tokenId),safeTransferFrom(from, to, tokenId, data)
approve(to, tokenId)getApproved(tokenId), setApprovalForAll(operator, _approved), isApprovedForAll(owner, operator)

Important Events in ERC721:

Transfer
Approval
ApproveForAll

In-Depth Analysis of ERC721 Functions and Events

ERC721 Interface

pragma solidity ^0.6.2;

import "../../introspection/IERC165.sol";


interface IERC721 is IERC165 {

    event Transfer(address indexed from, 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);

    
    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);

Function Parameter:

_tokenId -the unique ID assigned for each NFT.

What it does: Simply looks for the owner of a particular NFT.

What it returns: Returns the address of the owner who owns the NFT.

Throws an Error: If the

tokenId
passed as parameter doesn’t have any owner, then such NFTs are invalid.

safeTransferFrom

Syntax:
function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;

Function Parameter:

_from -the current owner of the NFT
_to -address of the new owner
_tokenId -unique ID of the NFT to be transferred.
_data -Additional Data.

What it does: Its main task is to transfer the ownership from one address to another.

Throws an Error: This function can throw errors in 5 crucial conditions. Its really imperative to understand each of them.

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 _to address is a contract address(code size>0), then it calls an

onERC721Received
function on
_to
address.

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:

from -the current owner of the NFT
to -address of the new owner
tokenId -unique ID of the NFT to be transferred.

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

safeTransferFrom
function.

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 for a particular NFT
tokenId -unique ID of the NFT to approve.

What it does: This function is used to change or reaffirm the approved address for an NFT.

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:

_operator
-the address of the operator who will be approved for control over the NFTs

_approved
-True if the provided operator is to be approved or False if the approval is to be revoked.

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:

tokenId
-unique ID of the NFT to approve.

What it does: This is a simple function that provides us with the approved address for a single NFT.

What it returns: Returns the approved address for a particular NFT. It returns zero address if there is not approved address for an NFT.

Throws an Error: If the _tokenId is not a valid NFT.

isApprovedForAll

Syntax: function isApprovedForAll(address _owner, address _operator) external view returns (bool);

Function Parameter:

_owner
-the Owner of the NFT

_operator
-The address of the third party that acts on behalf of the owner.

What it does: This function provides us with the information that whether or not an operator is authorized for another address.

What it returns: Returns True if _operator is an approved address for the owner, else returns False.

Important Events in ERC721:

Transfer Event:

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

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!

Tags

The Noonification banner

Subscribe to get your daily round-up of top tech stories!