In this article, we will compare Ethereum Request for Comments #223 (the new ERC223 token standard) to the popular ERC20 token standard and discuss its motivation and advantages (Kin is an ERC20 token).

TLDR: ERC20 should be retired, and it’s better to use the new ERC223 token standard when implementing new tokens. Long live the new ERC223 token standard!

ERC20 Token Standard: An Oldie, but a Goldie

The ERC20 token standard, which was already formalized as Ethereum Improvement Protocol #20 (EIP20), defines a common list of rules for all Ethereum tokens to follow. This ensures common interfaces/methods and provides best practices. For example, an exchange or a smart contract (or an exchange that is a smart contract, such as EtherDelta) would only need to implement the integration logic once and later reuse the same code and functionality when listing ERC20 tokens. This is because all tokens respond to the same interface.

At the moment, there are about 100,000 ERC20 compatible token smart contracts deployed to the public Ethereum main-net, hundreds of which belong to ongoing projects and teams. For example, here are the top 10 tokens, according to the number of performed operations/transactions so far:

Top 10 ERC 20 tokens

At the time of writing, the Kin token has had about 43,946 transactions, which ranks it somewhere around thirtieth (and we expect its transaction rate to increase much more once the alpha is released).

ERC20 Interfaces

In order to comply with the ERC20 standard, the token developer needs to implement the following interfaces:

name (optional)

Returns the name of the token (e.g., "Kin" ).

symbol (optional)

Returns the symbol of the token (e.g., "KIN" ).

decimals (optional)

Returns the uint8 number of decimals the token uses (e.g., 18 means to divide the token amount by 10^18 (1000000000000000000) to get its user representation).

totalSupply

Returns the total token supply.

balanceOf(address _owner)

Returns the account balance of another account with the address _owner .

transfer(address _to, uint256 _value)

Transfers _value amount of tokens to address _to and must fire the transfer event. The function should revert if the _from account balance does not have enough tokens to spend.

A token contract which creates new tokens should trigger a transfer event with the _from address set to 0x0 when tokens are created.

Transfers of zero value must be treated as normal transfers and fire the transfer event.

transferFrom(address _from, address _to, uint256 _value)

Transfers _value amount of tokens from the address _from to the address _to , and must fire the transfer event (see below).

The transferFrom method is used for a withdrawal workflow, allowing contracts to transfer tokens on your behalf. For example, this can be used to allow a contract to transfer tokens on your behalf and/or to charge fees in sub-currencies. The function should revert unless the _from account has deliberately authorized the sender of the message via some mechanism.

Transfers of zero value must be treated as normal transfers and fire the transfer event.

approve(address _spender, uint256 _value)

Allows _spender to withdraw from your account multiple times, up to the _value amount. If this function is called again it overwrites the current allowance with _value .

To prevent attack vectors like the one described here and discussed here, clients should make sure to create user interfaces in a way that sets the allowance first to 0 before setting it to another value for the same spender.

allowance(address _owner, address _spender)

Returns the amount which the _spender is still allowed to withdraw from the _owner .

Events

Transfer(address indexed _from, address indexed _to, uint256 _value)

Must trigger when tokens are transferred, including zero-value transfers.

Approval(address indexed _owner, address indexed _spender, uint256 _value)

Must trigger on any successful call to approve(address _spender, uint256 _value) .

ERC223: So What’s All the Fuss About?

ERC223 is a new token standard that was proposed a couple of months ago and in the process of formalizing into an official EIP (Ethereum Improvement Protocol).

It’s important to remember that ERC223 tokens are backwards compatible with ERC20 tokens. It means that ERC223 supports every ERC20 function and contract or service working with ERC20 tokens, and will work with ERC223 tokens correctly.

After accustoming ourselves with the interfaces and the behaviors of an ERC20 token, let’s see some of its imperfections and how can they be resolved.

Accidental transfer of tokens to an unaware contract

There are two different ways to transfer ERC20 tokens depending on whether you intend to send the tokens directly or delegate the transfer to another smart contract. You can either call transfer to send tokens to a wallet address or call approve , and then trigger transferFrom from the receiver contract, in order for it to be aware of the transfer and handle it accordingly.

But what happens when you transfer your tokens to a contract address that is unaware or doesn’t expect these tokens (e.g., by simply mistyping your intended address)? Unfortunately, your tokens are going to be lost forever.

There are already a number of tokens held by token contracts that didn’t expect any tokens transfers (and the list is only growing). These tokens will not be accessible as there is no function to withdraw them from the contract.

For example: