ERC-20 is the Ethereum token standard for fungible tokens: a common interface of functions and events that a smart contract implements so that every unit of its token is interchangeable and any wallet, exchange or application can hold, transfer and account for it in the same way. In the area of tokenization & NFTs, ERC-20 is the format behind most stablecoins, governance tokens, utility tokens and many tokenized real-world assets on Ethereum and EVM-compatible chains.
The standard does not define what a token represents or how it is issued. It defines only the minimum interface for balances, transfers and delegated spending, which is why a dollar stablecoin and a game currency can look identical to software while carrying very different rights.
The ERC-20 interface
An ERC-20 contract keeps a mapping of addresses to balances and exposes a fixed set of functions. Six functions are mandatory and three metadata functions are optional, together with two events that let indexers and wallets track movements off-chain.
| Element | Type | Purpose |
|---|---|---|
totalSupply | Function | Returns the number of tokens in existence |
balanceOf | Function | Returns the balance of one address |
transfer | Function | Moves tokens from the caller to a recipient |
approve | Function | Sets an allowance a spender may use |
allowance | Function | Returns the remaining approved amount |
transferFrom | Function | Lets an approved spender move tokens |
name, symbol, decimals | Optional functions | Human-readable metadata |
Transfer, Approval | Events | Logs used by wallets and explorers |
Balances are stored as unsigned 256-bit integers without a decimal point. The decimals value, most often 18, tells software how to display them; a balance of 1,000,000 with six decimals, as used by several dollar stablecoins, means exactly one token.
Allowances and the approve pattern
Smart contracts cannot pull tokens from a user’s address on their own. ERC-20 solves this with the two-step approve and transferFrom flow: the user first approves a contract to spend up to a certain amount, and the contract later calls transferFrom when the user trades, deposits or pays.
This pattern makes DeFi composable, but it also creates the most common user-side risk. Many applications request an unlimited allowance for convenience, so a later bug or a malicious contract can drain the whole balance. Approval phishing and wallet drainers exploit exactly this mechanism.
| Strategy | Advantage | Risk |
|---|---|---|
| Unlimited approval | One transaction, lower total gas | Full balance exposed to the spender |
| Exact-amount approval | Exposure limited to one action | Extra transaction each time |
| Signed permits (EIP-2612) | Approval by signature, no gas | Signature phishing if users sign blindly |
| Revoking old approvals | Removes stale exposure | Costs gas and needs regular attention |
ERC-20 compared with other token standards
ERC-20 is the fungible member of a family of Ethereum token standards. Choosing between them depends on whether each unit must be distinguishable and on how many asset types a single contract should manage.
| Standard | Token type | Typical use |
|---|---|---|
| ERC-20 | Fungible, identical units | Currencies, stablecoins, governance tokens |
| ERC-721 | Non-fungible, unique IDs | NFTs, deeds, collectibles |
| ERC-1155 | Multi-token, fungible and unique | Game items, batched assets |
| ERC-4626 | Tokenized vault shares built on ERC-20 | Yield vaults, lending deposits |
| ERC-3643 | Permissioned ERC-20 with identity checks | Security tokens, regulated RWAs |
Regulated security tokens and tokenized treasuries often extend ERC-20 with transfer restrictions, whitelists and forced transfers so that issuers can meet KYC and securities rules. The result remains ERC-20 compatible for wallets, but transfers can fail for compliance reasons that the base standard does not anticipate.
Known pitfalls of ERC-20
The standard was written early in Ethereum’s history and leaves several behaviors open. Integrators must expect that real tokens deviate from the specification in ways that break naive code.
- Missing return values: some widely used tokens do not return true on transfer, so integrations rely on safe-transfer wrappers.
- Fee-on-transfer and rebasing tokens change balances unexpectedly, which breaks accounting that assumes the amount sent equals the amount received.
- Tokens sent to contracts are often lost, because plain ERC-20 has no hook that lets a receiving contract reject or handle them.
- The approval race condition allows a spender to use both the old and new allowance if an allowance is changed directly from one nonzero value to another.
- Admin functions such as minting, pausing or blacklisting may exist in a token without being visible in the standard interface.
Because the interface says nothing about issuer powers, holders should inspect the verified contract or its audit to see who can mint new supply, freeze addresses or upgrade the code. These powers are normal for regulated stablecoins, yet they are a central trust assumption that the token symbol does not reveal.
Creating and deploying an ERC-20 token
In practice, almost no team writes ERC-20 logic from scratch. Developers inherit an audited reference implementation, set name, symbol, decimals and the initial supply, and add only the features they need, such as capped minting, burning or role-based access.
Deploying the contract costs gas and creates the token instantly; listing it on wallets or exchanges is a separate step. Since anyone can deploy a token with any name, users should verify the contract address, not the ticker, before trading.
The same ERC-20 code can be deployed on many EVM-compatible networks, including layer 2 rollups. A token that exists on several chains is usually a set of separate contracts linked by a bridge or by the issuer’s own mint-and-burn process, so the canonical address differs per network and balances on one chain cannot be spent on another without that link. Every transfer is paid for in the network’s native asset, not in the token itself, which is why a wallet holding only ERC-20 tokens cannot move them without gas.
A plain-language summary
ERC-20 is a shared rulebook for digital coins on Ethereum. Every token that follows it answers the same basic questions in the same way: how many exist, who owns how many, and how they move.
Because of that, a wallet or exchange does not need special code for each new coin. It is similar to how any standard plug fits any standard socket, regardless of which company made the appliance.
An example from practice
A user wants to swap 500 units of a dollar stablecoin for ether on a decentralized exchange. The interface first asks for an approval transaction; the wallet offers an unlimited amount, but the user edits it to exactly 500 tokens before signing.
The swap then runs: the exchange contract calls transferFrom to pull the 500 tokens and sends ether back. A month later, the exchange’s router is found to have a vulnerability. Because the user approved only the exact amount, which was fully used, the remaining stablecoin balance stays safe, while users with unlimited approvals are urged to revoke them immediately.