Chapter 6 · Tokens · lesson 2

ERC-20 from scratch

20 min

You will never write an ERC-20 by hand in production. You will import OpenZeppelin's, like everyone else.

Write one anyway, once. Every token you ever read, audit or exploit is this file with additions.

ERC-20 is not code. It is an agreed list of function signatures — a promise that if your contract exposes these, every wallet, exchange and protocol on earth can use it without knowing anything else about you.

That is the whole innovation. Not the transfers, the interoperability.

The spec

Six functions and two events. That is the entire standard:

function totalSupply() external view returns (uint256);
function balanceOf(address account) external view returns (uint256);
function transfer(address to, uint256 value) external returns (bool);
function allowance(address owner, address spender) external view returns (uint256);
function approve(address spender, uint256 value) external returns (bool);
function transferFrom(address from, address to, uint256 value) external returns (bool);

event Transfer(address indexed from, address indexed to, uint256 value);
event Approval(address indexed owner, address indexed spender, uint256 value);

name, symbol and decimals are optional extras that everything relies on anyway.

Build it

Nothing is written for you. Work top down: state, constructor, then the three functions that change things.

Token.solCompose

Loading editor…

Build a working ERC-20. Nothing is written for you.

Run the code to see what happens.

Nudge

Work top down: state variables, then the constructor, then the three functions.

Show me the approach

The constructor sets totalSupply and gives it all to `msg.sender`. `transfer` checks, subtracts, adds, emits. `approve` writes one mapping entry. `transferFrom` checks the allowance *and* the balance.

Show me the code

Remember `1000 * 10 ** 18` for the supply, and that `transferFrom` must reduce the allowance as well as the balances.

Explain the solution

Two details people miss: the constructor should emit `Transfer(address(0), msg.sender, totalSupply)` — minting is conventionally a transfer from the zero address, and explorers rely on it. And `transferFrom` decrements the allowance; forgetting that turns a one-time approval into an unlimited one.

Two details almost everyone misses

Minting emits a Transfer from the zero address. Nothing enforces it, but every explorer and wallet builds its picture of a token from Transfer events. Skip it at mint time and your initial supply appears to come from nowhere — which usually reads as a scam.

decimals is display-only. The contract stores plain integers. decimals = 18 is a note to interfaces saying "put the point 18 digits from the right". The contract never divides by anything.

Predict

USDC uses 6 decimals, not 18. What does a balance of 1000000 mean?

1 USDC1,000,000 USDC0.000001 USDC

Check

What makes a contract an ERC-20 token?

Exposing the standard's functions and events — nothing registers or certifies itInheriting from OpenZeppelin's ERC20Being registered with the Ethereum Foundation

Worth remembering

ERC-20 is six functions and two events — an interoperability agreement, not code.
Nothing registers or certifies a token; matching the interface is sufficient.
Minting should emit `Transfer` from the zero address, because explorers build history from events.
`decimals` is display metadata; the contract only ever stores integers.
Never assume 18 decimals — USDC uses 6.