What Is ERC20? How Ethereum's Token Standard Actually Works

If you have ever held a token on Ethereum, you have almost certainly held an ERC20 token, even if the name on the wallet screen was USDC, LINK, UNI or WBTC. The label describes a contract interface rather than a brand, and that interface is the main reason a single wallet can display thousands of different assets without being rebuilt for each one.

This guide covers what the standard actually specifies, how the allowance system works, and the places where a token that looks perfectly standard can still behave in ways your tools do not expect.

A Specification, Not a Coin

ERC20 is not a network, a company or a piece of software you install. It is a written specification, EIP-20, that describes how a fungible token contract on Ethereum should behave. Fabian Vogelsteller and Vitalik Buterin proposed it in November 2015, and the proposal reached final status in 2017.

Fungible means one unit is interchangeable with any other unit, the way one euro equals another euro. A token contract keeps a ledger of balances inside its own storage and exposes a small set of functions that let outsiders read and move those balances.

The key point is that the specification says nothing about what the token is worth, who controls it, or whether it can be paused, frozen or taxed. It only describes the vocabulary a contract must speak so other software can talk to it. So what is an ERC20 token beyond that vocabulary? A contract that stores balances and follows the shared rules, with everything else left to whoever wrote it.

The Functions Every ERC20 Token Must Implement

The standard requires six functions and two events. Anything beyond that is optional.

• totalSupply() returns how many units exist.
• balanceOf(address) returns the balance held by one address.
• transfer(to, amount) moves units from the caller to another address.
• transferFrom(from, to, amount) moves units on behalf of someone else, provided an allowance exists.
• approve(spender, amount) grants another address permission to spend up to a limit.
• allowance(owner, spender) reports how much of that permission remains.

The two required events are Transfer, emitted on every movement of units, and Approval, emitted when an allowance changes. Block explorers, indexers and wallets rely on those events to reconstruct history, which is why a token that moves balances without emitting Transfer will appear broken in most software even though the chain state is correct.

Metadata such as name, symbol and decimals is optional, and that optional status matters more than it sounds. Almost every token uses 18 decimals to mirror ether's smallest unit, but the number is a convention, not a rule. USDC uses 6. A wallet or exchange that hardcodes 18 will display a 6-decimal token with the wrong magnitude, so the display bug is common enough to be a standing support topic.

Why Such a Small Interface Changed Everything

Before the standard existed, each token contract had its own design. An exchange that wanted to list a new token wrote custom integration code, and every wallet had to do the same. Adding the twentieth token meant twenty integrations.

With a shared interface, one integration covers every compliant token, including ones that did not exist when the integration was written. That is the whole trick, and it explains why token launches became routine rather than an engineering project.

It also explains a limitation people discover later: the interface describes how to move tokens, not how they behave. Two contracts can both answer every required call correctly and still differ wildly in what happens underneath. Transfers can be taxed, frozen, capped or redirected, and the standard has no opinion on any of it.

The Approval Pattern, and Why It Deserves Attention

The approve and transferFrom pair exists because a smart contract cannot sign a transaction on your behalf. When you trade on a decentralised exchange, the exchange contract needs permission to pull tokens from your address. You grant that permission once with approve, and the exchange calls transferFrom each time it executes a trade.

This design is efficient and it is also the source of the most common security mistake in decentralised finance: approving an unlimited amount to a contract you have not verified. An unlimited allowance does not move anything by itself, but it stays in place until you revoke it, and any bug or exploit in the approved contract can use it.

Two further details are worth knowing. First, the naive version of approve has a race condition: if you change an allowance from 100 to 50 while a spender is mid-transaction, the spender may be able to use both the old and the new amount. Tokens therefore often add increaseAllowance and decreaseAllowance helpers, which were never part of the original specification. Second, a later proposal, EIP-2612, adds a permit function so that approvals can be signed off-chain and submitted by someone else, saving a transaction. Useful, but again not ERC20 itself.

Where a Compliant Token Still Surprises You

The most practical thing to understand about ERC20 is that compliance is shallow. Several widely used tokens bend assumptions that integrators make.

Fee-on-transfer tokens deduct a cut during the transfer, so the receiver gets less than the sender specified. Code that records the requested amount instead of measuring the actual balance change will drift out of sync with reality.

Rebasing tokens change every holder's balance without any transfer occurring. A wallet showing a constant balance is not necessarily wrong; the balance itself moved.

Some early tokens, Tether's original implementation among them, return no value from transfer and approve where the specification expects a boolean. Strict contracts that check the return value treat a successful transfer as a failure. Libraries such as OpenZeppelin's SafeERC20 exist largely to absorb that inconsistency.

Tokens with blacklists, pause switches or transfer limits can reject a transfer that every signature and balance check said should succeed. None of these are exotic; they are standard features of regulated stablecoins and of tokens with upgradeable contracts.

ERC20 Compared With Other Token Standards

ERC20 handles fungible tokens only. When Ethereum needed unique tokens, the network adopted ERC721, where each token id is distinct and ownership is tracked individually. ERC1155 combines both ideas by tracking many token types, fungible or not, inside one contract, which is why game items and mixed collections tend to use it.

A newer addition, ERC4626, standardises tokenised vaults: a contract that holds assets and issues shares representing a claim on them. Its shares are themselves ERC20 tokens, so the older standard still sits underneath the newer one. Each of these specifications follows the same pattern, defining a small vocabulary so that wallets and aggregators can support new contracts without bespoke work.

How to Check a Token Before You Trust It

Token names and symbols are not unique, and anyone can deploy a contract called USDC tomorrow. The reliable check is the contract address, confirmed against the project's own documentation or a reputable explorer.

On the contract page, look for the read and write function tabs. A genuine ERC20 token exposes totalSupply, balanceOf, decimals and the rest. Verified source code is a good sign, though many tokens use proxy contracts, where the logic lives at a separate implementation address and the proxy can be upgraded later. Upgradeability is not inherently bad, but it means the rules you read today can change.

One more caution: tokens that arrive in your wallet without your involvement are usually worthless, and interacting with their contracts can be risky. They exist to get your attention, not to give you value.

What This Means in Practice

For a holder, the standard delivers a quiet benefit: every token lives in the same place, moves the same way and shows up in the same list. Sending a token costs network fees just like sending ether, which is worth understanding before you move small amounts during a busy period.

For anyone building or trading, the lesson is to treat ERC20 as a starting point for verification rather than a guarantee. Check the allowance you are granting, confirm the decimals on an unfamiliar asset, and remember that a token contract is code with an owner, not a fixed law of nature.

That is the honest summary of what ERC20 is: a small, unglamorous agreement about function names that made an entire ecosystem composable. Its limits come from the same place as its success, because a standard broad enough to fit thousands of projects cannot also promise that each one behaves the way you hope.