This article offers a detailed comparison of the common Ethereum token standards — ERC 20 vs ERC 223 vs ERC 777. The comparison will discuss the fundamentals, functionalities, and bugs of these standards.
Are you an Ethereum developer working on a crypto project? You are likely developing the new token using the ERC 20 standard; however, you need to know the improvement efforts as the initial ERC20 token has a severe bug that ‘burns’ accidentally sent tokens.
Due to this flaw, the Ethereum developers and the community later came up with ERC 223 and ERC 777 token standards. To make the right decision about which ERC token standard to use in a project, a clear understanding of ERC 20 vs ERC 223 vs ERC 777 comparison is necessary.
As you know, such proactive moves from the Ethereum developers and community have led to the creation of Enterprise Ethereum — permissioned version of Ethereum designed to meet the enterprise needs.
This article starts the comparison with an explanation of ERC 20, and subsequently explains the drawbacks of it. Then we will explain the improvement efforts that the Ethereum community undertook, via ERC 777 and ERC 223.
Coming Soon: Beginners Guide to Ethereum Development Course
What Are ERC Token Standards?
Before we compare ERC 20 vs ERC 223 vs ERC 777, you need to understand what are ERC standards, and what does ERC represent.
Ethereum developers often submit ‘Ethereum Improvement Proposals’ (EIPs). The Ethereum community reviews EIPs, makes comments, which may trigger some rework.
After the Ethereum community accepts an EIP, it becomes an ERC standard, and we then called it an ‘Ethereum Request for Comments’ (ERC). Only eighteen ERC standards have the ‘Final’ status according to Ethereum Improvement Proposals.
What is ERC 20?
ERC 20 is the most well-known Ethereum token standard and almost all ICOs (what is an ICO initial coin offering) 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 to scale Ethereum dApps. 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?
6 Fundamental Features of ERC20
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.
The 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., an 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 trait burns those tokens permanently, 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.
The ERC223 Token Standard: A Proposed Resolution for The ERC 20 Bug
An Ethereum developer who goes by the Reddit username “Dexaran” proposed the EIP 223 with a solution to this ERC 20 bug.
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. 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.
Risks of ERC777
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.
ORCA token is a great ERC777 example that is a banking platform designed for crypto users.
Recently, non fungible tokens or NFTs and ERC-721 have gained much traction and people are getting more interested in non-interchangeable and unique tokens. What is the difference between ERC20 vs ERC721? ERC20 deals with money and money-like tokens while ERC721 deals with unique and non-interchangeable things.
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. Otherwise, you can take a look at the NEP5 tokens from NEO that challenges ERC20 and ERC777 in every way.
You can sharpen your skills around Ethereum development with our upcoming Beginners Guide to Ethereum Development Course.