ERC-20 is a common interface for tokens within smart contracts on Ethereum. It describes a shared way for applications to request information, such as an account’s token balance, and to interact with token transfers. It is a standard that different token contracts can implement, rather than the name of one particular token.
For someone asking “what is ERC20,” the useful distinction is between a shared interface and the information returned by a particular contract. Two contracts can offer the same methods while reporting different supplies and balances. Understanding that distinction helps you read token information without treating a familiar interface as an endorsement or economic guarantee.
What the ERC-20 interface standardizes
An application programming interface, or API, defines ways for software to interact. ERC-20 gives token applications common method names and specified meanings. For example, an application can request an address’s balance through balanceOf rather than requiring a different balance-reading method for each token.
The EIP-20 specification describes this shared interface and its purpose: allowing tokens to be reused by applications, including wallets and decentralized exchanges. Ethereum’s ERC-20 documentation provides an overview of the methods and events that support this interoperability.
The practical benefit is a common vocabulary for software. That purpose does not establish compatibility with every application, especially where an implementation does not conform to the standard. Nor does recognizing the API establish a token’s market value or the trustworthiness of its implementation. Those conclusions require evidence beyond an interface description.
Total supply and an address’s balance answer different questions
totalSupply() returns the total token supply for the contract being queried. balanceOf(owner) returns the token balance associated with the supplied account address. The first question concerns the token’s overall supply; the second concerns one address within that token contract.
Keep both the contract and the question attached to a number. A result described only as “25 tokens” leaves out whether it represents total supply or an address’s balance. It also leaves out which token contract supplied the result.
The specification calls the result of totalSupply the total token supply. That definition alone does not establish a market valuation or identify a separate circulating-supply measure. Likewise, an address-specific balance is a quantity in the queried contract, rather than a statement about what that quantity is worth.
A hypothetical example: shared methods, different balances
Consider two entirely hypothetical token contracts, A and B, and one hypothetical holder address. Both contracts expose ERC-20 API names. For this teaching example, stipulate the following invented raw quantities:
- Contract A:
totalSupply()returns1000, andbalanceOf(holder)returns10. - Contract B:
totalSupply()returns5000, andbalanceOf(holder)returns25.
The holder address is the same, and the balance method has the same name. Nevertheless, the stipulated balance is 10 in A and 25 in B. The total supplies are separate quantities as well.
This illustrates a deduction from the common API and address-specific balance definitions: a shared way to ask a question does not require different contracts to return the same answer. It also does not combine their answers into one balance. These numbers are invented teaching inputs, with no claim about deployed tokens, prices or safety.
What transfer and its event describe
The specified role of transfer is to transfer the supplied token amount to the supplied destination address. ERC-20 also requires a Transfer event when tokens are transferred. Its declared fields identify a from-address, a to-address and a value.
These elements serve related reading tasks. The method describes the requested operation, while the event provides a structured transfer record. Merely seeing that someone submitted a call does not establish that the specified transfer occurred. Equally, an event alone does not establish implementation honesty, completion of an economic payment obligation or EVM rollback behavior.
Zero-value transfers are explicitly covered. The standard requires them to fire the event. A logical consequence is that the presence of a Transfer event alone does not establish that its value is positive: the value field still matters.
For the broader task of interpreting a transaction record, see how to read an Ethereum transaction in a block explorer. Here, the narrower point is the transfer behavior and event structure that ERC-20 specifies.
Name, symbol and decimals are optional metadata
ERC-20 describes three methods that help present token information. When provided, name() returns the token’s name, symbol() returns its symbol, and decimals() describes the decimal precision used to represent token amounts to people.
All three methods are optional. The specification explicitly says interfaces and other contracts must not expect these values to be present. An explanation of the interface should therefore preserve the possibility that descriptive metadata is unavailable, rather than silently assuming a name, symbol or decimal precision.
From these method definitions, we can also deduce that metadata and balances are distinct information. A name and symbol describe the token; decimals concerns amount representation. None of those answers is itself the address-specific quantity returned by balanceOf.
If your question concerns converting raw quantities into a displayed amount, our guide to ERC-20 decimals and raw units covers that separate calculation. For understanding the interface, the essential point is that representation metadata must remain separate from the balance question.
A checklist for reading an ERC-20 explanation
- Identify the contract. Keep each quantity associated with the token contract being discussed.
- Identify the question. Distinguish the total supply from the balance of a supplied address.
- Separate metadata from quantities. A name, symbol or decimal precision does not answer the holder-balance question.
- Allow for absent metadata. Do not assume the three optional methods are available.
- Read the transfer fields. Keep the from-address, to-address and value together, including the possibility of a zero value.
- Preserve the limits. A common API supports interoperability; its presence alone does not establish universal compatibility, value, implementation honesty or payment completion.
This checklist is for interpreting documentation and educational examples. Applying it does not require sending tokens or signing a wallet request.
Educational material prepared with AI assistance, using the primary documentation linked above. The hypothetical example explains interface behavior and is not a recommendation to transact.