ERC-20: The Standard That Powers Most Crypto Tokens

2025.11.21 · 6 min read

ERC-20 is a technical standard that defines how tokens behave on Ethereum. It specifies a common interface so that any wallet, exchange, or smart contract can interact with any ERC-20 token without custom integration code.

This post covers what ERC-20 requires, how each function and event works, the approve-and-transfer pattern used in DeFi, and the known weaknesses of the standard.

What ERC-20 Actually Is

ERC stands for "Ethereum Request for Comments". ERC-20 was proposed in November 2015 by Fabian Vogelsteller. Before this standard existed, every token on Ethereum had different function names and different behavior. Wallets and exchanges had to write custom code for each token they wanted to support. That was not scalable.

ERC-20 solved this by defining a minimal, shared interface. Any contract that implements the six required functions and two required events is an ERC-20 token. That is the entire requirement. The standard says nothing about what the token represents, who can hold it, or how it is created.

Today, the most widely used tokens on Ethereum follow this standard: USDT, USDC, LINK, UNI, and thousands of others.

The Six Required Functions

`totalSupply()`

Returns the total number of tokens that exist.

1function totalSupply() public view returns (uint256)

If a token launched with 1 million tokens, this returns 1000000000000000000000000 (accounting for 18 decimals). More on decimals below.

`balanceOf(address)`

Returns the number of tokens held by a specific address.

1function balanceOf(address account) public view returns (uint256)

This is how wallets display your token balance. Every balance query goes through this function.

`transfer(address, uint256)`

Sends tokens from the caller's address to another address.

1function transfer(address recipient, uint256 amount) public returns (bool)

The function must return true on success. It must revert (or return false) if the caller does not have enough tokens. It must also emit a Transfer event.

`approve(address, uint256)`

Authorizes another address to spend tokens on your behalf, up to a specified amount.

1function approve(address spender, uint256 amount) public returns (bool)

This is the first step in the delegated transfer pattern used across DeFi. You are not moving tokens here. You are setting a permission. The actual transfer happens later.

`allowance(address, address)`

Returns how many tokens a spender is still allowed to move on behalf of an owner.

1function allowance(address owner, address spender) public view returns (uint256)

After you approve a spender for 100 tokens and they transfer 40, allowance(yourAddress, spenderAddress) returns 60.

`transferFrom(address, address, uint256)`

Transfers tokens from one address to another, using an existing allowance.

1function transferFrom(address sender, address recipient, uint256 amount) public returns (bool)

The caller of this function must have an allowance from sender that covers amount. This is what a DEX or lending protocol calls after you have approved it.

The Two Required Events

Events let off-chain applications track what happens on-chain without polling the blockchain constantly.

`Transfer`

Emitted whenever tokens move between addresses.

1event Transfer(address indexed from, address indexed to, uint256 value)

When new tokens are minted, from is the zero address. When tokens are burned, to is the zero address. This convention lets indexers detect minting and burning without additional logic.

`Approval`

Emitted whenever approve() is called.

1event Approval(address indexed owner, address indexed spender, uint256 value)

A Minimal Working Implementation

Here is a complete ERC-20 implementation with no external dependencies:

 1// SPDX-License-Identifier: MIT
 2pragma solidity ^0.8.0;
 3
 4contract SimpleToken {
 5    string public name = "Simple Token";
 6    string public symbol = "SMP";
 7    uint8 public decimals = 18;
 8    uint256 private _totalSupply;
 9
10    mapping(address => uint256) private _balances;
11    mapping(address => mapping(address => uint256)) private _allowances;
12
13    event Transfer(address indexed from, address indexed to, uint256 value);
14    event Approval(address indexed owner, address indexed spender, uint256 value);
15
16    constructor(uint256 initialSupply) {
17        _totalSupply = initialSupply;
18        _balances[msg.sender] = initialSupply;
19        // Mint event: from is zero address
20        emit Transfer(address(0), msg.sender, initialSupply);
21    }
22
23    function totalSupply() public view returns (uint256) {
24        return _totalSupply;
25    }
26
27    function balanceOf(address account) public view returns (uint256) {
28        return _balances[account];
29    }
30
31    function transfer(address recipient, uint256 amount) public returns (bool) {
32        require(_balances[msg.sender] >= amount, "Insufficient balance");
33        _balances[msg.sender] -= amount;
34        _balances[recipient] += amount;
35        emit Transfer(msg.sender, recipient, amount);
36        return true;
37    }
38
39    function approve(address spender, uint256 amount) public returns (bool) {
40        _allowances[msg.sender][spender] = amount;
41        emit Approval(msg.sender, spender, amount);
42        return true;
43    }
44
45    function allowance(address owner, address spender) public view returns (uint256) {
46        return _allowances[owner][spender];
47    }
48
49    function transferFrom(
50        address sender,
51        address recipient,
52        uint256 amount
53    ) public returns (bool) {
54        require(_balances[sender] >= amount, "Insufficient balance");
55        require(_allowances[sender][msg.sender] >= amount, "Allowance exceeded");
56
57        _balances[sender] -= amount;
58        _balances[recipient] += amount;
59        _allowances[sender][msg.sender] -= amount;
60
61        emit Transfer(sender, recipient, amount);
62        return true;
63    }
64}

This contract is functional but not production-ready. For real deployments, use a battle-tested implementation like OpenZeppelin's ERC20.sol, which handles edge cases this example skips.

Optional Metadata Functions

The standard does not require these, but nearly every token includes them:

1function name() public view returns (string memory)
2function symbol() public view returns (string memory)
3function decimals() public view returns (uint8)

The decimals value is important. Most tokens use 18, matching Ether. This means that 1 token in human terms is stored as 1000000000000000000 in the contract. When you send 1.5 SMP, you are actually passing 1500000000000000000 to transfer(). Your wallet handles this conversion so you do not have to.

Some tokens use different values. USDC uses 6 decimals. This is a design choice, not a mistake.

The Approve-TransferFrom Pattern

This two-step flow is used in every major DeFi protocol.

Step 1: You call approve(dexAddress, amount) on the token contract. This sets an allowance.

Step 2: The DEX calls transferFrom(yourAddress, poolAddress, amount) when you execute a trade.

Why two steps? Because the token contract must be the one to move funds. The DEX cannot take your tokens without your prior authorization. The approve step is that authorization.

In practice, many wallets prompt you to approve an unlimited amount (type(uint256).max) so you only pay the gas cost once. This is a UX tradeoff with real security implications: if the spender contract is ever exploited, all your approved tokens are at risk.

Minting and Burning

These operations are not in the ERC-20 standard, but most real tokens need them.

 1function mint(address account, uint256 amount) public onlyOwner {
 2    _totalSupply += amount;
 3    _balances[account] += amount;
 4    // from = zero address signals a mint
 5    emit Transfer(address(0), account, amount);
 6}
 7
 8function burn(uint256 amount) public {
 9    require(_balances[msg.sender] >= amount, "Insufficient balance");
10    _balances[msg.sender] -= amount;
11    _totalSupply -= amount;
12    // to = zero address signals a burn
13    emit Transfer(msg.sender, address(0), amount);
14}

The convention of emitting Transfer with the zero address is not in the spec, but it is universally followed. Indexers and block explorers rely on it to correctly display total supply changes.

Known Weaknesses

The Approval Race Condition

Suppose you have approved a spender for 100 tokens. You then call approve() again to change it to 50. There is a window between your first transaction and the second where a watching spender can front-run you: spend the original 100 before the new approval lands, then spend 50 more after. Total damage: 150 tokens.

The safe mitigation is to set the allowance to 0 first, then set it to the new value in a second transaction.

1approve(spenderAddress, 0);      // First transaction
2approve(spenderAddress, 50);     // Second transaction

Some protocols add increaseAllowance and decreaseAllowance helpers to make this cleaner, but these are also not part of the standard.

Lost Tokens in Contracts

If you send ERC-20 tokens to a contract address that has no code to handle them, those tokens are stuck. The contract does not get notified that it received tokens. It cannot reject them. They are permanently inaccessible.

This is a real problem. Millions of dollars in tokens have been lost this way. ERC-223 and ERC-777 both tried to solve it by adding a callback mechanism, but neither gained the same adoption as ERC-20.

Always verify you are sending tokens to an address that can handle them. Sending ERC-20 tokens to a contract that has no withdrawal function results in permanent loss.

No Transfer Notification

Related to the above: contracts do not know when they receive ERC-20 tokens. If your contract needs to react to incoming tokens (trigger a swap, update accounting), you cannot rely on a callback. You have to build a separate deposit function that calls transferFrom, or instruct users to call a function after transferring.

When ERC-20 Is the Right Choice

ERC-20 is the right choice when you need a fungible token that works everywhere Ethereum infrastructure exists: wallets, DEXs, bridges, lending protocols, and block explorers.

It is not the right choice when you need:

Non-fungible tokens (use ERC-721 or ERC-1155)
Tokens with transfer hooks or callbacks (ERC-777 exists but has known reentrancy risks)
Gas-efficient multi-token contracts (ERC-1155 is better here)

The standard's simplicity is also its main limitation. It does exactly what it specifies, nothing more. Any behavior beyond the six functions and two events is your responsibility to implement correctly.