Ethereum Tokens: ERC 20 vs. ERC 223 vs. ERC 777

Ethereum, as we know, is a global open-source platform for decentralized applications. Using Ethereum, one can write code which runs exactly as programmed, controls digital value, and can be accessed from anywhere in the world. Ethereum was launched in 2015, and it is the world’s leading programmable blockchain. Developers can build new kinds of applications on Ethereum. Ethereum is a foundation for the new era of the internet which is built on an open-access, neutral infrastructure that is not controlled by any company or person.


 What Is An Ethereum Token?


Ethereum tokens are digital assets that are built on top of the Ethereum blockchain. These may represent anything from a physical object like Gold to a native currency like Golem, which is used to pay transaction fees. In the future, these may also represent financial instruments like bonds and stocks. They benefit from the existing infrastructure of Ethereum as developers need not construct an entirely new blockchain. They strengthen the Ethereum ecosystem by driving the demand for Ether, Ethereum’s native currency, that is needed to power the smart contracts. Smart contracts are self- executing contracts where the terms of the agreement between the buyer and seller are directly written into lines of code.


In this article, we will be comparing the three Ethereum tokens, namely ERC-20, ERC-223, AND ERC-777.


Often, Ethereum developers submit ‘Ethereum Improvement Proposals’ (EIP). The Ethereum community then reviews the EIPs and provides comments and suggestions, which may trigger some rework. After an EIP is accepted by the Ethereum community, it becomes a standard, and we call it ‘Ethereum Request for Comments.’ ERC-20 is one such Ethereum token standard. It is a famous token standard that has been used by all the ICOs which have used the Ethereum platform. By default, developers use it to create new tokens. Wallet s and exchanges accept these tokens easily. Before the launch of the ERC-20 token, Ethereum developers had to set rules for their token to follow, and this approach lacked standardization. ERC-20 token is more standardized.


Functions prescribed by ERC-20 standard while developing an Ethereum token


  • Get the total supply of tokens by using the “total supply” function.


  • Retrieve the token balance from another owner account.


  • Send the tokens to another owner account. These are “EOA” accounts. For this, we use the transfer function.


  • Send the tokens from one address to the other. Token addresses are contract addresses. For this, we will use the “transferFrom” function.


  • Allow another account to repeatedly withdraw funds from your account, within a specified limit. For this, we use the “approve” function.


  • By using the allowance function, spenders can return unused tokens to owners.



An ERC-20 bug that burns tokens


Though the ERC-20 token is well-documented and well-implemented overall, the ERC-20 token standard has a bug. This bug has burnt tokens worth millions of US dollars. With the transfer function, you can only send tokens to the EOA account. If you use the “transfer” function, you will see a successful transaction, but the contract will never receive the tokens. This burns the tokens forever, and it can’t be retrieved. By using the wrong function, several users have lost their tokens for good!


ERC-223 Token Standard- a proposed resolution for the ERC-20 bug


The ERC-223 token standard was developed by an Ethereum developer who goes by the Reddit username “Dexaran.” He proposed it as a solution to the ERC-20 bug.


The draft of the ERC-223 token standard proposes the following solution:


  • It considers transactions on the Ethereum blockchain as events.


  • If users use the “transfer” function, it will display an error and subsequently cancel the transaction.


  • Though the user pays the Ethereum “Gas price,” he doesn’t lose any token.


  • An additional parameter of checking whether the receiving address is a contract account is added to the “transfer” function.


  • If it finds that the recipient address is a contract account and not an EOA account, it assumes that the contract has implemented a “tokenFallback.”


  • Using a “toeknFallback” function, we can call back the token so that the transaction doesn’t burn the token.



Though the ERC-223 function solves the ERC-20 bug to a great extent, there is a weak point in this proposal. In case the recipient smart contract does not have the “tokenFallback” function, the “Fallback” function will run, resulting in the loss of tokens.


ERC-777- an improved proposal to the ERC-20 bug


The proposal of ERC-777 includes the following:


  • New functions introduced are “send” instead of “transfer,” “authoriseoperator” instead of “approve,” and “tokensReceived” instead of “tokenFallback.”


Till now, developers couldn’t identify the functions which can be implemented by smart contracts. Another token standard called the ERC-820 has implemented a central registry of contracts on the network. So, it is now possible to know the interfaces and functions a smart contract has. ERC-777 uses this to identify the interfaces a smart contract uses. Developers will now know beforehand if a contract has the functions required to receive tokens sent through certain functions.

  •  “Whitelisting” of operators is possible with ERC-777. So, Ethereum network users will now be capable of rejecting payment from blacklisted addresses. An address can be blacklisted due to reasons such as a history of illegal activities and attempts to hack the network.



You will now be able to understand that out of these three tokens, the ERC-777 token provides developers with multiple options to prevent the loss of tokens. However, the ERC-777 standard is also associated with risks such as:


  • Some Ethereum developers are of the opinion that the “authoriseoperator” function is deprecated; so developers shouldn’t use it. This function will need more “Gas,” and it will put additional strain on the network.


  • Using a central registry of smart contracts to look up for the interfaces a contract uses is risky. It is possible for the central registry to have bugs, and anything that depends on it will have an adverse impact.





Only time will tell as to which standard will be accepted as the “Gold standard” by the Ethereum ecosystem. It is the primary responsibility of you, as a developer, to protect the funds of traders and investors. If you accept such a responsible position, you will probably agree that the ERC-777 standard must be adopted and implemented, despite the risks.