[Ethereum] What are the key criteria for meeting the ERC20 token standard

erc-20tokens

I'm looking for a clear way to describe "the ERC20 token standard" to regular folks like me who are not developers, and can't seem to find a plain language articulation of the core components of that standard. Being a non-developer, the github thread where the ERC20 standard was developed is totally Chinese to me. Here is what I do understand and say about ERC20 at the moment (please edit if that is off):

The ERC20 token standard is a set of criteria developed by the Ethereum community for how to set up smart contracts on the blockchain in order to ensure optimal interoperability. ERC stands for Ethereum Request for Comments and this particular request was to help improve the standards to which developers should strive to adhere in developing smart tokens.

Below were my best sources for understanding ERC20 but none of them answer the question I asked above: What are the actual criteria?

  1. themerkle.com/what-is-the-erc20-ethereum-token-standard/
  2. www.ethnews.com/erc20-the-ethereum-token-standard
  3. steemit.com/cryptocurrency/@cryptoadvocator/all-about-ethereum-erc20-token-standard

Best Answer

At a high level, the main parts of ERC20 specify:

1. how tokens can be transferred by its owner

2. how tokens can be transferred on behalf of an owner

3. how to get data about the token

4. events about the token

The first specifies the obvious requirement that tokens must be transferrable, and what ERC20 defines is that you would tell the token contract to transfer some number of your tokens to someone else. You would not tell a token contract to "send" or "give" tokens to someone else: the term ERC20 chose is transfer.

The second part allows you to approve someone to take some number of your tokens and transferFrom you to someone else. It's less obvious why that's needed but it helps in some workflows. For example, one goal of Ethereum and smart contracts is "veridical computing" and a way for this to happen is for someone to publish their contract which says: "if you approve me to use some of your tokens, I will give you X". X could be another token or "smart property". Now you can read that contract, approve the contract and execute the contract. As part of the contract execution, it will transferFrom your tokens and deliver you X. If the contract did not have those terms, you had full control to not approve and execute it in the first place.

This is different from giving the contract your tokens first, and then asking it to deliver X. You don't give someone something and then ask them to sign a promise to deliver you X, because they might take your tokens and ignore your request for X. (There's ways that the contract can be made to keep its promise, but the workflow could be more complicated.) You can see that the type of contract by me "If you give me T, I will give you X" is simpler than you writing a contract for "I will give you T, but you must then give me X": the former is a promise by me and your choice to accept or not; the latter is written by you and I need to accept first before you do anything.

If you approve someone, you or they can find out for how many tokens, by checking their allowance.

The other parts of ERC20 allows anyone to get data like the name, symbol, totalSupply of tokens, as well as the balanceOf an account.

Finally, ERC20 specifies the format and meaning of certain events, for example a Transfer must indicate firstly the sender, secondly the recipient, and thirdly the number of tokens. User interfaces can then take comfort that what they display to users will make sense for tokens that comply with ERC20.

The finalized ERC20 is at https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20-token-standard.md