ERC-20 defines a common interface for token balances, transfers and spending approvals. This standards reference focuses on requirements and integration pitfalls: return values, events, allowance replacement and the boundary between the specification and extensions. For an introduction to fungible tokens and applications, see the ERC-20 glossary entry below. [1]

Last updated: 2026-10-08

The source document

• Title: ERC-20: Token Standard.
• Authors: Fabian Vogelsteller and Vitalik Buterin.
• Created: November 19, 2015.
• Status: Final, checked October 8, 2026.
• Rights: specification copyright and related rights waived through CC0.

This is an Ethereum interface standard, not a token issuer’s whitepaper. Matching function names alone does not establish compliance: return types, authorization rules, effects and events also matter. An implementation’s source-code license is separate from the specification’s rights. [1]

Balances, allowances and actions

The six core methods are totalSupply, balanceOf, transfer, transferFrom, approve and allowance. Supply and balance queries report token quantities. An allowance is permission for a spender to move up to a specified quantity from an owner; granting it does not itself transfer tokens or reserve a balance. transferFrom must be deliberately authorized. [1]

A spender does not receive the owner’s private key. Nevertheless, an approved contract may move funds within its authorization, so retaining the key does not eliminate approval risk. A successful approval transaction is not evidence that the spender is trustworthy.

False returns and zero-value events

The specification requires callers to handle false from methods returning a success boolean. A completed external call must not be treated as proof that the intended transfer occurred. Reverting on failure is another common implementation choice; OpenZeppelin documents that convention for its ERC20 implementation. [1] [3]

Zero-value transfers must behave as normal transfers and emit Transfer. Successful approve calls emit Approval. Token creation should emit Transfer with the zero address as the source. That last statement is a SHOULD in the source, not a universal guarantee that every historical token recorded minting identically. [1]

Integrations should not assume that every allowance change caused by transferFrom emits a new Approval event. OpenZeppelin’s documented implementation omits that event when spending an allowance and treats the maximum uint256 allowance as unlimited. These library conventions are not additional requirements imposed on every ERC-20 contract. [3]

Changing an existing approval

approve(spender, amount) replaces the allowance; it does not add to it. Suppose an owner changes a nonzero allowance from 100 to 50 while a spender can submit transactions. Transaction ordering can allow the old allowance to be spent before the new approval is included. The source recommends that user interfaces first set the allowance to zero before assigning another value. [1]

A zero reset is not a guarantee that the old allowance remains unspent before the reset executes. The final approved amount and spender’s behavior still matter. A signed ERC-2612 permit also sets an allowance: its source explicitly says the ERC-20 approval race still applies. Permit is not a general repair for that problem. [6]

Metadata and integer units

name, symbol and decimals are optional in base ERC-20. Consumers cannot require them merely because a token exposes the core interface. A symbol is a label, not a unique token identifier: the contract address and network identify the asset being used. [1]

Decimals affect presentation rather than on-chain arithmetic. For an illustrative token with two decimals, a raw balance of 505 displays as 5.05 tokens. OpenZeppelin defaults to 18 decimals, but that is not mandatory for all ERC-20 implementations. Assumptions about decimal precision can misprice transfers or balances. [2]

What extensions change

ERC-2612 adds permit, nonces and a domain separator for signed approvals. A relayer can submit a valid permit, but someone still pays transaction gas. Its deadline bounds submission validity; it does not automatically expire an allowance already granted. Implementations named “permit” can also differ from ERC-2612, as the standard’s compatibility discussion explains. [6]

Base ERC-20 transfers do not require a recipient callback. ERC-1363 separately defines transferAndCall, transferFromAndCall and approveAndCall. Sending tokens to a contract that cannot handle or recover them can leave them inaccessible; the outcome depends on that contract. Callback support is not implied by an ERC-20 label. [7]

Libraries and token policy

OpenZeppelin’s SafeERC20 wrapper handles false returns and accommodates some tokens that return no value on successful calls. That is compatibility handling, not proof that every such token follows the exact base specification or is economically safe. [4]

ERC-20 does not prescribe a supply cap, minting schedule, redemption right, governance design or upgrade policy. OpenZeppelin’s supply guide treats issuance as separate custom logic. The shared interface reduces integration work; deployed behavior, permissions and extensions still need individual review. No exchange listing or investment return follows from interface compliance. [5]

Social Media Sentiment

Not applicable to this standards reference. No current token count, popularity ranking or community mood is inferred from the interface.

Last updated: 2026-10

Related Terms

• ERC-20 — the broader glossary introduction.
• Token — a digital asset represented by a contract or ledger.
• Smart Contract — code implementing the token’s rules.

See Also

• ERC-4626 standard reference — additional obligations for tokenized vault shares.
• ERC-721 — a different interface for individually identified tokens.

Sources

1. Vogelsteller and Buterin — ERC-20: Token Standard (2015). The Final specification defines required semantics, events, optional metadata, allowance replacement and CC0 rights.
2. OpenZeppelin Contracts 5.x — ERC-20 guide. The guide explains integer amounts, display decimals and a concrete implementation example.
3. OpenZeppelin Contracts 5.x — ERC20 API reference. The reference distinguishes library behavior and extensions, including revert-on-failure and unlimited allowances.
4. OpenZeppelin — SafeERC20 Solidity source. The MIT-licensed wrapper handles false-returning and certain non-returning token implementations.
5. OpenZeppelin — Creating ERC-20 Supply. The guide explains that issuance policy is separate from the standard interface.
6. Lundfall — ERC-2612: Permit Extension for EIP-20 Signed Approvals (2020). Permit adds signed approvals, nonces and deadlines; its security section says the allowance race still applies.
7. Minacori — ERC-1363: Payable Token (2018). The separate extension adds transfer and approval callbacks absent from base ERC-20.