ERC-20
Published Last updated
Key Takeaway
A technical standard for fungible tokens on the Ethereum blockchain that defines a common set of rules enabling tokens to interact predictably across wallets, exchanges, and decentralized applications, making ERC-20 the dominant token standard in cryptocurrency.
Learn These First
What Is ERC-20?
A technical standard for fungible tokens on the Ethereum blockchain that defines a common set of rules enabling tokens to interact predictably across wallets, exchanges, and decentralized applications, making ERC-20 the dominant token standard in cryptocurrency.
How ERC-20 Works
Frequently Asked Questions
How do I know if a token is ERC-20 compliant, and does it matter?
ERC-20 compliance determines whether tokens work with standard Ethereum wallets, exchanges, and DeFi protocols, making verification essential before interacting with unfamiliar tokens. To verify ERC-20 compliance, examine the token's smart contract on Etherscan: navigate to the contract address, select the 'Contract' tab, and check the 'Read Contract' section for required ERC-20 functions (totalSupply, balanceOf, transfer, approve, allowance, transferFrom). Legitimate ERC-20 tokens display these functions clearly, while non-compliant tokens show different or missing functions. Contract verification status on Etherscan (green checkmark) indicates the creator published source code for public review, though verification alone doesn't guarantee safety or ERC-20 compliance. Token contract addresses should match official sources—project websites, verified social media accounts, or reputable token listing sites like CoinGecko or CoinMarketCap. ERC-20 compliance matters significantly because non-compliant tokens may not work with standard wallets, face exchange listing difficulties, or behave unpredictably in DeFi protocols. Some projects deliberately modify ERC-20 standards for additional features—tokens with transfer taxes, reflection mechanisms, or special restrictions technically violate pure ERC-20 specifications despite implementing core functions. These modifications can cause unexpected behavior or compatibility issues. When evaluating tokens, compliance represents a baseline check rather than comprehensive due diligence—verified ERC-20 contracts can still contain malicious code, poor tokenomics, or security vulnerabilities requiring deeper research through security audits, team background checks, and community reviews.
What are token approvals in ERC-20, and why do DeFi applications request them?
ERC-20 token approvals grant smart contracts permission to transfer tokens from your wallet on your behalf, enabling automated DeFi operations while creating security considerations requiring careful management. The approval mechanism works through the approve() function: users authorize a specific smart contract to spend up to a designated amount of tokens. For example, using Uniswap to swap USDC for ETH requires approving Uniswap's router contract to spend your USDC—the contract can then execute the swap by transferring your USDC and sending you ETH in return. Without approvals, smart contracts couldn't move tokens from user wallets, preventing DeFi protocols from functioning. Common approval scenarios include: decentralized exchanges requiring token spending permissions for swaps, lending protocols needing approval to deposit collateral or repay loans, yield farming platforms accessing tokens for liquidity provision, and NFT marketplaces moving payment tokens during purchases. Applications typically request unlimited approvals for user convenience—one approval enables infinite future transactions without repetitive approval transactions. However, unlimited approvals create security risks: compromised applications or malicious contract upgrades could drain entire token balances. Best practices include: granting exact amounts needed for specific transactions rather than unlimited approvals, regularly reviewing and revoking unused approvals through tools like Etherscan Token Approvals or Revoke.cash, maintaining skepticism toward approval requests from unfamiliar applications, and never approving tokens when interacting with unverified contracts. The two-step process (approve then transfer) increases gas costs compared to simple transfers but enables the programmable token interactions powering decentralized finance.
Why can't I send ERC-20 tokens to some addresses, and what happens if I send tokens to the wrong address?
ERC-20 tokens can be sent to any valid Ethereum address, but tokens sent to incompatible addresses often become permanently unrecoverable due to technical limitations in the standard's design. Smart contract addresses present the highest risk: many contracts cannot detect incoming ERC-20 token transfers since the standard's transfer() function doesn't notify recipient contracts about deposits. Tokens transferred to contracts lacking withdrawal functions remain locked indefinitely—no mechanism exists to recover them. This commonly affects tokens accidentally sent to the token contract's own address, exchange deposit contracts for wrong tokens, or random smart contracts without token handling capabilities. Unlike native ETH transfers which contracts can reject, ERC-20 transfers complete regardless of recipient capability to use received tokens. Some specific problematic scenarios: sending tokens to centralized exchange addresses with incorrect memo/tag fields causes processing failures though exchanges may eventually recover funds manually, sending tokens to addresses on different blockchains (like sending ERC-20 USDT to a Bitcoin address) results in permanent loss since addresses don't translate across chains, and sending tokens to burned or inaccessible addresses (like 0x000...000) destroys them permanently. Protection strategies include: double-checking recipient addresses before confirming transactions, sending small test amounts before large transfers to unfamiliar addresses, using address book features in wallets to avoid manual entry errors, verifying the recipient expects the specific token you're sending, and confirming network selection matches the token's blockchain for multi-chain assets. Address formats cannot prevent incompatible sends—valid Ethereum addresses work for both EOAs (externally owned accounts) and contracts, providing no warning when sending to contracts. Newer standards like ERC-777 attempt solving these issues, but ERC-20's dominance means limitations persist.
Common Misconceptions About ERC-20
All tokens on Ethereum are automatically ERC-20 tokens, so I don't need to verify token standards.
Ethereum hosts multiple token standards serving different purposes, with ERC-20, ERC-721, ERC-1155, and various specialized standards coexisting on the network. ERC-20 specifically addresses fungible tokens where each unit is identical and interchangeable, suitable for currencies, governance tokens, and utility tokens. ERC-721 defines non-fungible tokens (NFTs) where each token is unique, used for digital art, collectibles, and unique assets. ERC-1155 supports both fungible and non-fungible tokens within single contracts, popular for gaming items and complex token economies. Additionally, projects create custom token implementations adding features beyond standard specifications—tokens with transaction taxes, reflection mechanisms, voting capabilities, or specialized transfer restrictions. Some tokens deliberately deviate from ERC-20 to implement desired functionality, creating compatibility challenges with standard wallets and protocols. Token standard matters when: selecting appropriate wallets supporting specific standards, understanding how tokens will behave in transfers and interactions, evaluating compatibility with DeFi protocols and exchanges, and troubleshooting issues with token visibility or functionality. Blindly assuming ERC-20 compliance can cause problems—sending NFTs to addresses expecting fungible tokens, attempting to use non-standard tokens in protocols requiring strict ERC-20 compliance, or experiencing unexpected behavior from tokens with custom modifications. Always verify token standards through contract inspection on Etherscan and project documentation before significant interactions or investments.
ERC-20 tokens are safer than other cryptocurrencies because they follow a standard, so I don't need to research them carefully.
ERC-20 standardization addresses token interoperability and functionality, not security, legitimacy, or investment quality—malicious or poorly designed tokens can fully comply with ERC-20 specifications while still being dangerous or worthless. The standard defines how tokens should behave (tracking balances, enabling transfers, managing approvals) but doesn't restrict what additional code developers can include in smart contracts. Scam tokens regularly achieve perfect ERC-20 compliance while implementing: hidden minting functions allowing creators to inflate supply arbitrarily, transfer restrictions preventing token sales after purchase, ownership backdoors enabling fund seizures, or honeypot mechanisms allowing buys but blocking sells. Security audits become essential because ERC-20 compliance provides no security guarantees—contracts can contain reentrancy vulnerabilities, overflow/underflow bugs, or access control flaws while technically meeting standard requirements. Additionally, compliant tokens can have terrible tokenomics: excessive founder allocations, no utility or use case, inflationary supply mechanics, or plagiarized whitepapers. Due diligence for ERC-20 tokens requires examining: verified and audited smart contract code, team backgrounds and track records, tokenomics and distribution models, actual utility and adoption metrics, community engagement and development activity. Many of the most notorious crypto scams operated as fully compliant ERC-20 tokens, demonstrating that technical standard adherence doesn't indicate project legitimacy. The standard's accessibility—anyone can deploy compliant tokens in minutes—actually increases risk by lowering barriers to scam token creation.
Since ERC-20 is the token standard on Ethereum, tokens on other blockchains like Binance Smart Chain or Polygon must use different, incompatible standards.
Many blockchain platforms deliberately implemented ERC-20 compatibility to leverage Ethereum's established ecosystem and developer familiarity, enabling identical token standards across multiple networks despite their independence. Binance Smart Chain (BSC), Polygon, Avalanche C-Chain, and other EVM-compatible chains support ERC-20 tokens using identical technical specifications, function names, and behavior as Ethereum ERC-20 tokens. This compatibility stems from these blockchains using the Ethereum Virtual Machine or compatible execution environments, allowing developers to deploy the same smart contract code across multiple chains with minimal modifications. However, ERC-20 tokens on different blockchains remain separate assets despite technical compatibility—USDC on Ethereum differs from USDC on Polygon or BSC, existing as distinct tokens with separate supply, liquidity, and value. Token bridges enable cross-chain transfers by locking tokens on one chain and minting equivalent wrapped versions on destination chains. The technical standard compatibility creates advantages: developers write token contracts once and deploy across multiple chains, wallets supporting Ethereum ERC-20 automatically work with BSC and Polygon tokens, and users familiar with Ethereum interactions translate knowledge to compatible chains. But compatibility creates confusion risks: accidentally sending tokens to addresses on wrong chains can cause permanent loss, bridge exploits affect multiple chains simultaneously, and users must specify correct networks when transferring multi-chain tokens. Understanding this multi-chain ERC-20 landscape requires: verifying which blockchain hosts specific token instances, confirming wallet and exchange network selections match intended chains, and recognizing that ERC-20 compatibility doesn't mean tokens are fungible across chains.