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 token standards in detail. If you already know what token standards are and why we need them, let’s learn about how fungible tokens have been developed throughout time. written about This is gonna be a short article, unlike my other articles. ERC20 The first ERC proposed for fungible tokens was . ERC20 was a very simple interface allowing the users to send, receive and 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. ERC20 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 and functionality. Whenever we need to send tokens to any dApp to make a purchase 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 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. approve transferFrom transferFrom 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 and by adding one more function with the same name as the function but an additional parameter of bytes. approve transferFrom transfer function transfer(address _to, uint _value, bytes calldata _data) returns (bool) 2. It also introduced a function for the receiver contract same as what we have in and . 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. tokenReceived ERC721 ERC1155 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 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. ERC777 It has a concept of similar to the , but with the extended functionality of rejecting tokens. The hooks are a bit different in ERC777 because ERC777 introduces the usage of which is a registry contract. The hooks will be only called when the address has registered the interface( or ) via ERC1820. hooks tokenReceived ERC1820, ERC777TokensRecipient ERC777TokensSender and interfaces are used to notify the increment and decrement of balance respectively only to the addresses which have registered these interfaces via ERC1820. ERC777TokensRecipient ERC777TokensSender 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. Also published here. Thanks for reading it. Connect with me on and also share your reviews with me. Twitter

This story contains new, firsthand information uncovered by the writer.

An Update to Solidity’s ‘Assert()’ Statement You Might’ve Missed

How the Ethereum Blockchain Incentivizes Users to Clear Storage 

Everything related to EVM, solidity, Ethereum

Read My Stories

Too Long; Didn't Read

Download free Tech Leaders Productivity Report!

Fungible Tokens: Tracing the Evolution of Digital Assets

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

An Update to Solidity’s ‘Assert()’ Statement You Might’ve Missed

06/09/2018: Biggest Stories in the Cryptosphere

07/09/2018: Biggest Stories in the Cryptosphere

0x Protocol, Waves, and EtherDelta: Solutions and Limitations of Distrust

03/09/2018: Biggest Stories in the Cryptosphere

An Update to Solidity’s ‘Assert()’ Statement You Might’ve Missed

06/09/2018: Biggest Stories in the Cryptosphere

07/09/2018: Biggest Stories in the Cryptosphere

0x Protocol, Waves, and EtherDelta: Solutions and Limitations of Distrust

03/09/2018: Biggest Stories in the Cryptosphere

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps