ERC223 – Proposed ERC20 Upgrade

• The 375K Reasons For Improving ERC20
• ERC223 Proposal
• Evolution of ERC

The 375K Reasons For Improving ERC20

With ERC20 token-based juggernauts such as EOS, Basic Attention Token (BAT), and Storj, it’s difficult to argue the interface contract’s success. The Ethereum community has clearly rallied support around this standard, & both developer communities and financial markets are responding positively. However, for all of its success the ERC20 standard has resulted in one not-so-insignificant bug:

The ERC20 token standard is leading to money losses for end users by allowing users to send ERC20 tokens to none-ERC20 compliant token addresses.

When a user sends an ERC20 token to an Ethereum contract that doesn’t recognize ERC20 tokens, the user loses access to his or her funds forever. Just exactly how many funds are currently locked due to this issue? Again, not an insignificant amount:

• 310,067 GNT are stuck in Golem contract (currently worth about $217K).
• 242 REP are stuck in Augur contract (currently worth about $15K).
• 814 DGD are stuck in Digix DAO contract (currently worth about $125K).
• 14,506 1ST are stuck in FirstBlood contract (currently worth about $12K).

This is over a whopping $370K+ of ERC20 tokens that are frozen in these contracts; since the list of ERC20 tokens is growing, this number is most likely a conservative underestimate of the total amount of these tokens frozen in contracts. The list above is by no means exhaustive — these are just a few of the more popular ERC20 tokens.

None of the contracts above ever expected to receive any ERC20 tokens — so when users send tokens to these addresses, the transactions are confirmed by the network; however, the receiving contract doesn’t recognize the tokens. It doesn’t know what to do with these tokens which results in the funds being locked forever. Again, the tokens don’t get rejected — they’re just entirely ignored by the receiving contract.

The majority of these transactions are unintentionally committed by end users calling the transfer function (as opposed to the automated transferFrom function introduced previously). Recall that ERC20 makes use of both Transfer & TransferFrom — as it turns out some end users are using Transfer to directly send ERC20 tokens to contracts that aren’t expecting, & therefore don’t recognize, the incoming tokens.

Eventually, a few members of the Ethereum community decided to tackle this issue head-on by requesting a new ERC token standard. The issue number of this new token standard on GitHub, is issue number #223.

ERC223 Proposal

GitHub user Dexaran suggested a new ERC standard (ERC223) back in March 5th, 2017 that aimed to fix this token fallback failure issue. The abstract for his GitHub issue #223 new token proposal is the following:

The following describes standard functions a token contract and contract working with the specified token can implement to prevent accidentally sends of tokens to contracts and make token transactions behave like ether transactions.

Dexaran’s token proposal implements two core features in order to immediately stop decentralized app users from accidentally sending tokens to smart contracts that aren’t ready to receive said tokens:

1. Consolidating the ERC20 Transfer & TransferFrom functions into a single Transfer function with three parameters: (address _to, uint _value, bytes data).
2. The receiving contract, if receiving tokens, must contain a TokenFallBack function that defines exactly how to handle which type of incoming token.

Transfer & TransferFrom -> Transfer

A key part of ERC20 standard that contributes to this common issue is the fact that end users have the option mistakenly use one of the two functions used to transfer (Transfer & TransferFrom).

ERC223 proposes replacing both functions with a single Transfer function.

The ERC223 allows dapp end-users to send tokens to any Ethereum address, regardless of whether that contract is a wallet or a contract, with the same Transfer function. The logic here is that by eliminating the option for users to trigger a Transfer function or a TransferFrom function to just a single Transfer function, end users no longer have the potential to use the incorrect function.

The newly proposed Transfer function accepts three parameters (previously only accepted two), and, more importantly, it looks to invoke a TokenFallback function on the receiving address. Without the three defined parameters, the Transfer function fails to compile; without the receiving address containing a TokenFallback function, the Transfer function transaction will fail & no tokens will be transferred.

function tokenFallBack()

In Ethereum development there exists a contract modifier payable that’s used to prepare a contract to receive Ether — this means a contract is now expecting the digital currency. If a contract does not contain the payable modifier, the transaction sent is simply canceled & returned. Nothing fancy, this is Ethereum 101.

An analogous way of thinking about the ERC223 tokenFallback function is that the payable modifier is to preparing a contract to receiving Ether, as the tokenFallback function is to preparing a contract to receive x token.

In this standard, contract developers must implement tokenFallback if they want their contracts to work with specific tokens. If the receiver is a non-contract address, an ERC223 token transaction will execute just like any current ERC20 token transfer. On the other hand, if the receiver is a contract, then the ERC223 token contract will first try to call tokenFallback on the receiver contract; if no tokenFallback function is found, the transaction will fail.

Evolution of ERC

Despite the rough draft state of ERC223, another ERC standard looms on the horizon — ERC 721. ERC721 focuses on non-fungible assets such as CryptoKitties, Decentraland land, & perhaps even one-day real-estate assets. ERC 721 progress can be found here: https://github.com/ethereum/eips/issues/721

All to show that while young, the Ethereum community is very serious about improving its smart contract platform by putting the right standards in front of a growing wave of new developers. Slowly but surely, ERC token bugs will decrease — and then the question will become can the latest standard scale?