The evolution of fungible tokens

Fungible tokens are one of the most famous and important features in the Ethereum ecosystem, as it opens the doors for an enormous number of use cases from ICO/IDO to governance and many more.

I already have written about token standards in detail. HERE
If you already know what token standards are and why we need them, let’s learn about how fungible tokens are being developed throughout time.

This is gonna be a short article, unlike my other articles.

ERC20

The first ERC proposed for fungible tokens was ERC20.
ERC20 was a very simple interface allowing the users to send, receive and allow someone to spend their tokens.
As it was the first, it was the simplest with no extra features, which led to many problems.
One of the problems is the accidental transfer of tokens to any smart contract that doesn’t have a recovery functionality, in this case, the tokens will be forever locked in the contract.
At present, tokens worth millions of dollars are locked inside contracts because of this flaw.
Apart from this, there is one more problem, which is considered a bad UX as well as a security issue in some cases. We are talking about approve and transferFrom functionality.
Whenever we need to send tokens to any dapp to buy something or for any service, we first approve the dapp to spend our tokens and then we need to call the desired function that calls the transferFrom function to deduct the tokens and give us what we want. This way we end up sending two different transactions, which is not considered as a good UX.

ERC223

Considering these issues and limitations, ERC223 was proposed in the year 2017 with two new addition to the functionalities.
1. ERC223 claimed that it would remove the need to call approve and transferFrom by adding one more function with the same name as the transfer function but an additional parameter of bytes.

function transfer(address _to, uint _value, bytes calldata _data) returns (bool)

2. It also introduced a tokenReceived function for the receiver contract same as what we have in ERC721 and ERC1155.
This function should be called every time tokens are transferred to a contract, to ensure that the receiver contract has the functionality to retrieve the tokens.

But this standard is still in draft and not officially included in the official ERC standard due to less adoption.

ERC777

Meanwhile, a new standard ERC777 was proposed months after ERC223 and also became an official standard with more adoption than ERC223

ERC777 was not just an addition to ERC20, instead, it was a whole new standard with new functions and new concepts.

It has a concept of hooks similar to the tokenReceived, but with the extended functionality of rejecting tokens. The hooks are a bit different in ERC777 because ERC777 introduces the usage of ERC1820, which is a registry contract.
The hooks will be only called when the address has registered the interface(ERC777TokensRecipientor ERC777TokensSender) via ERC1820.

ERC777TokensRecipient and ERC777TokensSenderinterfaces are used to notify the increment and decrement of balance respectively only to the addresses which have registered these interfaces via ERC1820.

ERC777 also replaces the approve and allowance functionality from ERC20 and uses the concept of operators instead. This operator functionality is similar to what we see in ERC721 i.e. you can allow an address to spend all your tokens.

Apart from this ERC777 also removes the concept of decimals and introduces granularity which means whatever value you are working within the sending, minting, or burning of the tokens it should be a multiple of the granularity value. It simply means granularity is the lowest unit in which a token value can be determined.

But ERC777 is also considered as an overengineered and security flawed standard by a lot of people in the community, which indicates that it’s not gonna be adopted like ERC20.
There is a lot more to discuss about ERC777 which I will discuss in a separate article dedicated to ERC777. STAY TUNED.

Even after these attempts to get a better version of fungible tokens, we still haven’t found any better standard.

Let’s see if any token standard comes in which can truly replace or improve ERC20 and its limitations.

Thanks for reading it. Connect with me on Twitter and also share your reviews with me.