Fungible and Nonfungible Tokens

Not all tokens are created equal. One of the most important differentiators when creating tokens is whether they are fungible or nonfungible. Fungible tokens all have the same value and are interchangeable with one another, whereas nonfungible tokens represent something that is unique.

Items such as cars or houses are nonfungible—each is unique and not interchangeable with any other random car or house. CryptoKitties—digital cats represented on Ethereum as ERC-721 tokens—are another example of a nonfungible asset (we discuss this example more later in this chapter).

Smart contract development is a nascent area of computer science. It is highly recommended that a third-party auditor (like OpenZeppelin, which contributed background for this chapter) take a look at your code before you bring a token into the wild. Other well-known companies providing such services include Trail of Bits and Chainsecurity.

Ethereum offers many different token types that can be issued. Some popular ones include ERC-20, ERC-721, ERC-223, ERC-777, and ERC-1400. The variety enables developers to create different types of functional cryptocurrencies on top of the Ethereum blockchain.

Thanks to Ethereum’s nature, new types of cryptocurrencies on the Ethereum blockchain may provide real-world benefits. ERC-846, which provides for shared ownership of a token, is a good example of a real-world use case. 

Is a Token Necessary?

One existential question developers should ask when developing blockchain-based solutions is: Is a token necessary? Many tokenization/ICO projects have been developed with a token for fundraising, but with no clear motivation other than to have a cryptocurrency. Although ICOs are a good method of using crypto for fundraising, regulatory pressure is pushing developers to create tokens that have a greater function within projects.

As we’ve said, the main way to distribute tokens is via an ICO or similar type of offering. Another alternative is doing an airdrop. Intended to leverage network effects of already existing blockchains, airdrops are free or low-cost disbursements of cryptocurrencies to a large subset of users. The idea is to rapidly give a project a user base from its inception, baking in adoption of an already existing project/cryptocurrency. The largest case so far has been the Stellar Foundation’s $125 million airdrop of its XLM token via the Blockchain.info wallet.

Different Token Types

Different Ethereum tokens have different technical specifications, and they also use different nomenclature depending on how regulators around the world define them. It’s important for developers to understand the various terms being floated regarding how to define tokens:

Utility

Utility in the context of tokens means that a blockchain-based cryptocurrency must have some use outside of financial speculation. There are several longstanding projects attempting to do this in the blockchain world. One of the best-known is Filecoin, where tokens grant users access to space on a decentralized cloud storage platform.

Security

A security, as defined by the SEC, is an investment contract. Designed to provide a promise of a return, investment contracts are regulated devices used around the world for fundraising. For this reason, the tokens proposed in many ICOs could be considered securities. They are thus regulated in the jurisdiction of issuance. An example of a project that offers security tokens is bloXroute, a protocol that changes the way networking and routing work for blockchain. Owning a bloXroute token means entitlement to a share in the future payout that blockchains will be making to bloXroute to use its routing protocol.

A security token offering (STO) is an attempt to create an ICO that fits into a regulatory framework. As ICOs mimic some of the qualities of an equity IPO, regulators around the world are increasingly trying to understand how to protect investors from fraud, excessive risk, and theft. The SEC, for example, has published a framework for crypto-based security offerings. 

ERC-20

The most common ERC standard for Ethereum tokens is ERC-20. Every smart contract that is compliant with the ERC-20 standard will implement the methods shown in Table 5-1.

Every smart contract that is compliant with the ERC-20 standard will implement the two events shown in Table 5-2. Developers can build applications that listen for these events to be triggered—for example, a cryptocurrency wallet checking to see if any of its Ethereum addresses have received tokens.

The following is an example of a basic ERC-20 smart contract, Mastering_Blockchain_Token.sol:

pragma solidity ^0.4.21;

contract EIP20Interface {  
    /// total amount of tokens
    uint256 public totalSupply;
 
    /// @param _owner The address from which the balance will be retrieved
    /// @return The balance
    function balanceOf(address _owner) public view returns (uint256 balance);
 
    /// @notice send `_value` tokens to `_to` from `msg.sender`
    /// @param _to The address of the recipient
    /// @param _value The amount of tokens to be transferred
    /// @return Whether the transfer was successful or not
    function transfer(address _to, uint256 _value) public returns (bool success);
 
    /// @notice send `_value` tokens to `_to` from `_from` on the condition
    ///  it is approved by `_from`
    /// @param _from The address of the sender
    /// @param _to The address of the recipient
    /// @param _value The amount of tokens to be transferred
    /// @return Whether the transfer was successful or not
    function transferFrom(address _from, address _to, uint256 _value) public 
      returns (bool success);
 
    /// @notice `msg.sender` approves `_spender` to spend `_value` tokens
    /// @param _spender The address of the account able to transfer the tokens
    /// @param _value The amount of tokens to be approved for transfer
    /// @return Whether the approval was successful or not
    function approve(address _spender, uint256 _value) public 
      returns (bool success);
 
    /// @param _owner The address of the account owning tokens
    /// @param _spender The address of the account able to transfer the tokens
    /// @return Amount of remaining tokens allowed to be spent
    function allowance(address _owner, address _spender) public view 
      returns (uint256 remaining);
 
    // solhint-disable-next-line no-simple-event-func-name
    event Transfer(address indexed _from, address indexed _to, uint256 _value);
    event Approval(address indexed _owner, address indexed _spender, 
                   uint256 _value);
}
 
contract EIP20 is EIP20Interface {
 
    uint256 constant private MAX_UINT256 = 2**256 - 1;
    mapping (address => uint256) public balances;
    mapping (address => mapping (address => uint256)) public allowed;
    /*
    NOTE:
    The following variables are OPTIONAL vanities. One does not have to include
    them. They allow one to customize the token contract & in no way influence
    the core functionality. Some wallets/interfaces might not even bother to look
    at this information.
    */
    string public name;       // Token name: eg Mastering Blockchain Book
    uint8 public decimals;    // How many decimals to show. Standard is 18.
    string public symbol;     // An identifier: eg MBB
 
    function EIP20(
        uint256 _initialAmount,
        string _tokenName,
        uint8 _decimalUnits,
        string _tokenSymbol
    ) public {
        balances[msg.sender] = _initialAmount;  // Give creator initial tokens
        totalSupply = _initialAmount;           // Update total supply
        name = _tokenName;                      // Set name for display purposes
        decimals = _decimalUnits;   // Set number of decimals for display
        symbol = _tokenSymbol;      // Set symbol for display purposes
    }
 
    function transfer(address _to, uint256 _value) public returns (bool success) 
    {
        require(balances[msg.sender] >= _value);
        balances[msg.sender] -= _value;
        balances[_to] += _value;
        emit Transfer(msg.sender, _to, _value); 
        return true;
    }
 
    function transferFrom(address _from, address _to, uint256 _value) public 
      returns (bool success) {
        uint256 allowance = allowed[_from][msg.sender];
        require(balances[_from] >= _value && allowance >= _value);
        balances[_to] += _value;
        balances[_from] -= _value;
        if (allowance < MAX_UINT256) {
            allowed[_from][msg.sender] -= _value;
        }
        emit Transfer(_from, _to, _value); 
        return true;
    }
 
    function balanceOf(address _owner) public view returns (uint256 balance) {
        return balances[_owner];
    }
 
    function approve(address _spender, uint256 _value) public 
      returns (bool success) {
        allowed[msg.sender][_spender] = _value;
        emit Approval(msg.sender, _spender, _value); 
        return true;
    }
 
    function allowance(address _owner, address _spender) public view 
      returns (uint256 remaining) {
        return allowed[_owner][_spender];
    }
}

This token contract was published on the Ropsten testnet and has the following attributes:

• Token name: Mastering Blockchain Book

• Token symbol: MBB

• Token supply: 100 MBB

• Token decimal places: 18

To create your own custom token, you can simply copy and paste the preceding code and change these four values in the constructor function:

symbol

The symbol of your token.

name

The name of your token.

decimals

How many decimals your token can be divided into. The standard value for most tokens is 18.

totalSupply

How many tokens will be in existence. There is a lot of variation in supply among tokens; 1 billion is an easy round number that is common.

ERC-721 is a standard for nonfungible tokens. As mentioned earlier, with fungible tokens (like ERC-20 tokens), each token has the exact same attributes. With nonfungible tokens, each token can have different attributes and therefore is unique, which allows for extreme digital scarcity.

Before blockchain, most virtual items could easily be copied. Connecting a virtual good or a real-world item to an ERC-721 token is a way to create a digitally scarce item that cannot be copied or tampered with.

The most famous example of this in the blockchain world is CryptoKitties, virtual cats that are connected to ERC-721 tokens on the Ethereum blockchain. Figure 5-1 shows CryptoKitty #1270015.

Figure 5-1. The unique attributes of the CryptoKitty with the unique ID 1270015

Instead of reading the attribute information about CryptoKitty #1270015 from a centralized database, the information is pulled from the CryptoKitty ERC-721 smart contract. Go to function #32 and enter the CryptoKitty ID, which is 1270015. From there it is possible to see the unique attributes for this CryptoKitty stored on the Ethereum blockchain, as shown in Figure 5-2.

Figure 5-2. Calling the read function getKitty from the main CryptoKitties smart contract responds with data stored in Ethereum about the specific kitty ID 1270015

ERC-777

This proposed standard is for the next generation of fungible (ERC-20) tokens. It includes some improvements to the ERC-20 standard, the most important of which is in the way tokens are transferred.

There are two ways that users can move ERC-20 tokens from one address to another:

Push transaction

Calling the function transfer(address _to, uint256 _value) is a push transaction, where the sender initiates the transfer of tokens.

Pull transaction

The combination of the functions approve(address _spender, uint256 _value) and transferFrom(address _from, address _to, uint256 _value) is a pull transaction, where the sender gives permission to the receiver and then the receiver pulls the tokens out of the sender’s account.

If a person sends tokens to a smart contract using a push transaction, then the smart contract will receive the tokens. However, the smart contract will not receive a trigger telling it that it has received the tokens and instructing it to run some code.

This is the reason for a pull transaction—the smart contract receiving the tokens initiates the transaction, and it can recognize when the tokens are received and execute additional code to react to this event. The most common use case for a smart contract receiving and sending tokens is decentralized exchanges, IDEX being the most popular.

Pull transactions work for smart contracts receiving tokens, but their use has led to many tokens accidentally being lost. A common problem is if a user mistakenly sends tokens to a smart contract using a push transaction rather than via the correct pull method; those tokens will be burned and lost forever, because the smart contract will not recognize that it has received the tokens and therefore won’t know to send them to another address at a later time.

ERC-777 proposes to fix this problem by introducing the following improvements:

authorizeOperator(address operator) and revokeOperator(address operator)

Allow token holders to authorize smart contracts to transfer tokens on their behalf and revoke that permission, respectively. The contracts that are authorized are known as operators. This is a variation of the pull transaction combination in ERC-20, but instead of authorizing the operator each time you want to transfer tokens, you only need to authorize the operator once. Then, for each additional transfer, the operator can transfer the tokens on your behalf.

tokensReceived and tokensToSend hooks

The contract receiving the tokens can include a function called tokensReceived. In that function, the receiving contract can identify which ERC-777 tokens the contract would like to accept and which it would like to reject (using revert). If an ERC-777 token is received but identified as to be rejected, the token transfer will not complete. It’s like receiving a letter in the mail and sending it back. Similarly, a contract that is requesting a token transfer can receive the tokensToSend hook, and when that hook is called has the option to revert the transaction. It’s less likely that this will happen, because this is the contract that initiated the transfer of tokens—it’s like going to the post office to send a letter, but then changing your mind as you are about to hand it over.

send(address to, uint256 amount, bytes data)

The push transaction includes a data field that not only allows the sender to send tokens to a contract, but also can contain specialized logic that triggers a function in the receiving contract. This is similar to how Ethereum transactions are executed.

This standard was designed to track virtual goods in games. For example, the default weapon in a shooting game might be a pistol, but it is possible to purchase the triple-barreled rocket-launching weapon that kills one hundred enemies in one shot.

Like the ERC-777 token standard, this standard includes the concept of an operator, an address that has the authority to move your tokens on your behalf.

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

function safeBatchTransferFrom(address _from, address _to, uint256[] calldata _ids, 
      uint256[] calldata _values, bytes calldata _data) external;

At time of this writing, about 35 games have adopted this standard, and about 100,000 people hold ERC-1155 virtual goods.