The ERC20 standard was proposed in 2015 through an Ethereum Improvement Proposal, EIP-20. This standard outlines the fundamental functionality for most tokens used today and a smart contract must meet these minimum criteria in order to be considered an ERC20 token. The core components of ERC20 tokens are transfers and approvals. We covered approvals and third-party allowances in a previous post that can be found here:
There are nine methods outlined in the standard. Of the nine methods, six are “view” methods that only return info on the state of the smart contract and three methods can actually update the data in the contract. Most implementations of ERC20s have additional methods, but these listed below are the minimum in order to be compliant. It may also be helpful to read the following article to understand how data is structured in the state of these contracts:
View Methods
View methods only return information about the state of the token contract. These methods do not update the smart contract and do not require gas to execute. You can follow along by going to the USDC page in Etherscan and opening the “read contract” tab. Each of the methods listed below will be on that page and you can call them to view the return value of the USDC contract on Ethereum.
name()
Requires no parameters and returns the name of the ERC20 token as a text string.
symbol()
Requires no parameters and returns the symbol, or ticker, of the ERC20 token as a text string.
decimals()
Requires no parameters and returns the number of decimals that the ERC20 token uses as an unsigned (positive) integer. This is used to determine the divisibility of a token. Most have 18 decimals but some, like USDC, have 6.
totalSupply()
Requires no parameters and returns the total supply of the token.
balanceOf()
Requires an address parameter and returns the token balance for that address as an unsigned integer.
allowance()
Requires two parameters, one “owner” and one “spender”. It returns the amount of tokens that the spender is allowed to spend on behalf of the owner as an unsigned integer.
Update Methods
These methods update the state of the contract and do require gas to execute.
transfer()
Requires two parameters, “to” and “value”. The address calling this method will have their balance reduced by “value” and the recipient, or the “to” address, will have their balance increased by “value”. This method will return a value of True if successful and will throw an Error if the sender’s balance is less than the “value” being transferred.
approve()
Requires two parameters, “spender” and “value”. The address calling this method will be creating an allowance in the ERC20 contract that allows the spender address to transfer tokens on their behalf. This method will return a value of True if successful.
transferFrom()
Requires three parameters: “from”, “to”, and “value”. This method is meant to be called by a spender that was previously approved. The allowance for the spender would be reduced for the spender as well as the token balance for the “from” address. The token balance for the “to” address would be increased by “value”.
Implementations
The ERC20 standard only outlines the name of the methods, what they should accept as parameters, what errors they should throw, and what they should return. It does not include the actual implemented code. Two of the more commonly used code implementations of the standard are the ConsenSys and the OpenZepplin codebases.
Disclaimer
We, Digital Opportunities Group, LLC, are not providing investment or other advice. Nothing that we post on Substack should be construed as personalized investment advice or a recommendation that you buy, sell, or hold any security or other investment or that you pursue any investment style or strategy.
Case studies may be included for informational purposes only and are provided as a general overview of our general investment process. We have compiled our research in good faith and use reasonable efforts to include accurate and up-to-date information. In no event should we be responsible or liable for the correctness of any such research or for any damage or lost opportunities resulting from use of our data.
We are not responsible for the content of any third-party websites and we do not endorse the products, services, or investment recommendations described or offered in third-party social media posts and websites.
Nothing we post on Substack should be construed as, and may not be used in connection with, an offer to sell, or a solicitation of an offer to buy or hold, an interest in any security or investment product.