What is ERC-20?
ERC-20 is an interface standard for fungible tokens on Ethereum. It addresses a kind of onchain program responsible for recording balances and handling operations — a token contract. ERC stands for Ethereum Request for Comments, the category for Ethereum's application-layer standards and conventions; 20 is this proposal's number. ERC-20 specifies how a token contract should answer balance and total supply queries, how it should handle transfers and approvals, and which operation records it should emit for applications to read — its events — so that wallets and other applications can connect to different tokens in much the same way.
"Fungible" means that equal amounts of the same token can be exchanged for one another as the contract keeps account of them. One unit recorded by a given contract does not, for example, automatically become a different type because it came from a different address. What ERC-20 standardizes is how those units are operated on, not their price, purpose or trustworthiness.
A shared interface solves differences in integration
If every token contract used different function names and parameters, a wallet would have to learn a new set of query and transfer methods for each token it added, and onchain applications would struggle to reuse existing code.
ERC-20 specifies one set of shared interfaces. A wallet can read balances for different tokens through the same query method, an application can request a transfer as agreed, and data services can read transfer and approval events in a uniform format.
The standard itself does not create a token. A developer still has to write or adopt a specific contract and deploy it to the network. Each contract can record its own supply, account balances and additional rules, so two ERC-20 tokens may use different code and may hold entirely different administrative permissions.
Balances, totals and display units
An ERC-20 contract records token amounts as integers. balanceOf queries the balance of an address, and totalSupply queries the total amount the contract reports.
The decimals you see in an interface usually come from a display rule, not from the contract actually storing a fractional amount. The optional decimals field tells a wallet how many places to shift the integer to the left. If a contract records 1,000,000 of the smallest unit and decimals is 6, an interface normally displays 1 token.
That does not change the onchain amount, and it does not automatically change a token's value. The original standard lists the name field name, the ticker field symbol and the display decimal field decimals as optional information; names and tickers can also be duplicated. Identifying an ERC-20 token reliably requires checking both the network and the contract address, not just an icon or a ticker.
How a direct transfer happens
When a holder transfers tokens from their own balance directly to another address, they usually call transfer, supplying the recipient address and an amount expressed in the smallest unit.
The contract checks its own rules on execution. In the basic case, an insufficient balance causes the operation to fail; an implementation may also add pausing, lists, transfer fees or other restrictions. On success, the contract updates its internal balances and emits a Transfer event, letting wallets, block explorers and data services recognize the change.
The Transfer event is an important clue for reading changes, but the final balance is still determined by contract state. An application also has to confirm that the transaction was successfully written to the correct network, and that the event came from the correct contract address.
Approvals let an application transfer a limited amount on your behalf
ERC-20 also supports a flow of "approve first, then have another address or contract execute". It is commonly used for decentralized trading, lending or other operations where a contract needs to receive tokens.
Three roles are involved:
- the holder owns the tokens and decides whether to approve;
- the approved party can be another address or an onchain application;
- the recipient is the address the tokens are finally transferred to, which can differ from the approved party.
The holder calls approve to set an allowance. allowance queries how much remains; the approved party calls transferFrom to move tokens within what the balance and remaining allowance permit. On a successful approval, the contract emits an Approval event.
An approval does not mean the tokens have already been transferred out, but it leaves room for the approved party to act later. If the allowance is large or is not revoked promptly, then once the approved application has a defect, comes under someone else's control or behaves unexpectedly, it may move tokens out within the approved scope. Users need to check the approved address, the token contract and the allowance, rather than relying on the name shown on an application's page.
What to watch when changing an allowance
The original ERC-20 design allows approve to be called again, overwriting the old allowance with a new figure. If the old allowance has not been used and the holder changes it directly to another non-zero value, the approved party may spend the old allowance before the change transaction takes effect and then continue with the new allowance, together exceeding the new allowance the holder intended to leave in place.
The ERC-20 specification suggests client interfaces first set the allowance for the same approved party to 0 and set the new value only after the zeroing transaction is confirmed. This is a compatibility suggestion about the allowance-change flow; it does not mean every wallet uses the same interaction, and it cannot substitute for judging the approved contract itself.
Revoking an approval usually also means setting the allowance to 0 and submitting an onchain transaction. Merely disconnecting a wallet from a website normally does not automatically change an allowance already written into the token contract.
The shared interface of the base standard
From a user's point of view, the base interfaces fall into three groups:
- queries: reading total supply, an address's balance and the remaining allowance;
- operations: a holder transferring directly, setting an approval, or an approved party transferring on their behalf;
- events: recording successful transfers and approvals so external applications can update their data.
Name, ticker and decimals are optional display information. The standard also requires callers to be able to handle an operation returning false, rather than assuming every call either succeeds or raises an error automatically. In practice, an application has to deal with the various implementations already deployed, not merely check whether a function name exists.
Which capabilities are not part of the base standard
ERC-20 does not uniformly specify how a token should create its initial supply, and it does not require a contract to keep minting or to support destruction. Minting, destruction, pausing, freezing, lists, transaction fees, voting rights, upgrades and administrative roles may each be added separately by a specific implementation, or may not exist at all.
The standard also does not specify:
- whether token supply has an upper limit, and who can change the supply;
- whether a token corresponds to reserves, goods, services or other offchain rights;
- a token's price, liquidity or trading venues;
- whether an administrator can pause, freeze or upgrade the contract;
- whether an identically named token on another network belongs to the same asset arrangement.
Reading totalSupply therefore only gives the total the contract currently reports; on its own it says nothing about whether more will be issued later. Seeing the same symbol likewise cannot prove that two contracts represent the same token.
Token contracts and native ETH
ETH is the native asset of the Ethereum network, used to pay the gas fee the network charges for executing transactions, and it is recorded directly by the protocol. An ERC-20 token instead has a smart contract maintaining its balances and operating rules.
Both can be transferred between addresses, but the call path is not the same. An ordinary ETH transfer does not require calling any ERC-20 contract, and ETH itself is not an ERC-20 token. Some applications use a contract to represent ETH in an ERC-20 form so that it can connect to programs that only accept the ERC-20 interface; that introduces another contract and its rules, so the two records cannot be treated directly as the same object.
Interface compatibility does not mean identical behaviour
"Supporting ERC-20" usually only indicates that a wallet or application can call the base interfaces. A specific token may still behave differently:
- an extra fee is deducted on transfer, so the amount received is lower than the amount entered;
- an administrator can pause transfers, freeze addresses or change the implementation;
- some older contracts do not return results the way an application expects;
- display fields are missing, duplicated or supplied by an untrustworthy source;
- additional logic makes an ordinary transfer fail under particular conditions.
ERC-20 therefore provides a shared language, not uniform business rules. Judging whether a token can be integrated safely requires checking the specific contract address, the code or verification information, the administrative permissions and the actual results of a call.
FAQ
Are all Ethereum tokens ERC-20?
No. Ethereum also has standards for individually numbered tokens and other purposes, and custom interfaces can exist too. ERC-20 mainly serves tokens recorded by amount, where equal units are interchangeable.
Do all tokens use 18 decimals?
No. decimals is an optional display field and different tokens can use different values. An application should read and correctly handle the specific contract's setting before calculating or displaying amounts.
Does disconnecting a wallet from a website revoke an approval?
Usually not. Disconnecting stops the website from continuing to request wallet operations through the current session, but the onchain allowance is still recorded by the token contract. Revoking usually requires changing that allowance to 0 and having the transaction written successfully to the network.
Does receiving an ERC-20 token mean it is genuine?
No. Anyone may deploy a contract with a similar name or ticker. Check the network, the contract address and trustworthy information sources; standard compatibility cannot prove an issuer's identity, reserves or value.
Can other blockchains use this standard directly?
ERC-20 is an Ethereum application-layer standard. Other networks able to run Ethereum-style smart contracts may adopt a similar interface, but contract addresses and state on each network are independent of one another. Moving across chains usually also involves a bridge or a separate issuance arrangement, which the ERC-20 interface does not perform automatically.
Related concepts
Continue with token standard, crypto token, smart contract and gas fee, or return to the Crypto Glossary.
Sources
- ERC-20: Token Standard — basic query, transfer, approval, return value and event requirements.
- Ethereum.org: ERC-20 introduction — the standard's purpose, common functions and how wallets and applications connect to it.
- EIP-1: the purpose and categories of Ethereum Improvement Proposals — what EIP and ERC mean, their scope and the standards process.
© 2025 OKX. Tento článek může být reprodukován nebo šířen jako celek, případně mohou být použity výňatky tohoto článku nepřekračující 100 slov za předpokladu, že se jedná o nekomerční použití. U každé reprodukce či distribuce celého článku musí být viditelně uvedeno: „Tento článek je © 2025 OKX a je použit na základě poskytnutého oprávnění.“ U povolených výňatků musí být uveden název článku a zdroj, a to např. takto: „Název článku, [místo pro jméno autora, je-li k dispozici], © 2025 OKX.” Část obsahu může být generována nástroji umělé inteligence (AI) nebo s jejich asistencí. Z tohoto článku nesmí být vytvářena odvozená díla ani nesmí být používán jiným způsobem.









