Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
ERC stands for âEthereum Request for Comment.â This is Ethereumâs version of a Request for Comments (RFC), a concept devised by the Internet Engineering Task Force. Memos within an RFC contain technical and organizational notes. For ERCs, this includes some technical guidelines for the buildout of the Ethereum network.
This was written by Ethereum developers for the Ethereum community. Thus, the workflow of generating an ERC includes a developer. To create standards for the Ethereum platform, a developer submits an Ethereum Improvement Proposal (EIP). This includes protocol specifications and contract standards. Once that EIP is approved by a committee and finalized, it becomes an ERC. The complete list of EIPs can be found here.
The finalized EIPs give the Ethereum developers a set of implementable standards. This allows Smart Contracts to be built with these standards, which a common interface can access. ERC-20 is the most well-known of all the standards within the entire crypto community, and most tokens issued on top of the Ethereum platform use it.
Whats in the ERC-20 Standard?
The ERC-20 standard includes the following functions:
- totalSupply(): returns total token supply
- balanceOf(address _owner): returns account balance of _ownerâs account
- transfer(address _to, uint256 _value): takes in number _value and transfers that amount of tokens to address _to and triggers transfer event
- transferFrom(address _from, address _to, uint256 _value): transfers _value amount of tokens from the address _from to the address _to, and triggers the transfer event
- approve(address _spender, uint256 _value): allows _spender to withdraw any number up to _value amount
- allowance(address _owner, address _spender): returns the amount which the_spender is still allowed to withdraw from the _owner
The following events are triggered based on the functions above:
- transfer(address indexed _from, address indexed _to, uint256 _value): this is triggered whenever tokens are transferred
- approval(address indexed _owner, address indexed _spender, uint256 _value): is triggered on any call to approve()
ERC-20 was proposed in 2015 and officially formalized in September 2017. It is a great starting point for token standardization. However, some in the developer community have noted that it has certain flaws and vulnerabilities. Additionally, there are some use cases that require something different. Take a look at some of the proposed ERC standards below:
ERC-223
Status: OpenDate Proposed: 3/5/2017
A post by developer Dexaran describes these two scenarios in detail:
âThere are two ways of performing a transaction in ERC20 tokens:1. transfer function.2. approve + transferFrom mechanism.Token balance is just a variable in the token contract.The transaction of a token is a change in the internal variables of the contract. The balance of the sender will be decreased and the balance of the recipient will be increased.The transfer function will not notify the recipient when the transaction occurs. The recipient will not be able to recognize the incoming transaction! I wrote this illustration of the process that is leading to unhandled transactions and money losses.As a result, if the recipient is a contract, users must transfer their tokens using the approve +transferFrom mechanism. If the recipient is an externally owned account address, users must transfer their tokens via the transfer function. If a user makes a mistake and chooses the wrong function, the token will get stuck inside contract (contract will not recognize a transaction). There will be no way to extract stuck tokens.â
His proposed solution to this issue is contained within ERC-223. It is very similar to the ERC-20 standard, but it solves the problems described above. When tokens are transferred to a smart contract, a special function of that contract is tokenFallback. This allows the receiving contract to decline the tokens or trigger further actions. This can be used in place of the approve function in most cases.
ERC-621
Status: OpenDate Proposed: 5/1/2017
ERC-621 is an extension of the ERC-20 token standard. It adds two additional functions, increaseSupplyanddecreaseSupply. This can increase and decrease the token supply in circulation. ERC-20 only allows a single token issuance event. This restricts the supply to a certain amount which canât be changed. ERC-621 proposes that totalSupply can be modified.
ERC-721
Status: Open Date Proposed: 9/22/2017
ERC-721 is very different than ERC-20 and ERC-223. It describes a non-fungible token. This means that each token is totally different and each one can have a different value to different users. One way to think about this is to recall CryptoKittes. Each one is its own separate commodity whose value is based on its own rarity and desirability by users.
ERC-721 tokens can be used in any exchange, but the token value is âa result of the uniqueness and rareness associated with each token.â The standard functions are name, symbol, totalSupply, balanceOf, ownerOf , approve , takeOwnership , transfer , tokenOfOwnerByIndex, and tokenMetadata. It also defines two events: Transfer and Approval. This article by Gerald Nash does a good job explaining the concept of fungibility as it relates to tokens and goes into good technical detail.
ERC-827
Status: OpenDate Proposed: 1/12/2018
Another extension of the ERC-20 standard is ERC-827. It allows for the transfer of tokens and allows tokens to be approved by the holder to be spent by a third party. Tokens on Ethereum can be reused by other applications, including wallets and exchanges. This could be very useful for spending a dynamic amount that is up to a third party based on some criteria both parties have agreed to. Most importantly, since it is an extension of ERC-20, it is also ERC-20 compatible.
Some of the proposed functions include:
transferFrom(address _from, address _to, uint256 _value, bytes _data) returns (bool success)
and
function approve(address _spender, uint256 _value, bytes _data) returns (bool success)
These are some of the more interesting standardization proposals so far. Please feel free to suggest any others that you believe should be on this list!
Sources
The Anatomy of ERC721 by Gerald Nash The New ERC223 Token by Leonid BederERC standards to move Ethereum forward? ERC-20, ERC-223, ERC-721 by Lucas KUnderstanding ERC-20 Token Contracts by Jim McDonald An Appeal to Token Developers by DexaranERC827 on Github
The Ethereum token standards you need to know was originally published in freeCodeCamp on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.