T9 · ERC Standards

A Real-World Problem

You built a staking pool and wrote “supports any ERC20 token” in its documentation. The core logic is simple:

token.transferFrom(msg.sender, address(this), amount);
shares[msg.sender] += amount;

Three things happen in the first three days after launch.

Day one: someone deposits a major stablecoin. The transaction fails, and the error gives no useful clue. You change no code; another token works.

Day two: someone deposits a token that charges a 3% tax on each transfer. The contract receives 97 but records 100. The pool becomes insolvent immediately, without any alert.

Day three: someone deposits a token whose balances change on their own. A user deposits 100, returns the next day, and withdraws 105. The extra 5 comes out of other users’ shares.

You wrote the same code each time. The standard tells you how to use transferFrom, so why did it still fail?

Thought Experiment

First imagine a world without standards.

Every token creator names actions differently: send, pay, or moveTokens, with arguments in different orders.

To show 100 tokens, a wallet needs 100 adapters. An exchange listing those tokens needs 100 more. A lending protocol needs another 100. The cost is N times M; every new token requires everyone else to change code and release again.

Now introduce a standard: agree that the action is called transfer, its arguments say “to whom” and “how much,” and balanceOf returns a balance.

The cost changes from N times M to N plus M. More importantly, something almost magical becomes possible:

An exchange contract written in 2018 can interact with a token invented in 2025, even though their authors never met and neither side needs an upgrade.

That is composability. It does not mean “more features.” It means you do not need to know the other party when you write your code.

But now comes the real turn in this chapter. Look carefully at what a standard specifies: function names, argument types, and return types. It does not, and cannot, guarantee what the world looks like when a function finishes.

A token can have a perfectly standard transfer signature while deducting a 3% fee, calling a function on the recipient, or doing nothing except emitting an event.

Matching signatures do not guarantee matching behavior. Everything that happened over those three days follows from this one sentence.

Your Decision

How should your staking pool accept tokens? Consider four approaches.

What Happens

Put the four designs beside the three incidents:

Two conclusions follow:

First, a standard gives you an interface, not a guarantee. It lets your code call any token; it does not mean every token can be integrated safely. Callability and trust are different, and a standard supplies only the former.

Second, defenses build on each other. Mature protocols use all three: compatible calls, balance-difference accounting, and an allowlist. Each layer blocks a different problem; omit one and that class of incident remains.

These layers will recur later. The AMM in T19 must account for fee-on-transfer tokens in slippage calculations. The lending protocol in T22 must handle collateral whose balance changes itself. Ten minutes of care here will save confusion across both chapters.

Build a Model

Three Layers of a Standard

A token that “complies with ERC20” makes promises of different strengths at three layers:

Most incidents happen at the second layer: the interface matches, but the semantics do not.

Three Token Standards, Three Jobs

A short memory aid: ERC20 asks “how much,” ERC721 asks “which one,” and ERC1155 asks “how many of which batch.”

Notice the callback when ERC721 or ERC1155 is sent to a contract. It prevents an NFT being sent to a contract that cannot retrieve it, but it also means the recipient gets control during the transfer. This security property matters; T28 explores it.

The Approval Model

A contract cannot reach into your account and take tokens by itself, so ERC20 uses two steps:

Step one  You → token contract: allowance[you][protocol] = 100
Step two  You → protocol: deposit 100 for me
          Protocol → token contract: transferFrom(you, protocol, 100)
          Token contract checks the allowance, reduces it, and transfers

This solves “how can a contract take funds?” while creating three real problems:

1. Two transactions. On first use of a protocol, users sign twice. That is poor UX, and the first transaction is an extra Gas cost.
2. Allowances remain. After use, the approval can still exist. Most wallets default to unlimited allowances, so your wallet may carry dozens of permissions saying some protocol can take all of a given token at any time, even if that protocol is no longer maintained.
3. Changing an allowance has a race. If you change an allowance from 100 to 50, the spender may use 100 before your change lands, then another 50 afterward.

Permit addresses point 1: the user signs an approval message with a nonce and expiry (no transaction or Gas). The protocol includes that signature in its own transaction, and the token verifies it and sets the allowance. Two transactions become one.

The answer to point 2 is a habit, not code: periodically review and revoke approvals you no longer need. T13 walks you through it.

A Minimal ERC20

Here is a standalone implementation of those ideas. It needs no external library and can compile directly:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

contract MiniToken {
    string public name = "Mini";
    string public symbol = "MINI";
    uint8 public decimals = 18;          // Note: 18 is common, not mandatory

    uint256 public totalSupply;
    mapping(address => uint256) public balanceOf;
    mapping(address => mapping(address => uint256)) public allowance;

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

    constructor(uint256 initialSupply) {
        totalSupply = initialSupply;
        balanceOf[msg.sender] = initialSupply;
        // Minting conventionally emits a transfer from the zero address; offchain indexes use it to reconstruct supply
        emit Transfer(address(0), msg.sender, initialSupply);
    }

    function transfer(address to, uint256 value) external returns (bool) {
        _transfer(msg.sender, to, value);
        return true;
    }

    function approve(address spender, uint256 value) external returns (bool) {
        allowance[msg.sender][spender] = value;
        emit Approval(msg.sender, spender, value);
        return true;
    }

    function transferFrom(address from, address to, uint256 value) external returns (bool) {
        uint256 allowed = allowance[from][msg.sender];
        if (allowed != type(uint256).max) {        // Unlimited allowances do not decrease, saving a storage write
            require(allowed >= value, "allowance");
            allowance[from][msg.sender] = allowed - value;
        }
        _transfer(from, to, value);
        return true;
    }

    function _transfer(address from, address to, uint256 value) internal {
        require(to != address(0), "to zero");
        uint256 bal = balanceOf[from];
        require(bal >= value, "balance");
        balanceOf[from] = bal - value;
        balanceOf[to] += value;
        emit Transfer(from, to, value);
    }
}

Pause on three details:

• Minting is represented as “transferring from the zero address,” and burning as “transferring to the zero address.” This is an ecosystem convention, not a compiler requirement. Offchain indexers reconstruct supply from it; break the convention and data platforms may display your token incorrectly.
• Decimals need not be 18. That is simply the common value. Hard-code 18 in your protocol and a token with 6 or 8 decimals will make your calculations wrong by orders of magnitude.
• Unlimited allowances do not decrease. It is a common optimization, but also means “approve once, valid forever.”

What It Is Called

Hands-on

function transfer(address to, uint256 value) external {
    _transfer(msg.sender, to, value);
}

interface IERC20 {
    function transfer(address to, uint256 value) external returns (bool);
    function balanceOf(address account) external view returns (uint256);
}

// Strict version: call according to the declared interface
contract StrictConsumer {
    function push(address token, address to, uint256 value) external {
        require(IERC20(token).transfer(to, value), "transfer failed");
    }
}

// Tolerant version: use a low-level call and inspect return data yourself
contract TolerantConsumer {
    function push(address token, address to, uint256 value) external {
        (bool ok, bytes memory data) = token.call(
            abi.encodeWithSignature("transfer(address,uint256)", to, value)
        );
        // Either no return data, or data decoding to true
        require(ok && (data.length == 0 || abi.decode(data, (bool))), "transfer failed");
    }
}

AI Lab

Step one:
List common nonstandard ERC20 implementations in the real world. For each category explain
which part of the standard it violates, which consumers fail, and how to defend correctly.
Rank the categories by their frequency in practice.

Step two:
For the first category, provide an example you are confident exists on mainnet and explain
how I can verify it myself. If you are uncertain about a specific contract, say so clearly.

Real-World Case

Change One Variable

Takeaway Questions

Chapter Check