What Is an ERC-20 Token: Complete Guide to Ethereum's Token Standard (2026)

If you have ever held a token on Ethereum, traded on a decentralized exchange, used a stablecoin like USDC, or interacted with a DeFi protocol, you have used an ERC-20 token. This single standard powers the vast majority of all crypto assets that are not native blockchain coins. From Tether and Chainlink to Uniswap and Shiba Inu, almost every token you can name on Ethereum follows the same set of rules: the ERC-20 specification.

ERC-20 is a technical standard that defines how a fungible token must behave inside a smart contract on Ethereum. It tells every wallet, exchange, and DeFi protocol exactly which functions a token must expose, which events it must emit, and how transfers must work. This predictability is the reason MetaMask can show you any token balance, why Uniswap can list a new token in minutes, and why developers can build complex financial primitives on top of any compliant asset without writing custom integration code.

In this guide you will learn what ERC-20 actually is at a technical level, the difference between mandatory and optional functions, the famous approve and transferFrom pattern that powers DeFi, how to identify an ERC-20 contract on Etherscan, how to compare it with other token standards like ERC-721 and ERC-1155, how to add custom tokens to MetaMask, and what risks you should be aware of when granting approvals. By the end you will understand the standard well enough to read a token contract, evaluate its safety, and use it confidently across the entire Ethereum ecosystem in 2026.

What Is an ERC-20 Token

ERC-20 stands for Ethereum Request for Comments, number 20. It was proposed by developer Fabian Vogelsteller in November 2015 as a way to standardize how tokens behave on Ethereum. Before ERC-20 existed, every token on Ethereum was implemented differently, which meant wallets, exchanges, and other contracts had to write custom code to interact with each one. The result was fragmentation, bugs, and a major barrier to interoperability.

Vogelsteller's proposal eventually became EIP-20 (Ethereum Improvement Proposal 20) and was finalized in September 2017. The "ERC" name stuck even though the formal designation is EIP-20. The standard is intentionally minimal. It defines a set of functions and events that any fungible token contract must implement, but leaves the underlying logic up to the developer. This means an ERC-20 token can have a fixed supply, a mintable supply, burning mechanics, taxes on transfers, or any other custom behavior, as long as it exposes the standard interface.

At its core, an ERC-20 contract is essentially a smart contract that maintains a ledger of balances. Inside the contract there is a mapping (a key-value table) that stores how many tokens each address owns. When you "send" an ERC-20 token to someone, you are not actually transferring any object. You are calling a function on the token contract that decreases your balance by some amount and increases the recipient's balance by the same amount. The token never leaves the contract. The contract simply updates its internal ledger.

This is a fundamental concept to understand. Unlike coins like ETH or BTC, ERC-20 tokens are not stored in your wallet in any meaningful sense. Your wallet simply tracks which token contracts have recorded your address as having a balance. If a token contract were destroyed (which is possible with certain admin functions), your tokens would effectively vanish, even though your private key remains valid.

Why a Token Standard Matters

The reason ERC-20 became one of the most important standards in crypto history is interoperability. Because every compliant token exposes the same six functions and emits the same two events, any wallet, exchange, oracle, indexer, or DeFi protocol can interact with any ERC-20 token without needing prior knowledge of that token. Uniswap does not need to know what a specific token does internally. It only needs to know the contract address, and it can immediately call transferFrom() to move tokens during a swap.

This standardization is what enabled the explosion of decentralized finance starting in 2020. Lending protocols like Aave and Compound work with thousands of different tokens because they all behave the same way at the interface level. Tokenomics and economic experiments became cheap to run, because deploying a new token only requires copying battle-tested code. Block explorers, portfolio trackers, tax software, and analytics dashboards can all index any ERC-20 token automatically by listening to the same standardized events.

Without a token standard, the Ethereum ecosystem as we know it would not exist. Each token would need bespoke wallet integrations, each DEX would need custom code per asset, and the friction of launching a new project would be enormous. ERC-20 solved this problem with a remarkably simple interface: six required functions and two required events.

The 6 Mandatory ERC-20 Functions

The ERC-20 specification defines six functions that every compliant token contract must implement. These functions are the public interface that all external code interacts with. If a contract is missing even one of these, it is technically not ERC-20 compliant, and many wallets or protocols may refuse to work with it.

The first three functions, totalSupply(), balanceOf(), and transfer(), are the basics of token accounting. They let anyone read the supply, check balances, and send tokens directly. If ERC-20 only had these three, it would already be useful, but DeFi as we know it would be impossible.

The next three functions, approve(), allowance(), and transferFrom(), form the delegated spending pattern. They let a user authorize a smart contract to pull tokens from their wallet up to a defined limit. This is what enables DEXs, lending protocols, staking contracts, and bridges to operate without holding your tokens in advance. We will dive into this pattern in detail later because it is also the source of most ERC-20 related security incidents.

The 3 Optional Functions: name(), symbol(), decimals()

In addition to the six mandatory functions, the ERC-20 specification defines three optional ones. They are not technically required for compliance, but in practice every modern token implements them because wallets and exchanges depend on them for display purposes.

name() returns the human readable name of the token, such as "USD Coin" or "Chainlink Token". This is the string you see in MetaMask and other wallets. symbol() returns the short ticker, like "USDC" or "LINK", typically three to five characters. decimals() returns the number of decimal places the token uses, which is how the contract converts between the integer values it stores internally and the human readable amounts you see on the front end.

The decimals function deserves a deeper explanation because it is the source of frequent confusion. Ethereum smart contracts cannot natively handle fractional numbers. All balances are stored as integers. To represent fractions, ERC-20 tokens use a multiplier defined by the decimals value. The Ethereum convention is 18 decimals, the same as ETH itself uses with wei. So when you see a balance of 1 LINK, the contract actually stores the integer 1,000,000,000,000,000,000. Your wallet divides by 10 to the power of 18 before displaying it.

Not all tokens use 18 decimals. USDC and USDT, for example, use only 6 decimals because they are pegged to the US dollar and do not need extreme precision. WBTC uses 8 decimals to match Bitcoin's satoshi precision. Some experimental tokens use 0 decimals to make them non-divisible. This is why it is critical to always check the decimals value before doing math on raw token balances. A common bug in early DeFi was assuming 18 decimals when the actual token used 6 or 8, leading to transfers that were off by a factor of 100 billion or more.

ERC-20 Events: Transfer and Approval

Functions are how external code calls into a contract. Events are how a contract notifies the outside world that something has happened. The ERC-20 standard defines two mandatory events that every token must emit. These events are the foundation of how block explorers, indexers, and analytics tools track token activity.

The first is event Transfer, emitted whenever tokens move between two addresses, including minting (from the zero address) and burning (to the zero address). Every transfer in the entire history of a token is captured by these logs, and that is exactly how Etherscan and DexTools can show you a complete transfer history for any ERC-20 token, without having to crawl the entire blockchain. They simply subscribe to Transfer events from each token contract and store them in an indexable database.

The second is event Approval, emitted whenever an owner authorizes a spender via the approve function. Tools like Revoke.cash, Etherscan's Token Approval Checker, and various wallet security extensions all rely on these events to show you the complete list of contracts that currently have permission to spend your tokens. Without standardized events, this kind of cross-protocol monitoring would be impossible.

This event driven architecture has a beautiful side effect. Because events are emitted onchain and stored in transaction receipts, they are permanent, transparent, and cryptographically verifiable. Any analytics tool can independently reconstruct the complete history of any token by replaying its events from the contract's deployment block. This is one of the underrated superpowers of public blockchains and the standards built on top of them.

The approve() / transferFrom() Pattern

If you only learn one thing about ERC-20 deeply, make it this pattern. The approve and transferFrom flow is what enables DeFi to exist, and it is also what causes the majority of wallet drains and approval exploits when used carelessly.

The problem the pattern solves is this. Smart contracts cannot reach into your wallet and take tokens. They need permission. But you also cannot send tokens to a contract and expect it to know what to do with them, because the simple transfer() function does not trigger any callback or notify the recipient that funds arrived. The solution is a two step delegated authorization model.

In step one, the user calls approve() on the token contract, granting a specific spender (often a DEX router or lending pool) the right to spend up to a defined amount of their tokens. This is what you sign when MetaMask asks you to approve a new token before your first swap. In step two, when you actually trigger the swap, the DEX contract calls transferFrom() on the token contract, which checks the allowance and moves tokens from your address to wherever the DEX needs them, all in one atomic transaction. For more context on this signing step, read our deep dive on the approval transaction.

This pattern is elegant because it separates authorization from execution. You authorize once, then any number of operations can happen against that allowance until it is fully consumed or revoked. It is also reusable, meaning the same approval works for the next swap, the next lending deposit, and so on, until you cancel it. The downside, as the warning above states, is that approvals are permission slips that persist until you explicitly revoke them, even if you stop using the protocol entirely.

How to Identify an ERC-20 Token on Etherscan

Etherscan is the most widely used block explorer for Ethereum, and it offers powerful tools for inspecting ERC-20 contracts. Knowing how to read a token's Etherscan page is one of the most valuable skills for anyone who interacts with new tokens, whether you are buying meme coins, researching new DeFi launches, or auditing a portfolio.

When you paste a token contract address into Etherscan, you land on the token tracker page. This page automatically displays the token name, symbol, total supply, number of holders, and total transfers, all of which Etherscan derives from the standard ERC-20 functions and events we discussed above. The page is automatically generated for any compliant ERC-20 contract, with no manual intervention by the project team. That is the power of a standard.

The Contract tab is where the most useful information lives. If the developers have verified their source code, you can read the actual Solidity code that defines the token's behavior. This is critical because the standard only enforces the interface, not what happens inside each function. A token can implement transfer() in a way that takes a 10 percent tax, blacklists certain addresses, pauses transfers entirely, or worse. Always check verified source code before interacting with any non established token.

The Read Contract section lets you call view functions directly from your browser, with no transaction needed. You can verify the totalSupply, check balances of any address, or query allowances. The Write Contract section lets you call state changing functions if you connect a wallet, but most users will trigger these through DEX or wallet interfaces rather than directly. The Holders tab shows the distribution of token ownership, which is essential for assessing concentration risk before buying a new token. If the top ten wallets hold 90 percent of the supply, that is a red flag.

ERC-20 vs Other Token Standards

ERC-20 is the most famous Ethereum token standard but it is far from the only one. Different use cases require different properties, and the Ethereum community has developed a family of related standards. Understanding how they compare helps clarify what ERC-20 is and is not.

ERC-20 tokens are fungible, meaning every unit is identical and interchangeable. One USDC is the same as any other USDC. ERC-721, the standard for NFTs, is the opposite. Each token has a unique ID and unique properties. You cannot swap one CryptoPunk for another without explicit agreement, because they are not interchangeable. ERC-1155 is a hybrid that allows a single contract to manage both fungible and non fungible tokens, making it especially popular in gaming where a single contract might handle gold coins (fungible) alongside legendary swords (non fungible).

ERC-4626 is one of the newer standards, finalized in 2022 and widely adopted by 2024. It is a wrapper standard built on top of ERC-20. A 4626 vault accepts deposits of a specific ERC-20 token and issues shares representing ownership of the underlying pool. Yearn Finance vaults, MakerDAO's sDAI, and many lending market receipt tokens follow this pattern. Because 4626 inherits from ERC-20, every vault share is itself a fully transferable ERC-20 token, which means you can put yield bearing receipts into Uniswap pools, use them as collateral elsewhere, and so on.

Top ERC-20 Tokens in 2026

The ERC-20 ecosystem includes tens of thousands of tokens, but a small set of them concentrate the vast majority of the value and volume. Here are some of the most important ERC-20 tokens you should be aware of in 2026.

Notice the diversity. Stablecoins like USDC, USDT, and DAI are the workhorses of onchain settlement. Governance tokens like UNI and AAVE distribute control of major protocols. LINK powers critical infrastructure. SHIB and PEPE prove that even tokens with no formal utility can reach billion dollar market caps when the meme captures attention. Every single one of them uses the exact same ERC-20 interface, which is why they all work in MetaMask, Uniswap, and DexTools without any custom integration.

How to Add a Custom ERC-20 to MetaMask

Although MetaMask automatically displays the most popular ERC-20 tokens, brand new or less common tokens require manual import. The process is fast once you know the steps, and it works the same way for any compliant ERC-20 on Ethereum or any EVM compatible network.

First, find the official contract address from a trustworthy source. The token's official website, the project's verified Etherscan page, DexTools, or CoinGecko are all reliable. Never copy a contract address from a random Telegram message or Twitter reply. Scammers regularly deploy fake tokens with names identical to legitimate ones, hoping users will import the wrong contract and lose funds.

Next, open MetaMask and make sure you are on the correct network. ERC-20 tokens on Ethereum mainnet are different contracts from their counterparts on Arbitrum, Base, or Polygon. Click the Tokens tab, then click "Import tokens" at the bottom of the list. Paste the contract address into the address field. MetaMask should automatically populate the symbol and decimals by querying the contract. If those fields stay blank, the contract may not be fully ERC-20 compliant, which is itself a warning sign worth investigating.

Confirm the import. The token now appears in your wallet's token list, and your balance is displayed based on the current state of the contract. Remember that importing a token does not affect your balance. The tokens already exist in the contract under your address. Importing just tells MetaMask which contracts to query and display. You can remove a custom token at any time without losing anything, because the tokens never lived in MetaMask in the first place.

ERC-20 on Other Chains

ERC-20 began on Ethereum, but its design is so simple and useful that it has been copied onto every Ethereum Virtual Machine compatible blockchain in existence. BNB Smart Chain calls its version BEP-20, but it is functionally identical, with the same six functions and same two events. Polygon, Arbitrum, Optimism, Base, Avalanche C-Chain, Fantom, and dozens of other EVM chains all use the ERC-20 standard natively.

This is why a token like USDC can exist on Ethereum, Arbitrum, Base, Polygon, Optimism, Avalanche, and many other chains. Each version is a separate ERC-20 contract on its respective chain, often bridged from the canonical Ethereum mainnet contract, but otherwise behaving identically. Wallets like MetaMask handle each version separately, and you must always confirm which chain a token is on before sending. Bridging tokens across chains uses different mechanisms entirely, often involving lock and mint patterns that we cover in our bridge tutorials.

The TRON blockchain also has a USDT version called TRC-20, which serves a similar purpose to ERC-20 but is not technically compatible. TRON is not an EVM chain, so its smart contracts use different bytecode and ABI conventions. The result is that USDT TRC-20 and USDT ERC-20 are not interchangeable. Sending TRC-20 to an ERC-20 address (or vice versa) typically results in lost funds. This kind of cross chain confusion is one of the most common ways users lose money in crypto.

Security: The Approve Exploit and Why You Should Revoke Old Approvals

The approve pattern is one of ERC-20's most powerful features and also its biggest security weak point. Every time you swap on a DEX, deposit into a lending protocol, or interact with any DeFi smart contract, you grant that contract permission to move your tokens. These approvals persist indefinitely unless you explicitly revoke them. Many users have hundreds of forgotten approvals from protocols they used once years ago.

The good news is that revoking approvals is straightforward. Tools like Revoke.cash will display every active approval on your wallet across all major EVM chains, and one click sends a transaction that resets the allowance to zero. The bad news is that revoking costs gas, so users tend to ignore it until it is too late. A reasonable habit is to review approvals every few months, especially after using new or experimental protocols, and to never approve unlimited amounts on a protocol you do not fully trust.

A second class of approval related risk involves phishing signature attacks. The EIP-2612 permit extension (which we cover in the next section) lets users approve tokens with an offchain signature instead of an onchain transaction. Phishing sites trick users into signing permits that look harmless but actually grant the attacker permission to drain their tokens. Always read what you are signing, and treat any "free claim" or "verify wallet" prompt with extreme suspicion.

The Evolution: ERC-777, ERC-1363, EIP-2612, ERC-4626

ERC-20 is intentionally minimal, and over the years the community has developed extensions to address its limitations. None of these have fully replaced ERC-20, but they are all important context for understanding the modern Ethereum token landscape.

ERC-777 was proposed in 2017 as a more advanced fungible token standard. It introduced hooks that let contracts react to incoming tokens, eliminating the need for the two step approve and transferFrom dance. It was elegant in design but ultimately controversial. The reentrancy hooks proved dangerous when combined with naive DeFi contracts, and a notable Uniswap V1 exploit involving an ERC-777 token led to most major protocols explicitly disallowing 777 tokens. As a result, adoption never took off.

ERC-1363 is a payable token extension that adds transferAndCall functions, allowing a single transaction to transfer tokens and trigger an action on the receiving contract. It is fully backward compatible with ERC-20, since it just adds new functions on top. Adoption has been modest but is growing in newer protocols.

EIP-2612 introduced the permit function, a way to grant approvals via offchain signatures instead of onchain transactions. This means a user can sign a message in their wallet, and a third party can submit that signature to the token contract along with the actual transfer, all in one transaction. The user pays no gas for the approval. Permit is widely supported in newer tokens including DAI, USDC, and many others. It is convenient but also introduces the phishing vector mentioned above, since users do not see a clear approve transaction in their wallet.

ERC-4626 we already covered above. It standardizes how yield bearing vaults issue shares, making it possible to plug any vault into any DeFi protocol. The deposit, withdraw, mint, redeem, totalAssets, convertToShares, and convertToAssets functions form a unified interface that any vault can implement.

Creating Your Own ERC-20 Token

Creating an ERC-20 token is one of the easiest ways to ship a smart contract. The OpenZeppelin contracts library provides battle tested, audited implementations of the standard that you can extend in just a few lines of Solidity. Almost every major token on Ethereum either uses OpenZeppelin directly or forks from it.

A minimal ERC-20 token using OpenZeppelin is roughly twenty lines of code. You inherit from the ERC20 base contract, give your token a name and symbol in the constructor, optionally mint an initial supply to the deployer, and you are done. Optional extensions include ERC20Burnable for letting users burn their own tokens, ERC20Capped for enforcing a maximum supply, ERC20Pausable for emergency pauses, and ERC20Votes for governance enabled voting power tracking with checkpoints.

The deployment workflow typically uses Foundry, Hardhat, or Remix. Foundry has emerged as the favored framework for serious developers due to its speed, but Remix remains the easiest entry point for beginners since it runs entirely in the browser. After writing and compiling your contract, you deploy it to your target network, then verify the source code on Etherscan so that everyone can see and read your code. Verification is critical for building trust, especially for tokens that hope to attract liquidity and listings.

However, deploying a token is only the first step. A successful token requires liquidity on a DEX, a community, a clear narrative, and ideally honest distribution practices. Tens of thousands of tokens are deployed every month, the vast majority of which fail to attract any meaningful trading volume. Compelling tokenomics, transparent vesting, locked liquidity, and renounced ownership are common signals that legitimate teams use to differentiate themselves from rug pulls and scams.

Frequently Asked Questions

What does ERC-20 stand for?

ERC-20 stands for Ethereum Request for Comments, number 20. It refers to the twentieth proposal submitted under the Ethereum Request for Comments process, which is how technical standards are formally proposed and discussed for the Ethereum protocol. The standard was eventually formalized as Ethereum Improvement Proposal 20, or EIP-20, but the ERC-20 name has remained the colloquial term in everyday use.

Is USDC an ERC-20 token?

Yes, USDC on Ethereum mainnet is an ERC-20 token. Its contract address is 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 and it has been fully ERC-20 compliant since launch in 2018. USDC also exists on many other chains (Solana, Stellar, and various EVM chains), but those versions are separate contracts using whatever local token standard applies. The Ethereum version is the canonical ERC-20 USDC and accounts for a large share of total USDC supply.

What is the difference between ERC-20 and BEP-20?

BEP-20 is the token standard on BNB Smart Chain. Functionally it is essentially identical to ERC-20, using the same function signatures, the same events, and the same approval pattern. The difference is the underlying blockchain. ERC-20 lives on Ethereum and benefits from Ethereum's security and ecosystem, while BEP-20 lives on BNB Smart Chain and benefits from lower fees and faster blocks. Tokens like USDT exist as both ERC-20 and BEP-20 versions, and they are not interchangeable without bridging.

Can I create my own ERC-20 token?

Yes, anyone can create an ERC-20 token in just a few lines of Solidity using libraries like OpenZeppelin. Deployment costs gas (typically anywhere from twenty to a few hundred dollars on Ethereum mainnet, depending on contract complexity and network conditions). However, creating a token is the easy part. Building real utility, attracting holders, and providing liquidity on a DEX are the harder challenges that determine whether a token has any value beyond its deployment.

What is the gas cost of an ERC-20 transfer?

A typical ERC-20 transfer on Ethereum mainnet costs around 65,000 gas units when the recipient already has a balance of the token, or roughly 50,000 gas when the recipient is a fresh address (slightly higher cost is offset by other dynamics). At a gas price of 20 gwei, this translates to roughly 0.0013 ETH per transfer. The actual dollar cost depends entirely on the current ETH price and network congestion. Layer 2 rollups like Arbitrum and Base reduce these costs by ten to one hundred times.

Why do ERC-20 tokens use 18 decimals?

Eighteen decimals is the convention because ETH itself is denominated in wei, which is one quintillionth (10 to the negative 18) of an ether. Aligning tokens with the same precision avoids confusion when doing math between ETH and tokens in smart contracts. However, ERC-20 does not enforce 18 decimals. Stablecoins like USDC and USDT use 6 decimals because they are dollar pegged and do not need extreme precision. WBTC uses 8 decimals to mirror Bitcoin's satoshi system. Always check decimals before doing arithmetic on raw token balances.

Conclusion

ERC-20 is the unsung hero of the entire crypto economy. It is a deceptively simple specification, just six required functions and two required events, but it has enabled trillions of dollars in token issuance, the entire DeFi ecosystem, and a level of interoperability that traditional finance can only dream of. Every stablecoin, every governance token, every meme coin, and every yield bearing vault on Ethereum and on every EVM compatible chain ultimately speaks the same language defined by EIP-20 back in 2015.

Understanding ERC-20 at the level we covered in this guide gives you a real advantage. You can now read a token contract on Etherscan, evaluate its approval surface, identify red flags, import custom tokens to MetaMask without making mistakes, and reason about why DeFi protocols behave the way they do. You also understand the standard's most dangerous weak point, the approve and transferFrom pattern, well enough to manage it safely with periodic revocations and careful signing habits.

The standard will continue evolving. Permit signatures, account abstraction, and new extensions like ERC-4626 are reshaping how users interact with tokens. But the core ERC-20 interface is so deeply embedded in every wallet, exchange, indexer, and protocol that it is effectively permanent infrastructure. If you only learn one technical standard in crypto, learn this one. Almost every interaction you will ever have onchain runs through it.

Related Guides

• What Is Account Abstraction: ERC-4337 Explained Simply (2026)
• TRC-20 vs ERC-20: Complete USDT Comparison Guide (2026)
• ERC-721 vs ERC-1155 Comparison for Traders
• What Is an XRP ETF? Approval and Trading Guide 2026
• What Are Jettons? Complete TON Token Standard Guide (2026)