ERC223 And Beyond
ERC20 is the most widely adopted standard for Ethereum based tokens, and is used today by the majority of ICOs that take place. It is well known that ERC20 is not bug-proof, and contains critical logic errors that could lose investors a lot of token should they fall victim to these errors.
Why is this standard the most widely adopted?
Firstly, because it was the first standard that was adopted by the Ethereum community and thereafter exchange and wallet platforms. Contract to contract code also adheres to the ERC20 standard interface that would require reengineering to accept a different standard if it was not backwards compatible.
ERC20 also does a great job at fund grabbing, and with Ethereum themselves still promoting this standard, there is little incentive for developers under time sensitive deadlines to look for alternatives, consequently sticking to what they know.
To get a feel of the activity taking place with Etherum tokens, check out Ethereums EIP (Ethereum Improvement Proposals) Github page. On this page you will see that proposals are split into 4 categories, namely Draft, Accepted, Final and Deferred. Take a look at the already finalised EIPs to get a sense of how the proposals vary in usage, gas and other technicalities.
We will focus on one of these EIPs, ERC223, and why it is a good candidate to replace ERC20.
But firstly, what exactly is this critical bug that is plaguing ERC20 right now?
Let's quickly examine the ERC20 logic flow. The transfer function allows you to send tokens to an address – more specifically, a wallet address. If you want to deposit tokens to a smart contract address, a combination of approve and transferFrom functions should be used. Concretely, you need to authorise the contract to withdraw your tokens with the approve function, followed by a contract hosted function call that will carry out the withdrawal from your deposit.
So what happens if we deposit tokens via the transfer function? The transaction will succeed, but the recipient contract will not recognise it. Moreover, if the contract does not support a method to withdraw these tokens in some way, then they will be lost forever. This is permanent loss that has already lost the ecosystem millions of dollars.
With this widely known issue, one of the proposed solutions is the ERC223 standard, which is hosted here on Github by user Dexaran.
The author explains what ERC223 exactly is:
"ERC223 is a superset of the ERC20 token standard. It is a step forward towards economic abstraction at the application/contract level allowing the use of tokens as first class value transfer assets in smart contract development. It is also a more safe standard as it doesn't allow token transfers to contracts that don't support token receiving and handling."
There are 3 primary improvements with ERC223:
It eliminates the problem of lost tokens that happens during the transfer of ERC20 tokens to a contract (when people mistakenly use the instructions for sending tokens to a wallet). ERC223 allows users to send their tokens to either wallet or contract with the same function transfer, thereby eliminating the potential for confusion and lost tokens.
It allows developers to handle incoming token transactions, and reject non-supported tokens. This is not possible with ERC20.
Energy savings. The transfer of ERC223 tokens to a contract is a one step process rather than 2 step process, resulting in less gas used and less Blockchain bloating.
Moreover, ERC223 tokens are backwards compatible with ERC20 tokens. Meaning ERC223 will not break any existing infrastructure designed for working with ERC20 tokens.
This insight has touched on one EIP. The development of EIPs is an ongoing process. Proposals are actively being introduced, discussed and evolved. We encourage anyone with an interest in ICOs, tokens or smart contract development in general to read up on proposals of interest, contribute your thoughts and ultimately shape the future of the Ethereum token standards.