Skip to content
Financial Context Wiki

ERC-20

ERC-20 is Ethereum's standard interface for fungible tokens. Learn how balances, transfers, allowances, and approvals work, and what the standard does not guarantee.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

ERC-20 is a standard interface for fungible-token contracts on Ethereum. It lets wallets, exchanges, and decentralized applications use the same calls to read a supply or balance, transfer tokens, and authorize another address to spend a limited amount. Fungible means that equal units of the same token are intended to be interchangeable.

The core interface includes:

  • totalSupply and balanceOf for reading supply and account balances;
  • transfer for sending the caller’s tokens;
  • approve and allowance for setting and reading a spender’s limit;
  • transferFrom for spending from an owner’s balance within that limit; and
  • Transfer and Approval events for recording transfers and approvals.

The standard defines interoperability, not asset quality. ERC-20 compliance does not guarantee a fixed supply, a fair market value, redeemability, liquidity, secure administration, or even identical behavior across implementations.

How it works

An ERC-20 balance is an entry in the token contract’s state, associated with an address. A wallet displays that state; it does not hold a separate token file. When transfer(to, amount) succeeds, the contract reduces the caller’s balance, increases the recipient’s balance, and emits a Transfer event. The user normally pays network gas in ETH. If execution reverts, the token-state changes are undone, but gas already consumed is not refunded in full.

Delegated spending uses an allowance. Calling approve(spender, amount) sets how much that spender may use from the caller’s balance. The spender can then call transferFrom(owner, to, amount), and allowance(owner, spender) reports the remaining limit. An approval belongs to one owner-spender pair in one token contract on one network; it is not permission over every asset in the wallet.

Calling approve again overwrites the previous allowance. The EIP-20 specification warns user interfaces to set an existing allowance to 0 before setting a different nonzero value because transaction ordering can otherwise let a spender use both the old and new limits. Setting an allowance to 0 can stop future transferFrom calls for that owner-spender-token combination, but it cannot recover tokens already transferred.

name, symbol, and decimals are optional metadata methods in EIP-20. decimals affects display units, not the contract’s integer accounting. The standard also does not prescribe how tokens are minted or burned, whether transfers can be paused or taxed, whether addresses can be frozen, or whether proxy logic can be upgraded. Those behaviors must be checked in the deployed code, current implementation, and administrative permissions.

Example

Suppose a wallet holds 1,000 units of an ERC-20 token and a user wants a decentralized-exchange router to swap 100. The user first submits approve(router, 100). If it succeeds, the router may call transferFrom(user, pool, 100); after a full spend, the ordinary remaining allowance is 0. The approval transaction and the swap transaction are separate on-chain actions, so each can require gas and either can fail independently.

Approving the maximum possible value can avoid repeated approvals, but it leaves a larger amount exposed for longer if the router, its upgrade authority, or the interface used to obtain the approval is compromised. A limited allowance narrows that exposure, although it does not remove smart-contract, token-price, liquidity, or transaction risks.

Risks

  • Wrong contract or network: names, symbols, and icons can be copied; verify the contract address on the intended network.
  • Excessive allowance: a malicious or compromised spender may use an unused allowance up to the approved limit.
  • Nonstandard behavior: some widely used tokens do not return values exactly as expected, while others charge transfer fees, rebase balances, block addresses, or pause transfers.
  • Administrative control: minting, freezing, upgrades, or other privileged actions may change the token’s risk after a user acquires it.
  • Irrecoverable transfer: sending tokens to the wrong address or to a contract that cannot handle them may make recovery impossible.

ERC-20 standardization reduces integration friction; it does not remove contract, issuer, custody, market, or operational risk. Before signing, check the network, token contract, spender address, approval amount, and transaction call.

Common misconceptions

Myth 1: An ERC-20 label proves that a token is legitimate

Anyone can deploy a contract with a familiar name or symbol. The label only describes an interface claim. Verify the contract address and then assess the code, permissions, issuer, liquidity, and market separately.

Myth 2: An approval immediately transfers the approved tokens

approve normally changes an allowance; it does not itself move tokens to the spender. The later transferFrom call moves them. Nevertheless, an outstanding allowance is a real permission that can remain usable until it is spent, replaced, or set to 0.

Myth 3: Every ERC-20 token behaves identically

The standard specifies a minimum common interface. It does not require a particular supply policy or forbid fees, pausing, blacklists, rebasing, or upgradeability. Integrations must account for the actual implementation rather than relying only on the ERC-20 label.

Sources

Navigation

Search the wiki...