You are all familiar with ERC20 tokens as you probably own a couple, distributed by some kind of token sale. But did you know many more standards exist besides ERC20? Ethereum has a long history of developed standards.

To give you a better idea of what ERC means, it stands for “Ethereum Request for Comment”. This is a proposal submitted for discussion and suggestions to the actual standard. The number (like 20) refers to an issue number on code sharing platform Github. First, let’s take a look at the ERC20 standard.

ERC20 standard

What exactly is the ERC20 standard?

The advent of ERC20 tokens revolutionized the cryptocurrency market and opened the door to the plethora of ICO cryptocurrency projects the world witnessed during 2017. Introduced in 2015, the ERC20 code outlines a specific list of rules that a given Ethereum based token has to deploy, simplifying the process of programming the functions of tokens on Ethereum's blockchain. Basically, ERC20 tokens are special forms of smart contracts that utilize Ethereum's blockchain.

The most prominent examples of ERC20 tokens include Bancor, EOS, Tronix, BNB, VeChain, and Bankex.
Before the innovation of the ERC20 standard for Ethereum tokens, coders had to create specific implementation standards for developing a token and launching it on Ethereum's network. Nevertheless, the ERC20 token code have simplified the process of creation of tokens, thanks to a streamlined protocol and smart contract standards. The ERC20 code alleviated the complexity associated with implementation of token's smart contracts, which significantly reduced the possibility of breaking token's contracts.

As of April 2018, there are 66,468 ERC20 token contracts, thanks to the uniformity of token code provided by the ERC20 standard, which made it easy for cryptocurrency exchanges to list various tokens on their trading platforms. As such, the ERC20 standard has helped the crypto community overcome liquidity problems that could have associated such an enormous number of Ethereum based tokens.

ERC20 token functions:

ERC20 code outlines six specific functions for tokens, which are

1- Getting the total supply of tokens via the "totalSupply" function
2- Retrieving the token balance of another account associated with the "_owner" address via the " balanceOf(address _owner) constant returns (uint256 balance)" function.
3- Sending a specific amount of tokens "_value" to a given address via the " transfer(address _to, uint256 _value) returns (bool success)" function.
4- Sending a specific amount of tokens "_value" from one token (contract) address to another token (contract) address via the "transferFrom(address _from, address _to, uint256 _value) returns (bool success)" function.
5- Enabling a specific account to withdraw tokens from one's account repeatedly, while predefining the upper limit for the amount of tokens to be withdrawn with the "_value" parameter. This can be achieved via the "approve(address _spender, uint256 _value) returns (bool success)". The upper limit for withdrawal, i.e. the "_value" parameter, can be overwritten when the function is recalled.
6- Returning the residual amount of tokens, within the preset amount defined by the upper limit allowed to be spent by the "_spender" to withdraw from the account of the "_owner". This can be executed via the "allowance(address *_owner*, address *_spender*) constant returns (uint256 remaining)" function.

These six functions defined by the ERC20 code represent cornerstone functionality issues, which include how these tokens will be transferred between different accounts, and how users can retrieve data associated with a given ERC20 token. These group of functions are prescribed to ensure that Ethereum based tokens will function similarly within any part of Ethereum's platform. As such, all crypto wallets that are compliant with the ether coin will also support tokens based on the ERC20 standard.

Critical bug:

ERC20 is the first token standard of Ethereum. As is often the case with new code, it contains some bugs or logical mistakes. ERC20 assumes two ways of performing a token transaction. First of all, the transfer function lets you send tokens to someone’s address. If you want to deposit tokens to a smart contract, you should use the combination ‘approve + transferFrom’. You should authorize this contract to withdraw your tokens via the approve function. Then, you need to call a function of a contract that will handle your deposit and withdraw your tokens via the transferFrom function.

What if you deposit tokens by accident to a contract with the transfer function? The transaction will succeed but this transaction will not be recognized by the recipient contract. For example, if you send tokens to a decentralized exchange contract, then the exchange contract will receive your tokens but it will not credit this tokens to your exchange token balance. Moreover, if the decentralized exchange contract does not implement an emergency token extraction function, then it’s impossible to get your tokens back in any case, resulting in a permanent loss of the tokens. Due to this bug, the Ethereum ecosystem has lost millions of dollars already.

Why are we still using the ERC20 standard?

Reddit user u/Dexaran, creator of the ERC223 standard, is one of the first developers who notified the community about the aforementioned bug. We asked him why ERC20 is still so widely used, even when knowing about this critical bug. He gave the following reasons:

Because of criminal irresponsibility of token developers for their deeds.
Because Ethereum Foundation is still promoting the ERC20 token standard even when it is known to contains bugs. The same situation as it was with TheDAO previously. They need to say "Stop this now" but they will not.
Because the main reason for token development is fund grabbing, rather than product creation.
Because using a different standard will lead to higher network effects. This is not what we really need given that the Ethereum network already has scalability issues.

ERC223 standard

The ERC223 standard was proposed by u/Dexaran who helped creating this article. ERC223 is a token standard that allows token transfers to behave exactly as ether transactions. ERC223 utilizes event handling (considers a transaction an event) to prevent tokens from being lost in unhandled transactions. This improved standard resolves the ERC20 critical bug by making the transfer function throw an error on invalid transfers and canceling the transaction so no funds are lost. In short, ERC223 focuses on security.

Additions and problems

ERC223 adds an additional data parameter to the transfer function, to allow for more complex operations than just a token transfer.
Dexaran's main concern is that too many people can lose their tokens by sending them to contracts using the transfer function, not the approve and transferFrom methods as earlier discussed. His solution is to modify the transfer method to check whether the receiving address is a contract (i.e. contains data) or not. If it is a contract, then it assumes that there is a tokenFallback function to call it back. The main weakness is that if the tokenFallback does not exist, then the receiving contract's fallback function will be called and the sent tokens may still be lost.

ERC777 standard

ERC777 is a new fungible token standard that relies on ERC820 (Contract pseudo-introspection registry) and tries to solve ERC20's problems, such as lack of transaction handling mechanisms that led to the loss of millions of dollars from the Ethereum ecosystem. In short, ERC777 focuses on adoption by offering a wide range of transaction handling mechanisms.

Benefits

The main advantage of ERC777 is that it uses a new method of recognizing the contract interface. This standard assumes that there is a central registry of contracts on Ethereum's network (this is defined in ERC820). Everyone can invoke this registry to know if a certain address (it doesn't matter if this address is a contract or not) supports a certain set of functions i.e. `interface`.
One of the main problems of Ethereum is the inability to know what functions the contract implements. ERC820 is intended to solve this. ERC777 takes advantage of this approach, which is definitely a good idea.
On the other hand, you can create a token that will implement ERC20's default functions alongside with the new ERC777 functions without overrides (and optionally inherit ERC20's critical bug). This can guarantee a good network effect for this new token standard and faster adoption. As practice shows, the main goal of token developers is to raise money which assumes that they need to push their tokens to exchanges. It is easier for exchanges to support a token that implements legacy ERC20 functions (it doesn't matter if these functions contain bugs or not) without any research on newer functionalities of new token standards. The easier it is for exchanges to support tokens on a new standard, the more developers will use it. This boosts the adoption of ERC777, while ERC223 lacks this property.

What’s different?

This token standard defines a completely new set of functions i.e. `send` functions instead of `transfer` functions. `authoriseOperator` instead of `approve`. `tokensReceived` handler function instead of `tokenFallback` handler function.

Such an approach can guarantee that the functions of this standard will not cross and override with functions of any other token standard, thus it is possible to make a token that will be compatible with ERC777 and ERC820 standards simultaneously.
At last, ERC777 standardizes Mint and Burn functionality of tokens.

Points of failure and security concerns

ERC777 implements the `authoriseOperator`function which allows someone to manage tokens on your behalf. Dexaran explained to us that he thinks this method is deprecated and should not be used. In addition, authorizing someone to manage tokens on your behalf hurts the network's bandwidth and requires more gas. `authoriseOperator` already represents one transaction, and another transaction is required to perform the "authorized withdrawal". So, two transactions are required to perform a transfer which can be done with just one transaction.
Next, the ERC777 standard contains an optional flag to prevent stuck tokens by performing some checks about the ITokenRecipient interface, and to check if the address is whitelisted. As this standard is focused on security of a network that handles tokens that are worth millions of dollars, it’s not a good thing to make these checks optional.

Other standards

There are many other standards like ERC827 which combines some advantages of ERC223 with legacy ERC20 functions. The ERC664 standard focuses on the modularity of the token standard. This standard allows token contracts to be upgradeable, but it has inherited the ERC20 critical bug. Other standards include ERC721, ERC677, and ERC820, but they are less well-known.

Compatibility between standards

We asked Dexaran which standards are backward compatible. He told us we first should understand what ‘backward compatibility’ stands for: “Backward compatibility is a property of a system, product, or technology that allows for interoperability with an older legacy system, or with input designed for such a system.”

ERC20 & ERC223: ERC223 tokens are compatible with ERC20. Everything that is designed to properly work with ERC20 (like wallets) can work with ERC223 as well. The only exception here are contracts that are relying on approve + transferFrom token deposit patterns. However, it is possible to implement approve + transferFrom functions with ERC223 tokens, even if they are not included in the standard right now. As for wallets and any third party services that are not smart-contracts, they support ERC223 automatically because the input call data of ERC20 token is valid for ERC223.

ERC20 & ERC777: You can find the following statement in the ‘Backward Compatibility’ section of the ERC777 proposal: “This EIP does not introduce backward incompatibilities and is compatible with the older ERC-20 token standard.”

However, Dexaran told us the exact opposite and gave us this example: “Such wallets and services as MetaMask, Mist, and MyEtherWallet are working with ERC20 tokens. The input that is designed for the ERC20 token is a contract call that contains encoded parameters and a function signature. Function calls in the Ethereum Virtual Machine are specified by the first four bytes of data sent with a transaction. These 4-byte signatures are defined as the first four bytes of the hash of the canonical representation of the function signature. This means that `transfer(address, uint256)` and `send(address, uint256)` functions will have different signatures. As a result, the input designed for the ERC20 token will not be valid for the ERC777 token.” As we use our definition of backward compatibility, ERC777 is not compatible with the ERC20 token standard.

When to use which standard

ERC20: Reddit user u/Dexaran gave us this sarcastic advice, “When you want your investors to lose money because of bugs.”

ERC223: This token standard is also usable alongside with ERC777. ERC777 has some elegant features that ERC223 lacks, but the logic of ERC223 is straightforward compared to ERC777 which can guarantee that it cointain much less error-prone code. Moreover, ERC223 is not relying on any central service which means that your ERC223 token will only depend on your own implementation. As we have mentioned earlier, ERC223 aims at security improvements, but this rendered ERC223 tokens non-compliant with the ERC20 standards.

ERC777: This token standard is already usable. On the other hand, ERC777 has some security concerns as mentioned above. They also rely on central contract registry which is a security concern as well. A central registry can make developer's life easier but it also acts as a central point of failure exactly as it was with Parity Multisig. All the Parity Multisigs relied on a central code library. It happened that there was a bug in the library and it was exploited. As a result, all the Parity Multisigs crashed. In addition, ERC777 defines a new set of functions. This is an attempt to allow token developers to make their tokens compatible with both ERC20 and ERC777 standards simultaneously for the sake of adoption. This means that a developer can inherit a bug of ERC20 in ERC777, but it allows a developer to use more transaction handling events.

In general: All tokens have a similar use case - ICO. I would say that ERC223 and ERC777 are trying to solve one problem of ERC20 in different ways. ERC223 is already taking its niche in Ethereum Classic instead of the ERC20.

This article was created with the help of Dexaran, the ERC223 developer. Some of Paul Edge's comments on Ethereum's token standards were used too.

International Conference on Mainstreaming Block Chain Implementation (ICOMBI) 2020

Start date

End date

Location