What Is an ERC-20 Token?

In brief

ERC-20, standardized as EIP-20, defines an interface for fungible-token contracts. The core interface has six methods:

• totalSupply()
• balanceOf(owner)
• transfer(to, value)
• transferFrom(from, to, value)
• approve(spender, value)
• allowance(owner, spender)

It also specifies Transfer and Approval events. By contrast, name(), symbol(), and decimals() are explicitly optional. permit(), minting, burning, pausing, blacklisting, fees, and administrator controls are not required by ERC-20.

ERC-20 methods that return bool may return false; EIP-20 tells callers that they must handle it rather than assume failure always reverts. Real deployed tokens also include legacy and non-standard behavior, so “widely integrated” is not proof of exact compliance.

What the standard guarantees—and what it does not

EIP-20 standardizes an API, not one storage layout or monetary policy. A typical implementation maintains:

• an address-to-balance mapping;
• an owner-and-spender allowance mapping;
• a total-supply value.

The standard does not require those exact Solidity variables. A proxy, rebasing design, or other implementation can calculate values differently while exposing the interface.

totalSupply() reports token supply according to the contract. balanceOf(owner) reports raw base units assigned to an address. transfer(to, value) requests a transfer from the caller, while transferFrom(from, to, value) lets an authorized caller transfer from another address.

EIP-20 specifies boolean return values for transfer and approval methods. Integrators must check return data and accommodate known token quirks deliberately; silently treating every call that did not revert as success is unsafe.

Events are part of the interface

A successful transfer or transferFrom must emit Transfer, including when value is zero. The standard says token creation should emit Transfer from the zero address; that mint event is a recommendation, not a blanket MUST.

A successful approve call must emit Approval. EIP-20 does not require transferFrom itself to emit a new Approval event when an implementation reduces allowance. Indexers therefore should not invent a stronger event guarantee than the standard provides.

Events are logs for off-chain consumers; they do not replace contract state. A wallet should ultimately read balanceOf and allowance when it needs the current on-chain value.

Optional metadata and decimals

name(), symbol(), and decimals() are optional usability methods. Interfaces and contracts must not require them to exist. Even when present, names and symbols are not unique: anyone can deploy a token using a familiar label.

decimals() is a display convention. If it returns 6, a raw amount of 1_000_000 is commonly shown as 1.000000. The contract still transfers integers in base units. The standard does not require 18 decimals, does not impose a maximum supply based on decimals, and does not make fractional arithmetic happen inside the token.

A token’s identity is anchored to its chain and contract address, not its ticker alone. The same address on another chain is a different execution context, and a bridged representation is not automatically the native issuer’s contract.

Allowances: approval is spend authority

approve(spender, value) sets the amount that spender may withdraw from the caller’s tokens through transferFrom. Calling approve again overwrites the current allowance; it does not add to it.

This creates the classic non-zero-to-non-zero allowance race. If an owner tries to change an allowance from N to M, a spender watching pending transactions may spend N before the replacement confirms and later have M available. EIP-20 tells clients to set the allowance to zero before setting another non-zero amount, while explicitly saying the contract should not enforce that sequence for backward compatibility.

Zero-first is a UI mitigation, not time travel. It cannot stop a spender from using the old allowance before the zeroing transaction confirms. Users should treat an outstanding allowance as live until confirmed on-chain and should review the spender, token, amount, chain, and transaction ordering.

Some contracts treat the maximum uint256 value as an “infinite” allowance, and common implementations may avoid decrementing it. That convention is not a requirement of EIP-20. The separate Token approvals article should own revocation workflows and wallet-security advice.

permit and callbacks are separate standards

ERC-2612 adds permit, allowing an allowance change authorized by an EIP-712 signature. It is optional and does not make every ERC-20 support gasless approval. ERC-2612 also states that the ordinary ERC-20 approval race applies to permit.

Pure ERC-20 has no mandatory receiver callback. A transfer to a contract can succeed even when that contract has no function capable of using or returning the tokens, leaving them stuck. ERC-1363 defines optional transfer-and-call and approval-and-call interfaces, but those methods are additions rather than hidden ERC-20 requirements.

ETH, WETH, and other chains

ETH lives in Ethereum’s native account balance field. It has no ERC-20 contract and cannot be approved with EIP-20’s approve. WETH is a contract-backed ERC-20 representation created by depositing ETH and destroyed by withdrawing ETH; its exact implementation is separate from the ERC-20 interface.

On EVM-compatible chains, ERC-20 contracts can expose the same API, but the chain, contract address, bridge path, and issuer still determine asset identity. Solana tokens use shared Token Programs, mint accounts, and token accounts. Solana delegates are account-scoped permissions under that model, not an ERC-20 allowance mapping.