• Introducing Solidity
• ERC20 Interface Walkthrough
• Summary

Understanding ERC20

This article assumes the reader is already familiar with at the very least, the following concepts: the Ethereum blockchain, dapps, ether, smart contracts & ICOs.

To quickly re-cap, the Ethereum blockchain is a distributed, open-source blockchain-based computing platform. This computing platform, the Ethereum network, hosts decentralized applications (dapps) that are executed with chunks of codes named smart contracts; all transactions on the Ethereum network, as well as the computing costs of executing smart contracts, are paid for in the Ethereum cryptocurrency ether.

Some, but not all, of these dapps (decentralized apps) require an additional in-dapp currency — these dapps introduce their new currency, named token, and raise funds through an initial coin offering (ICO).

The Ethereum blockchain platform is built in such a way that it encourages dapps of all kind — including those that require the creation, maintenance & transferring of digital assets. These dapp-specific Ethereum tokens can be are implemented in order to create a network of dapps with meaningful use cases such as invoice factoring, browser-wide payments, & a cryptocurrency debit card.

All previously mentioned ideas are currently-live Ethereum based dapp-tokens that follow a very common token programming standard; in fact, 99% of all deployed Ethereum tokens follow this standard, the ERC20 standard.

The ERC20 token standard, which stands for Ethereum Requests for Comment, is a standard set of programming “rules” that all Ethereum-based token are expected to follow. Developers agreed on these six functions & two events as the minimal viable token in order to normalize expected behaviors while communicating across the Ethereum network — by establishing this protocol, Ethereum developers are able to work with external smart contracts easily.

Introducing Solidity

While the most popular Ethereum client is currently written in Google’s GO, the choices for a developer-friendly smart contract language are plentiful. Developers can choose from languages such as Vyper, Bamboo, Serpent & Solidity.

For the remainder of this article we’ll highlight & walkthrough Solidity syntax.

Solidity is a high-level contract-oriented programming language used for implementing smart contracts. The Solidity syntax, to those familiar with programming, is a mishmash of Javascript, Python, & C concepts; it’s statically-typed, supports inheritance & has a host of libraries right from the get-go. For further information on Solidity you should head over to the documentation found here: https://solidity.readthedocs.io/en/develop/#

ERC20 Interface Walkthrough

We’re going to start digging a little deeper into exactly what & how this standard is implemented across the Ethereum network — as previously mentioned, we’ll cover this specifically in Solidity syntax.

In Ethereum-land, it all starts & ends with contracts. Solidity documentation defines contracts as “a collection of code (its functions) & data (its state) that reside at a specific address on the Ethereum blockchain.” Ethereum contracts support inheritance — so a contract can be an instance of another contract.

Following this logic, an abstract contract, one that’s used strictly for inheritance, can also be used as failsafe by defining what a new contract must contain in order to compile. These abstract contracts, are also known as interface contracts.

This means that any token contract that’s an ERC20 instance does not compile without the following; in contrast, this means Ethereum developers now know what functions & behaviors they can expect when interacting with any ERC20 token.

The ERC20 standard is an interface contract that contains a grand total of six executable functions & two logging events.

Allowance

The Allowance function allows for two address to create repeated unidirectional transfer; a wallet address tokenOwner & a second wallet spender are the defined as the two wallets that will engage in repeated transactions. Specifically, the wallet spender will withdraw some amount from the wallet tokenOwner at some interval – both of these are variables that’ll be determined later on.

Approve

For the Approve function, refer back to our Allowance function: the function allows for two addresses to repeatedly withdraw unidirectionally. The Approve function, aptly named, is a simple standard function that calls for the wallet owner to “approve” a transaction that’s about to made on his/her behalf in context of an Allowance. This function requires two inputs, the address of the spender & the amount of tokens being sent. The output returns a public boolean that dictates whether approval was provided or rejected.

BalanceOf

BalanceOf is an intuitive function that accepts a single address input parameter (address tokenOwner) & returns a single public constant (uint balance). The returned uint constant, balance, represents the amount of tokens the queried address holds — remember, transactions on a blockchain are usually public, Ethereum is no different.

TotalSupply

The totalSupply function, as you can probably guess from the name, is an anonymous constructor function that’s ran only once in the very first moment of deployment to the live Ethereum network. The function returns a public constant totalSupply unassigned integer (uint) that acts as that tokens total supply for the remainder of the contracts life. This totalSupply constant is usually defined one of two ways: hardcoding a variable or funding from an origin wallet.

Transfer

The Transfer function is the core function of any ERC20 token; it defines & implements direct wallet-owner-to-peer token transferring. Since wallet owners make this call, only two parameters are required: the receiver address & the amount of tokens being sent. These two parameters are usually initialized as (address to) & (uint tokens). The Transfer return value is simply a boolean that confirms whether the receiver (the “to” address) received the tokens sent.

TransferFrom

The TransferFrom function allows for a smart contract to execute a transfer with the parameters passed on behalf of the wallet owner. Carefully make the distinction with the previous Transfer function. The previous function allowed for the wallet owner to directly send tokens to an address; this TransferFrom allows for a smart contract to send tokens on the wallet owners’ behalf, such as filling an order on an exchange, releasing funds in a timely manner, or paying our winnings in an game of luck.

The TransferFrom function has three input parameters, the address of the wallet owner, the address of the receiver wallet, & the amount of tokens sent. They’re often initialized in in the following syntax: (address from, address to, uint tokens). The function output is exactly the same as the Transfer output: a single public boolean that details the success or failure of the transaction.

Summary

The six functions detailed above are the six core functions found in 99% of all currently live ERC20 tokens. With a few exceptions (looking at you Golem), Ethereum developers can feel safe knowing they can fully expect these core functions while developing internal contracts or when interacting with external public contracts out in the wild.