ERC-20
ERC-20 is a technical standard used for creating fungible tokens on the Ethereum blockchain, defining a common set of rules for token behavior.
The ERC-20 standard, formally EIP-20, is a widely adopted technical specification for fungible tokens on the Ethereum blockchain. It defines a common interface for smart contracts to implement, enabling interoperability and standardization across the Ethereum ecosystem. The core of the ERC-20 standard comprises six mandatory functions: totalSupply, which returns the total number of tokens in existence; balanceOf(address _owner), which returns the token balance of a specific address; transfer(address _to, uint256 _value), which sends a specified amount of tokens to another address; transferFrom(address _from, address _to, uint256 _value), which allows a pre-approved spender to transfer tokens on behalf of the owner; approve(address _spender, uint256 _value), which allows an owner to delegate a certain amount of tokens to a spender; and allowance(address _owner, address _spender), which returns the remaining amount of tokens that the spender is allowed to withdraw from the owner. Additionally, it includes two optional but highly recommended events: Transfer and Approval, which log token transfers and approvals, respectively. The primary benefit of ERC-20 is its standardization, allowing wallets, exchanges, and other dApps to easily integrate and interact with any ERC-20 compliant token without needing custom code for each one. This fungibility means each token is identical and interchangeable, similar to traditional currency. However, the standard itself does not inherently provide features like burning, minting, or pausing, which must be implemented by the token contract developer. Trade-offs include the potential for reentrancy attacks if transfer and transferFrom are not implemented carefully, and the fixed nature of the standard, requiring new EIPs for enhanced functionality.
graph LR
Center["ERC-20"]:::main
Pre_smart_contract["smart-contract"]:::pre --> Center
click Pre_smart_contract "/terms/smart-contract"
Pre_ethereum["ethereum"]:::pre --> Center
click Pre_ethereum "/terms/ethereum"
Pre_token["token"]:::pre --> Center
click Pre_token "/terms/token"
Center --> Child_stablecoin["stablecoin"]:::child
click Child_stablecoin "/terms/stablecoin"
Center --> Child_governance_token["governance-token"]:::child
click Child_governance_token "/terms/governance-token"
Rel_erc_721["erc-721"]:::related -.-> Center
click Rel_erc_721 "/terms/erc-721"
Rel_erc_1155["erc-1155"]:::related -.-> Center
click Rel_erc_1155 "/terms/erc-1155"
Rel_eips["eips"]:::related -.-> Center
click Rel_eips "/terms/eips"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 Explain Like I'm 5
Think of ERC-20 like a universal remote control for digital money on [Ethereum](/en/terms/ethereum). It makes sure all digital coins work the same way so your [wallet](/en/terms/wallet) and other apps know how to send, receive, and check balances without needing special instructions for each coin.
🤓 Expert Deep Dive
The ERC-20 standard, codified in EIP-20, provides a foundational interface for fungible tokens on Ethereum. Its design prioritizes simplicity and broad compatibility, defining a minimal set of functions and events. The approve and transferFrom pattern is crucial for enabling decentralized exchanges (DEXs) and other protocols to act as token custodians without requiring direct token ownership. This pattern, however, introduces a potential attack vector: reentrancy. If a malicious contract calls back into the token contract after a transferFrom but before the balance is updated, it could potentially drain more tokens than intended. Robust implementations mitigate this through checks-effects-interactions pattern or reentrancy guards. The standard's fungibility implies that all token instances are identical, simplifying supply management but limiting expressiveness for unique digital assets. The absence of built-in minting or burning mechanisms means these functionalities must be explicitly coded into the contract, often leading to variations like MintableToken or BurnableToken contracts, which themselves can introduce additional security considerations.