ERC20 Protocol and Proposals to Improvement

Ethereum allows anyone to create decentralized apps or dApps in given standards and ERC20 protocol is by far the most popular standard for creating smart contracts on Ethereum. The standard defines how tokens will function on the network and as long as a token follows the said standard, then it automatically will be compatible with others and new tokens that adhere to those standards.

ERC20 was introduced in 2015 and there were 66,468 ERC20 token contracts as of April 2018. The said standards relate to six functions that prescribe a number of things such as how tokens are transferred, how users can access data about the token, and different signals that each token takes and which other tokens are attuned to.

The standard specifies a minimum set of functionality that a token must adhere to. However, many token projects go beyond the minimum and add all sorts of features. For instance, most of the major tokens have implemented similar features that appear to be part of the standards including minting/crowdsales where the project builds the token distribution logic directly into the token contract or by a generic function that can be called by an external contract; pausing which is a defined period within which the token is not transferable after the crowdsale; ownership model that allows people to own tokens and to limit actions to ownership; burning where a function is introduced to keep the total supply value up to date; granting an unlimited allowance to a trusted contract; and increase/decrease approval to avoid attack on approve () function.

Many projects also implement advanced features such as vesting/time locking of tokens built directly into the smart contract or implemented with a dedicated contract that holds the locked tokens; upgrading/migrating tokens to a new address; cloning for tokens build off the MiniMe library; whitelisting of addresses only to which transfers can be allowed; liquidity by including a continuous supply model that allows to buy and sell tokens directly from a smart contract; delegated transfers where a project could allow a third party to submit a transfer and the third party pays the gas and collects a token fee off the user -- this will prevent the inconveniencing of user by requiring them to hold ETH in order to pay gas fees.

Using the ERC20 tokens not only introduces some standards for creating tokens but also makes it easy to create exchanges, wallets, smart contracts or other products and services that would otherwise require writing a custom code to communicate with each type of token.

For instance, launching a token with the standard does not need you to create own blockchain, which would take a significant amount of resources and money. It means having some standards not only makes your token interoperable with the rest but also takes lesser time to create, have it adopted by third parties, exchanges and all because those adopting would spend little time adopting the code to their needs.

For instance, a token can get supported and listed at exchanges that already have support for ERC20 tokens because they do not need doing major changes of the code. An ERC20 token is not only popular among many projects but there is also a large community of Ethereum developers which a project can take advantage of when creating and running or maintaining his ERC20 project. But is there any bad side of ERC20? Is it a perfect solution?

While ERC20 token standard has made significant advances in making the creation and operating of a token very easy, it has its bad side including the two main bugs: batchOverlofw bug and the second one causes Unexpected Money Losses.

For instance, many tokens were affected by the batchOverflow Bug, a ‘classical integer overflow issue’ and many exchanges went ahead to suspend the tokens last year. The Unexpected Money Losses occurs in that a person who sends money to a smart contract not built to work with Ether will lose the money and not get the funds back.

Already, $millions have been lost so far via this bug. If a person sends ETH to a contract not intended to work with Ether, it rejects the transactions and ETH is not lost. However, sending ERC20 tokens instead, the transaction is not rejected but the tokens get stuck at the contract's balance and are lost. It cannot recognize an incoming transaction.

Other proposals to improve ERC20

ERC223 protocol

Not only is ERC223 backward compatible with the ERC20 token standard but also improves on a number of issues about the previous standard. Backward compatibility means all the contracts and services that can interact with ERC20 tokens can interact with the ERC223 as well without the need to do any changes.

The main difference between the two is that ERC223 can deal with the inability of a contract to work with the incoming token and thus solving the problem of unexpected losses of tokens when they are sent to an incompatible contract. ERC223 treats transactions as events and the "transfer" function throws an error on invalid transfers and canceling the transaction so no funds are lost.

It checks whether the receiver address is a contract or not. However, it does not prevent loss of tokens sent to an incompatible contract because by assuming that the "tokenFallback" function exists, tokens may still be lost if it does not exist. There are obviously other advantages of ERC223.

For instance, it employs one function "transfer" to send tokens anywhere (whether the receiver is a contractor wallet address) and users do not need to learn how token contract is working in order to send tokens. The "transfer" to the contract also consumes 2 times less gas than ERC20 "approve" and "transfer from" at receiver contract. It also prevents extra blockchain bloating by allowing to deposit tokens into a contract with a single transaction, besides making token transactions similar to Ether transactions.

If a user wanted to send ERC20 tokens to a smart contract and then have the smart contract do something with the tokens, it takes two transactions. First, the user “approves” an allowance for the contract, and then the contract utilizes the tokens via the “transferFrom” function. The “approveAndCall” function is implemented by some token projects to solve this problem where the contract receives and tries to spend tokens from the same transaction to execute the next code.

ERC223 was also targeted at resolving this problem. Not only does it focuses efforts on these issues, but it also adds an additional data parameter to the transfer function to allow for more complex operations than just a token transfer.

ERC777

ERC777 not only maintains backward compatibility with ERC20 but also adds some standards for common actions like minting/burning, and formalizing the concept of “authorized operators” who can spend on your behalf. It standardizes the Mint and Burn functionality of tokens. It also implements transaction handling mechanisms to solve the problem of loss of tokens sent to an incompatible contract.

It uses a new method of recognizing the contract interface and assumes that there is a central registry of contracts on Ethereum's network (this is defined in ERC820 standards). Everyone can invoke this registry to know if a certain address supports a certain set of functions i.e. interface. ERC820 is meant to solve the inability of Ethereum to know what functions a contract implements.

ERC777 allows a project to implement ERC20’s default functions alongside with the new ERC777 functions without overrides (and optionally inherit ERC20’s critical bug). This could improve adoption of the standard. It also introduces a new set of functions including `send` functions instead of `transfer` functions. `authoriseOperator` instead of `approve,` `tokensReceived` handler function instead of `tokenFallback` handler function. This means a project can create a token that is compatible with ERC777 and ERC820 standards simultaneously without any cross or override with functions of any other token standard.

One issue with the ERC777 is, as mentioned, relies on central contract registry which is a security concern as well because it acts as a central point of failure. A bug in the central library can render all addresses prone to exploitation as happened to Parity Multisig that relies on a central code library.

ERC827

Like the ERC223 and ERC777, the ERC827 seeks to extend functionality of ERC20 standard while adding more features/functionality. Not only does it allow for transfer of tokens, it also allows tokens to be approved for spending by an on-chain third-party.

That means any tokens on Ethereum can be able to be re-used by other applications including wallets and decentralized exchanges. In addition to implementing the basic ERC20 functionality, ERC827 implements three main functionality, namely transferAndCall which allows transfer of tokens to an address and firing of the transfer event; transferFromAndCall which allows transfer of tokens from an address to another and firing of the transfer event; and approveAndCall, which allows a user-approved spender to withdraw from a user's account several times up to a given amount and firing of the event.

ERC644

ERC644 introduces upgradeability of tokens as hence opens a door for modular functionality to be added from time to time. ERC721 ERC721 was introduced by Dieter Shirley in late 2017 to improve on ERC20 and would allow smart contracts to operate as tradeable tokens. It's are different from ERC20 tokens in that they are non-fungible tokens.

It means while ERC721 tokens can be traded on an exchange, their value is a result of their uniqueness and rareness associated with each token and not their interchangeability with say money or other tokens. A good applicationis with collectible items where two items would not be fungible in that they have different characteristics, and those characteristics define their unique value to the buyers and sellers.

The same would apply for physical metal coins such as gold coins, copper coins etc, which have different characteristics and therefore different values to collectors. They are not fungible. However, ERC721 is compliant with the ERC20 token standard. This allows tokens to support simple functions such as sending, receiving etc and so that wallets can display information about the token.

ERC865

For Ethereum transactions, gas is paid in ETH. The fee is paid to miners for mining transactions in a PoW algorithm.

The ERC865 proposal provides anability for token holders who wish, to pay the transaction fee for token transfer in tokens instead of gas, and in a single transaction. When the method of gas payment is only Ether, users of other tokens may also need to acquire necessary Ether to pay for gas and may also need to understand gas prices, costs and how Ethereum itself works.

The standard introduces a third party who takes transfer fee in the tokens and forwards the transaction with necessary fee in ether to the blockchain. This may ease adoption of DAPPS that have in-built tokens.

ERC-884

ERC 884 proposal allows the creation of tradeable ERC20 tokens with each of them representing a numberless share issued by a Delaware corporation, whether it is private or public.

With ERC 884 tokens, a firm can raise funds either via IPO (initial public offering) or via a private equity sale, all in conformance to Delaware Corporations Law, but bypassing the need for a custom share registry, or the involvement of a traditional stock exchange or transfer agent.

Instead of leaving owner whitelisting and verification to separate crowdsale, ERC 884 requires that all token owners are whitelisted. The whitelist can be referenced by accompanying crowdsale contracts, to enforce eligibility, but the whitelist remains an integral part of the token contract itself. Each of the shares are not numbered and an owner of ERC884 token simply owns the equivalent single paid share.

ERC-1155

ERC-1155 protocol introduces a standard smart contract that allows for managing multiple token types including any combination of fungible tokens, non-fungible tokens, or other configurations (for example, semi-fungible tokens). It builds on or improves on the ERC-721, which is a non-fungible token standard.

However, while a ERC-721 Token ID is a single non-fungible index and the group of these non-fungibles is deployed as a single contract with settings for the entire collection, ERC-1155 Multi Token Standard allows for each Token ID to represent a new configurable token type, which may have its own metadata, supply and other attributes.

ERC-948

The ERC 948 protocol proposes a smart contract that allows users to opt ouof crypto tokens services in order to arguably align consumer and supplier incentives. The smart contract to be embedded would allow withdrawal of a certain number of tokens from their wallet every defined time period by the company in question and they canremove consent at any time.

The protocol can be used to support a shared contract or a contract-per-subscription and in this case, a user would not need to audit every single subscription. The contract would make it possible for users with many subscriptions to manage those subscriptions from a single place instead of managing all contracts separately.

It would also create an opportunity to save gas although being a centralization solution, it would create a single source of vulnerability.bHowever, in addition to improving user experience, it could reduce time and gas consumption, as well as make it easy for service providers.