Skip to main content

What is ERC-20

What is ERC-20

ERC-20 is the most widely adopted token standard on the Ethereum blockchain. It defines a common interface -- a set of functions and events -- that a smart contract must implement to create a fungible token. "Fungible" means that every unit of the token is identical and interchangeable, just as any one dollar bill is equivalent to any other dollar bill.

ERC stands for Ethereum Request for Comments, and 20 is the proposal number. The standard was proposed in 2015 and has become the de facto blueprint for creating tokens on Ethereum and on EVM-compatible chains. When a project says its token is "ERC-20," it means the token contract follows this standard interface, which guarantees compatibility with wallets, decentralized exchanges, portfolio trackers, and other smart contracts across the Ethereum ecosystem.

In short: ERC-20 is a technical standard that defines how fungible tokens work on Ethereum -- ensuring that any ERC-20 token can be sent, received, and managed by any wallet or application that supports the standard.

How ERC-20 works

The standard interface

At its core, ERC-20 specifies a set of functions that every compliant token contract must implement. These functions provide a common language that external applications (wallets, exchanges, other contracts) can use to interact with the token without needing to know anything about the token's internal logic.

The key functions are:

Function What it does
totalSupply() Returns the total number of tokens in existence
balanceOf(address) Returns how many tokens a specific address holds
transfer(to, amount) Sends tokens from the caller's address to another address
approve(spender, amount) Authorizes another address (a smart contract or user) to spend up to a specified amount of the caller's tokens
transferFrom(from, to, amount) Allows a pre-approved spender to transfer tokens on behalf of the token owner
allowance(owner, spender) Returns how many tokens the spender is still allowed to transfer on behalf of the owner

The standard also defines two events -- Transfer and Approval -- that are emitted when tokens move or when spending permissions change. These events allow external systems (block explorers, indexers, analytics tools) to track token activity without querying the contract directly.

Why a standard matters

Before ERC-20 was widely adopted, every token project created its own custom interface. This meant that wallets, exchanges, and other applications had to write custom code for each new token. ERC-20 solved this problem by creating a universal contract interface: any application that supports ERC-20 automatically supports every ERC-20 token, whether it was created yesterday or years ago.

This composability is one of the foundations of the Ethereum ecosystem. A decentralized exchange does not need to know what a specific token represents or who created it -- if the token implements the ERC-20 interface, the exchange can list it, trade it, and settle transactions with it.

Deploying an ERC-20 token

Creating an ERC-20 token involves deploying a smart contract to the Ethereum network (or an EVM-compatible chain) that implements the required functions. The deployer specifies the token's name, symbol, decimal precision, and initial supply. Once deployed, the contract is immutable -- the token's core interface cannot be changed, though some implementations include additional features like minting, burning, or pausing through governance mechanisms.

The low technical barrier to deploying an ERC-20 token is both a strength and a risk. It enables rapid innovation and experimentation, but it also means that anyone can create a token with any name and any stated purpose. The existence of an ERC-20 token does not imply quality, legitimacy, or value.

ERC-20 and EVM-compatible chains

While ERC-20 was created for Ethereum, the standard works on any EVM-compatible blockchain. Chains such as BNB Smart Chain, Polygon, Arbitrum One, Base, and Avalanche all support ERC-20 tokens natively because they implement the Ethereum Virtual Machine. On some of these chains, the standard may have a different formal name (BEP-20 on BNB Smart Chain, for instance), but the interface is functionally identical.

This means that a project's token might be described as "ERC-20" even if it is deployed on a chain other than Ethereum. The standard is a technical interface, not a chain-specific designation. What matters is whether the token contract implements the ERC-20 function set, not which network it runs on.

ERC-20 compared to other token types

Dimension ERC-20 ERC-721 (NFT) ERC-1155 (Multi-token) Native token (ETH, SOL)
Fungibility Fungible (all units identical) Non-fungible (each token unique) Both fungible and non-fungible Fungible
Deployed as Smart contract Smart contract Smart contract Built into the protocol
Standard interface transfer, approve, balanceOf ownerOf, safeTransferFrom Batch operations No standard contract interface
Use case Currencies, utility tokens, governance tokens Digital art, unique assets, identity Gaming items, mixed collections Gas fees, staking, base currency

ERC-20 tokens are distinct from native tokens like ETH. While ETH is built directly into the Ethereum protocol and exists without a smart contract, ERC-20 tokens are created by deploying a contract that follows the standard. Both can be held and transferred, but they have different technical properties and different roles in the network.

Limitations and extensions of ERC-20

While ERC-20 is the most widely used token standard, it has known limitations that have led to extensions and improvements:

  • No notification on receive. When tokens are sent to a smart contract, the receiving contract has no automatic way to react. This has led to tokens being permanently locked in contracts that do not handle ERC-20 transfers. The ERC-223 and ERC-777 standards were proposed to address this, though ERC-20 remains dominant.
  • Two-step approval pattern. Transferring tokens on behalf of another address requires two transactions: first approve, then transferFrom. This adds friction and gas cost. The ERC-2612 (Permit) extension allows gasless approvals through off-chain signatures.
  • No built-in metadata. ERC-20 tokens have a name and symbol but no standardized way to include additional metadata (description, icon, documentation link). Extensions and off-chain registries fill this gap.

These limitations do not diminish ERC-20's practical utility. The standard's simplicity and universal support outweigh its technical imperfections for the vast majority of use cases.

Why ERC-20 matters for crypto AI projects

Most crypto AI projects that issue a token on Ethereum or an EVM-compatible chain use the ERC-20 standard. The token might serve as a utility token (paying for compute, accessing AI services), a governance token (voting on protocol parameters), or a fee mechanism (paying for network usage). Regardless of its intended role, using ERC-20 ensures the token is compatible with the broader ecosystem: users can hold it in standard wallets, trade it on decentralized exchanges, and interact with it through well-known interfaces.

For readers evaluating a crypto AI project, knowing that a token is ERC-20 tells you about its technical format -- not its utility, necessity, or value. The token standard answers "how does the token work technically?" but not "why does the project need a token?" or "does the token actually serve a purpose in the AI pipeline?"

Where it appears in DecAIHub project cards

In a DecAIHub project card, ERC-20 appears in the Token standard field. When a card shows Token standard: ERC-20, it means the project's token is implemented as an ERC-20 smart contract.

The token standard field is purely descriptive: it tells readers the technical format of the token. It should be read alongside the Token model field (which describes the token's role: utility, governance, fee mechanism) and the Main chain field (which tells readers which network the token is deployed on).

A project may have tokens on multiple chains -- for instance, an ERC-20 token on Ethereum and a bridged version on an L2 like Arbitrum. The token standard field typically reflects the primary deployment.

What ERC-20 alone does not prove

  • ERC-20 does not prove token utility. Any smart contract can implement the ERC-20 interface. The standard defines the token's technical behavior, not its economic role or necessity. A project can have an ERC-20 token that serves no purpose in its AI or application pipeline.
  • ERC-20 does not prove legitimacy. Creating and deploying an ERC-20 token requires minimal technical effort and cost. The existence of a token is not evidence that the project behind it is real, functional, or trustworthy.
  • ERC-20 does not prove that the project is on Ethereum. ERC-20 tokens exist on many EVM-compatible chains. The token standard does not indicate which chain the token is deployed on -- check the Main chain field for that information.
  • ERC-20 does not prove AI capability. A token's technical standard has no connection to whether the project has a real AI component, working inference, or verifiable models.
  • ERC-20 does not prove decentralization. The token contract itself may include centralized controls: admin keys for minting or burning, pause functions, upgrade proxies controlled by a single address. The standard defines the interface, not the governance model.

Do not confuse with

  • Token standard -- the umbrella concept. ERC-20 is one specific token standard. Others include ERC-721 (NFTs), ERC-1155 (multi-tokens), BEP-20 (BNB Smart Chain), SPL (Solana), and native tokens.
  • Native token -- ETH is Ethereum's native token, built into the protocol itself. ERC-20 tokens are created by deploying smart contracts on top of the protocol. They coexist but are technically different.
  • Token model -- the token model describes the role of the token (utility, governance, fee mechanism). The token standard describes the technical format. A token can be ERC-20 (standard) and a utility token (model) at the same time.
  • BEP-20 -- the token standard on BNB Smart Chain. BEP-20 is functionally identical to ERC-20 but is the naming convention used on a different chain.
  • ERC-721 -- the standard for non-fungible tokens (NFTs) on Ethereum. ERC-721 tokens are unique; ERC-20 tokens are interchangeable.

Frequently asked questions

What does "fungible" mean in the context of ERC-20?

Fungible means that every unit of the token is identical in value and function to every other unit. If you hold 100 units of an ERC-20 token, any one of those units is interchangeable with any other unit of the same token. This is the same principle that makes one dollar bill equivalent to any other dollar bill. By contrast, non-fungible tokens (ERC-721) are each unique -- one NFT is not interchangeable with another.

Can an ERC-20 token be created on chains other than Ethereum?

Yes. Any blockchain that implements the Ethereum Virtual Machine (EVM) supports ERC-20 tokens. This includes chains like Polygon, Arbitrum One, Base, BNB Smart Chain, Avalanche, and many others. On BNB Smart Chain, the equivalent standard is called BEP-20, but it implements the same interface. A token that follows the ERC-20 function set works with any EVM-compatible wallet, exchange, or smart contract regardless of the specific chain.

What is the difference between ERC-20 and a native token like ETH?

ETH is Ethereum's native token -- it is built into the protocol itself and exists without a smart contract. ETH is used to pay gas fees and to participate in staking. ERC-20 tokens, by contrast, are created by deploying smart contracts on top of Ethereum. They require ETH to pay gas fees for transfers and interactions. Both types of tokens can be held in the same wallet, but their technical implementation is fundamentally different.

Does deploying an ERC-20 token require a lot of technical expertise?

Deploying a basic ERC-20 token requires moderate smart contract development knowledge. Standard libraries (such as OpenZeppelin) provide audited, ready-to-use ERC-20 implementations that can be deployed with minimal customization. The low barrier to deployment is both a feature (enabling rapid experimentation and innovation) and a risk (enabling anyone to create a token for any purpose). The existence of a deployed token is not, by itself, evidence of technical capability.

External references

See also

No comments to display

Back to top