ERC-20

ERC-20 is an official Ethereum Request for Comments (ERC) that defines a common set of rules for creating and managing fungible tokens on the Ethereum Virtual Machine (EVM). This standard specifies six mandatory functions—including totalSupply, balanceOf, transfer, transferFrom, approve, and allowance—that a smart contract must implement, ensuring all ERC-20 tokens behave in a predictable way. By providing this universal interface, ERC-20 guarantees that any token, from a stablecoin like USDC to a governance token like Uniswap's UNI, can be seamlessly integrated into wallets, decentralized exchanges (DEXs), and other decentralized applications (dApps) without custom code.

The standard's core innovation is interoperability. Before ERC-20, each token project used a unique smart contract interface, forcing every new wallet or exchange to write custom support for each token. ERC-20 solved this by creating a universal blueprint. This allowed for the explosive growth of the Initial Coin Offering (ICO) era and remains the backbone of the DeFi (Decentralized Finance) ecosystem. Key technical behaviors defined by the standard include how tokens are transferred between addresses, how third-party contracts (like a DEX) can be approved to spend tokens on a user's behalf, and how to query an address's token balance.

While revolutionary, the ERC-20 standard has known limitations that led to the creation of subsequent standards. Notably, it lacks native support for safety features like preventing accidental transfers to non-receiving contracts, an issue addressed by ERC-223 and ERC-777. Furthermore, it cannot handle non-fungible tokens (NFTs), which are governed by standards like ERC-721 and ERC-1155. Despite these newer alternatives, ERC-20's simplicity and first-mover advantage have cemented its position as the most widely adopted token standard, serving as the primary model for fungible digital assets across the entire EVM-compatible blockchain landscape, including Polygon, Avalanche, and BNB Chain.

The term ERC-20 originates from Ethereum Request for Comments 20, a formal proposal submitted to the Ethereum developer community in late 2015 by Fabian Vogelsteller and Vitalik Buterin. The naming follows a convention common in internet engineering, where RFCs (Request for Comments) are documents that describe methods and behaviors for internet standards. In the Ethereum ecosystem, an ERC (Ethereum Request for Comments) serves the same purpose: it is a design document proposing a new feature or standard for the network, open for discussion and refinement by developers before potential adoption.

The number 20 is simply the sequential identifier assigned to this specific proposal. It was not the first token standard proposed—earlier attempts existed—but it was the one that achieved critical consensus due to its elegant simplicity and practical utility. The proposal outlined a minimal, mandatory interface—a set of six functions and two events—that any smart contract must implement to be recognized as a standard fungible token. This included functions like totalSupply(), balanceOf(), and transfer(), which became the universal language for token interactions.

The adoption of ERC-20 was a watershed moment, solving a critical interoperability problem. Before its widespread acceptance, each new token project created its own unique smart contract interface, meaning wallets and exchanges had to write custom code to support each one. By providing a common blueprint, ERC-20 allowed developers to build universal tools—wallets like MetaMask and decentralized exchanges—that could automatically interact with any compliant token, creating a powerful network effect and laying the groundwork for the 2017 Initial Coin Offering (ICO) boom.

The ERC-20 standard is a technical specification, defined by Ethereum Improvement Proposal 20, that establishes a common set of rules for creating fungible tokens on the Ethereum blockchain. These rules are implemented as a set of six mandatory functions and three optional ones within a smart contract. The mandatory functions enable basic token operations: totalSupply() returns the total token count, balanceOf(address) checks a user's holdings, transfer(address, uint256) moves tokens, transferFrom(address, address, uint256) allows delegated transfers, approve(address, uint256) grants spending allowances, and allowance(address, address) checks remaining allowances. This standardization ensures all ERC-20 tokens can interact seamlessly with wallets, exchanges, and other smart contracts.

A core mechanism of ERC-20 is its allowance system, which enables secure, non-custodial interactions with decentralized applications (dApps). Instead of transferring tokens directly to a dApp's contract—a risky operation—a user first approves the contract to spend a specific amount of their tokens. This creates an on-chain allowance. Later, when the user interacts with the dApp, the contract can execute a transferFrom function, moving the approved tokens from the user's wallet to the required destination. This two-step process is fundamental to decentralized exchanges (like Uniswap) and lending protocols (like Aave), where contracts must manage user funds without taking direct custody.

The standard also defines optional metadata functions for name, symbol, and decimals, which provide human-readable information about the token. While seemingly simple, the widespread adoption of ERC-20 has created a highly interoperable ecosystem. Because every wallet and exchange knows how to interact with the standard interface, new tokens are instantly compatible with existing infrastructure. However, the standard has known limitations, such as the inability to handle native asset transfers or non-fungible tokens, leading to the creation of subsequent standards like ERC-777 for enhanced functionality and ERC-1155 for multi-token contracts.

The following is a minimal, non-production-ready example of an ERC-20 token contract written in Solidity. It implements the six mandatory functions and two events specified by EIP-20. The totalSupply variable tracks the fixed number of tokens in existence, while the balanceOf mapping records individual holdings. The transfer, approve, and transferFrom functions enable the core token transfer logic, and the allowance mapping facilitates delegated spending via the approval mechanism.

This contract uses a simplified constructor that mints the entire initial supply to the deploying address. In a real deployment, minting logic is often more complex and may include access controls, vesting schedules, or a minting cap. The Transfer and Approval events are emitted on state changes, allowing external applications like wallets and block explorers to efficiently track token movements and permission updates without scanning all transactions.

To interact with this token, a user would call transfer(recipient, amount) to send tokens from their own balance. For a decentralized exchange or smart contract to move tokens on a user's behalf, the user must first call approve(spender, amount). The spender can then call transferFrom(sender, recipient, amount), provided the approved allowance is sufficient. This two-step pattern is fundamental to DeFi composability, enabling tokens to be used within other protocols.

Developers extending this base implementation must consider critical security practices. These include using the Checks-Effects-Interactions pattern to prevent reentrancy attacks, implementing proper access control for any mint or burn functions, and ensuring arithmetic operations are safe from overflows and underflows (often handled by using Solidity 0.8.x or libraries like OpenZeppelin's SafeMath). The OpenZeppelin Contracts library provides a widely-audited and feature-rich ERC20.sol implementation that serves as the industry standard foundation.

The ERC-20 standard's simplicity, while key to its adoption, created clear limitations that spurred the development of new token standards. Its inability to handle non-fungible assets led to ERC-721, which assigns a unique identifier to each token, enabling digital collectibles and provable ownership of distinct items. For semi-fungible use cases, such as event tickets or in-game items with varying attributes, ERC-1155 emerged as a multi-token standard that can efficiently manage both fungible and non-fungible tokens within a single smart contract, reducing gas costs and complexity for applications like gaming platforms.

To address the static nature of ERC-20 tokens, standards like ERC-777 and ERC-1363 introduced advanced transaction handling. ERC-777 added "hooks" that allow tokens to notify a receiving contract of an incoming transfer, enabling more complex interactions without requiring a separate approve transaction. Similarly, ERC-1363 defines a transferAndCall function, allowing a token transfer to trigger a specific function in a recipient contract atomically. This is crucial for seamless integrations in decentralized finance (DeFi), where a single transaction can deposit tokens into a lending protocol or swap them on a decentralized exchange.

For governance and utility, the ERC-20Votes extension became a critical evolution. It provides a standardized way for ERC-20 tokens to track historical voting power, which is essential for secure, snapshot-based delegated voting in Decentralized Autonomous Organizations (DAOs). This prevents manipulation through "vote dumping" by locking historical balances at the time a proposal is created. Furthermore, standards like ERC-4626 for yield-bearing vaults and ERC-6909 for minimal modular interfaces represent the ongoing specialization of token standards to optimize for specific, high-value use cases in the modern blockchain ecosystem.