









Are you an Ethereum developer working on a crypto project? You are likely developing the new token using the ERC20 standard, however, you need to know the improvement efforts. This will help you make the right decision about which ERC token standard to use, hence I will explain ERC777 vs ERC223 vs ERC20 comparison in this article.

I will start the comparison with an explanation of ERC 20, and I will subsequently explain the drawbacks of it. Then I will explain the improvement efforts that the Ethereum community undertook, via ERC 777 and ERC 223.

Comparison between ERC20 vs ERC223 vs ERC777

What is ERC 20?

Before I compare ERC 20 vs ERC 223 vs ERC 777, I need to explain what is an ERC, and what does ERC20 represent. Ethereum developers often submit ‘Ethreum Improvement Proposals’ (EIPs). The Ethereum community reviews EIPs, make comments, which may trigger some rework.

After the Ethereum community accepts an EIP, it becomes a standard, and we then called it an ‘Ethereum Request for Comments’ (ERC). ERC 20 is one such standard for Ethreum tokens.

ERC 20 is the most famous Ethereum token standard and almost all ICOs that used the Ethereum platform have used it. Developers use it by default to create new tokens, while wallets and exchanges accept ERC 20 tokens easily.

Before ERC 20, Ethereum developers had to specifically set rules that their token will follow, and this approach lacked standardization. Now with ERC20, Ethereum developers know that they will just have to use ERC 20 standard. This standardization played a big part in fueling the ICO craze we saw since 2017.

Read more about the ERC 20 standard in “Beginner’s Guide: What is ERC20?“.

What are ERC 20 standard functions?

The ERC 20 standard prescribes the following functions when developing an Ethereum token:

Get the total supply of tokens: You need to use the “totalSupply” function. Retrieve another owner accounts’ token balance. Send tokens to another owner account: You need to use the “transfer” function. These accounts are EOA accounts. Send tokens from one token address to another. Token addresses are contract addresses, and you need to use “transferFrom” function. Allow another account to withdraw funds from your account repeatedly, within a specified limit. You should use the “approve” function for this. Spenders can return unused tokens to owners, using the “allowance” function.

An ERC 20 bug that burns tokens

While very well documented and implemented overall, the ERC 20 standard has a bug, and this has already burnt tokens worth millions of US dollars. The “transfer” function only allows you to send tokens to another owner, i.e. EOA account.

If you want to send funds to a smart contract account, i.e. the other form of Ethereum accounts, you need to use “approve” and “transferFrom” combination. If you send tokens to a smart contract using the “transfer” function, you will see a successful transaction, but the contract will never receive the tokens.

This burns those tokens forever, and you can’t retrieve them. Several users have used the wrong function to send tokens to smart contracts and lost their tokens for good!

The Ethereum Foundation knows about the bug but continues to promote the ERC 20 standard. I don’t know their reasons for doing so. They probably aren’t appreciating the import of the issue, or there is a resistance to change.

The ERC223 token standard: A proposed resolution for the ERC 20 bug

An Ethereum developer who goes by the Reddit user-name “Dexaran” proposed the EIP 223 with a solution to this ERC 20 bug. Before comparing ERC 20 vs ERC 223 vs ERC 777, I will explain his proposal first.

The ERC223 token standard is still a draft, and the Ethereum community hasn’t implemented it yet. It proposes the following solution:

It considers a transaction on the Ethereum blockchain as an event and uses the ‘event-handling’ concept. If users use the “transfer” function to send tokens to a smart contract, it will throw an error, and will subsequently cancel the transaction. The user pays the Ethereum “Gas price”, but doesn’t lose any token. This proposal adds an additional parameter to the “transfer” function, to check whether the receiving address is a contract account. If it finds that the recipient address is a contract account and not an EOA account, then it assumes that the contract has implemented a “tokenFallback”. A “tokenFallback” function allows calling back the token, so the transaction doesn’t burn any token.

While the ERC223 solves the ERC 20 bug to a great extent, there is a weakness in this proposal. If the recipient smart contract doesn’t have a “tokanFallback” function, then the “Fallback” function will run, resulting in the loss of tokens.

Only a few projects use the ERC 223, an example is the AmigoCoin project. You can read more details about the ERC 223 proposal in the GitHub EIP 223 repository. This standard is also called the ERC 23.

The ERC777 standard: An improved proposal to resolve the ERC 20 bug

An improved proposal to prevent the loss of tokens due to the ERC 20 bug is the ERC 777 proposal. It includes the following:

New functions: “send” instead of “transfer”, “authoriseOperator” instead of “approve”, and “tokensReceived” instead of “tokenFallback”. So long the Ethereum platform had a drawback because developers couldn’t identify what functions smart contracts implement. ERC 820, i.e. another standard, has implemented a central registry of contracts on the network, hence it’s now possible to know the functions and interfaces a smart contract has. ERC777 uses it to identify interfaces that a smart contract uses. Now developers will know beforehand whether a contract has the functions required to receive tokens sent via certain functions. ERC 777 enables ‘whitelisting’ of operators, so the Ethereum network users will now have the capability to reject payment from blacklisted addresses. An address can be blacklisted due to many reasons, for e.g. attempt to hack the network, history of illegal activities.

You can see in the ERC 777 vs ERC 20 vs ERC 223 comparison how the ERC777 provides multiple options to developers so that they can prevent loss of tokens. However, the ERC777 standard also comes with a few risks, as follows:

Some Ethereum developers believe that the “authoriseOperator” function is deprecated, hence developers shouldn’t use it. This function will also require more “Gas” and it will put additional strain on the network. The use of a central registry of smart contracts to look up for the interfaces a contract uses is risky. A central registry may have bugs, and anything depends on it will have an adverse impact.

ERC777 is still a draft, however, the ORCA token uses it. Read the proposal in the EIP 777 GitHub repository.

ERC 777 vs ERC 20 vs ERC 223: Protection of funds is important

While only time will tell which standard the Ethereum ecosystem will accept as the “Gold standard”, you as a developer need to remember that it’s your responsibility to protect traders’ and investors’ funds. If you take such a responsible position, you will probably agree that despite the complexity, the ERC 777 standard should be implemented and adopted.

Note: If you want to learn more about a few key ERC standards, read “The Ultimate List of ERC Standards You Need To Know“.









