

Ethereum was founded by Vitalik Buterin in 2014, positioning itself as an open-source platform for launching decentralized applications (DApps). Many of Buterin's motivations for creating a new blockchain stemmed from the Bitcoin protocol's lack of flexibility.
Since its launch, the Ethereum blockchain has attracted developers, businesses, and entrepreneurs, spawning a growing industry of users launching smart contracts and distributed applications.
This article explores the ERC-20 standard, an important framework for creating tokens. While it is specific to the Ethereum network, the framework has also inspired other blockchain standards across various platforms.
In Ethereum, an ERC is an Ethereum Request for Comments. These are technical documents that outline standards for programming on Ethereum. They should not be confused with Ethereum Improvement Proposals (EIPs), which, like Bitcoin's BIPs, suggest improvements to the protocol itself. ERCs instead aim to establish conventions that make it easier for applications and contracts to interact with each other.
Authored by Vitalik Buterin and Fabian Vogelsteller in 2015, ERC-20 proposes a relatively simple format for Ethereum-based tokens. By following the outline, developers do not need to reinvent the wheel. Instead, they can build off a foundation already used across the industry.
Once new ERC-20 tokens are created, they become automatically interoperable with services and software supporting the ERC-20 standard, including software wallets, hardware wallets, and exchanges.
It should be noted that the ERC-20 standard was later developed into an EIP (specifically, EIP-20). This transition occurred a couple of years after the original proposal due to its widespread use. However, even with this evolution, the name "ERC-20" has remained the standard terminology.
Unlike ETH (Ethereum's native cryptocurrency), ERC-20 tokens are not held by accounts directly. The tokens exist only inside a contract, which functions like a self-contained database. It specifies the rules for the tokens (such as name, symbol, and divisibility) and maintains a list that maps users' balances to their Ethereum addresses.
To move tokens, users must send a transaction to the contract asking it to allocate some of their balance elsewhere. For example, if Alice wants to send 5,000 tokens to Bob, she calls a function inside the relevant smart contract requesting this action.
Her call is contained inside what appears to be a regular Ethereum transaction that pays 0 ETH to the token contract. The call is included in an additional field in the transaction, which specifies what Alice wants to do – in this case, transferring tokens to Bob.
Even though she is not sending ether, she must still pay a fee denominated in it to have her transaction included in a block. If she has no ETH, she needs to acquire some before transferring the tokens.
Now that we have covered the basics, let us examine the structure of a typical ERC-20 contract more closely.
To be ERC-20-compliant, a contract must include six mandatory functions: totalSupply, balanceOf, transfer, transferFrom, approve, and allowance. Additionally, developers can specify optional functions, such as name, symbol, and decimal.
function totalSupply() public view returns (uint256)
When called by a user, this function returns the total supply of tokens that the contract holds.
function balanceOf(address _owner) public view returns (uint256 balance)
Unlike totalSupply, balanceOf takes a parameter (an address). When called, it returns the balance of that address's token holdings. Since accounts on the Ethereum network are public, anyone can query any user's balance provided they know the address.
function transfer(address _to, uint256 _value) public returns (bool success)
The transfer function transfers tokens from one user to another. Here, the caller provides the address to send to and the amount to transfer.
When called, transfer triggers an event (event transfer, in this case), which tells the blockchain to include a reference to this transaction.
function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
The transferFrom function is a useful alternative to transfer that enables greater programmability in decentralized applications. Like transfer, it is used to move tokens, but those tokens do not necessarily need to belong to the person calling the contract.
In other words, users can authorize someone – or another contract – to transfer funds on their behalf. A practical use case involves subscription-based services, where users do not want to manually send a payment every day, week, or month. Instead, they can allow a program to handle payments automatically.
This function triggers the same event as transfer.
function approve(address _spender, uint256 _value) public returns (bool success)
The approve function is valuable from a programmability standpoint. With this function, users can limit the number of tokens that a smart contract can withdraw from their balance. Without it, users risk the contract malfunctioning (or being exploited) and stealing all of their funds.
Consider the subscription model example again. Suppose a user has a substantial amount of tokens and wants to set up weekly recurring payments to a streaming DApp. Rather than manually creating a transaction every week, they can automate the process.
If the user's balance far exceeds what is needed for the subscription, they can use approve to set a limit. For instance, if the subscription costs one token per week, they could cap the approved value at twenty tokens. This way, they could have their subscription paid automatically for five months.
At worst, if the DApp attempts to withdraw all funds or if a bug is discovered, the user can only lose twenty tokens. While not ideal, this is considerably better than losing the entire balance.
When called, approve triggers the approval event, which writes data to the blockchain.
function allowance(address _owner, address _spender) public view returns (uint256 remaining)
The allowance function works in conjunction with approve. When a user has given a contract permission to manage their tokens, they can use this function to check how many tokens it can still withdraw. For instance, if a subscription has used twelve of the twenty approved tokens, calling the allowance function should return eight.
The previously discussed functions are mandatory. However, name, symbol, and decimal are optional but can make an ERC-20 contract more user-friendly. Respectively, they allow developers to add a human-readable name, set a symbol (such as ETH, BTC, or other identifiers), and specify how many decimal places tokens are divisible to. For example, tokens used as currencies may benefit from greater divisibility than a token representing ownership of a physical asset.
By combining all of the functions described above, developers create a functional ERC-20 contract. The contract allows users to query the total supply, check balances, transfer funds, and grant permissions to other DApps to manage tokens on their behalf.
A major appeal of ERC-20 tokens is their flexibility. The conventions established do not restrict development, allowing parties to implement additional features and set specific parameters to suit their particular needs.
Stablecoins (tokens pegged to fiat currencies) frequently use the ERC-20 token standard, with most major stablecoins available in this format.
For a typical fiat-backed stablecoin, an issuer holds reserves of fiat currency. Then, for every unit in their reserve, they issue a corresponding token. For example, if $10,000 were locked away in a vault, the issuer could create 10,000 tokens, each redeemable for $1.
This approach is relatively straightforward to implement on Ethereum from a technical perspective. An issuer simply launches a contract with the desired number of tokens and then distributes them to users with the promise that they can later redeem the tokens for a proportionate amount of fiat currency.
Users can perform various actions with their tokens – they can purchase goods and services, use them in DApps, or request redemption from the issuer. When tokens are redeemed, the issuer burns the returned tokens (making them unusable) and withdraws the corresponding amount of fiat from their reserves.
The contract governing this system is relatively simple. However, launching a stablecoin requires substantial work on external factors such as logistics and regulatory compliance.
Security tokens are similar to stablecoins in structure. At the contract level, both could even function identically. The distinction occurs at the issuer's level. Security tokens represent securities, such as stocks, bonds, or physical assets. Often (though not always), they grant the holder some kind of stake in a business or asset.
Utility tokens are perhaps the most common token types found in the cryptocurrency space. Unlike the previous two categories, they are not backed by external assets. If asset-backed tokens are like shares in an airline company, then utility tokens are like frequent-flyer programs: they serve a specific function, but they have no inherent external value. Utility tokens can serve numerous use cases, functioning as in-game currency, fuel for decentralized applications, loyalty points, and much more.
While ether (ETH) can be mined, tokens are not mineable – we say they are minted when new ones are created. When a contract is launched, developers distribute the supply according to their plans and roadmap.
Typically, this distribution occurs through an Initial Coin Offering (ICO), Initial Exchange Offering (IEO), or Security Token Offering (STO). While variations of these acronyms exist, the underlying concepts are quite similar. Investors send ether to the contract address and, in return, receive newly created tokens. The funds collected are used to finance further development of the project. Users expect to use their tokens (either immediately or at a later date) or resell them for a profit as the project develops.
Token distribution does not need to be automated. Many crowdfunding events allow users to pay with a range of different digital currencies. The respective balances are then allocated to the addresses provided by the participants.
ERC-20 tokens are fungible – each unit is interchangeable with another. If someone held a particular ERC-20 token, it would not matter which specific token they had. They could trade it for someone else's token, and they would still be functionally identical, just like cash or gold.
This characteristic is ideal for tokens intended to function as a currency. Users would not want individual units with distinguishable traits, which would make them non-fungible. This could cause some tokens to become more or less valuable than others, undermining their purpose as a medium of exchange.
As explored previously, ERC-20 tokens are highly customizable and can be tailored to numerous applications. For instance, they can be used as in-game currency, in loyalty points programs, as digital collectibles, or even to represent fine art and property rights.
ERC-20's popularity in the cryptocurrency industry is a compelling reason to use it as a blueprint. There are numerous exchanges, wallets, and smart contracts already compatible with newly launched tokens. Furthermore, developer support and documentation are abundant.
Like many cryptocurrency networks, Ethereum faces scalability challenges. In its current form, it does not scale efficiently – attempting to send a transaction during peak times results in high fees and delays. If an ERC-20 token is launched during periods of network congestion, its usability could be significantly impacted.
This is not a problem unique to Ethereum. Rather, it represents a necessary trade-off in secure, distributed systems. The community has planned to address these issues through upgrades and network improvements.
While not an issue with the technology itself, the ease with which a token can be launched could be considered a downside in some respects. It requires minimal effort to create a simple ERC-20 token, meaning that anyone could do so – for legitimate or illegitimate purposes.
As such, users should exercise caution with their investments. There are numerous pyramid and Ponzi schemes disguised as blockchain projects. Conducting thorough research before investing is essential to reach informed conclusions about the legitimacy of an opportunity.
ERC-20 was the first (and remains the most popular) Ethereum token standard, but it is by no means the only one. Over time, many others have emerged, either proposing improvements on ERC-20 or attempting to achieve different objectives.
Some less common standards are those used in non-fungible tokens (NFTs). In certain use cases, unique tokens with different attributes are actually beneficial. If someone wanted to tokenize a one-of-a-kind piece of art, in-game asset, or similar item, one of these alternative contract types might be more appropriate.
The ERC-721 standard, for instance, was used for the popular CryptoKitties DApp. Such a contract provides an API for users to mint their own non-fungible tokens and to encode metadata such as images and descriptions.
The ERC-1155 standard could be seen as an improvement on both ERC-721 and ERC-20. It outlines a standard that supports both fungible and non-fungible tokens within the same contract.
Other options like ERC-223 or ERC-621 aim to improve usability. The former implements safeguards to prevent accidental token transfers, while the latter adds additional functions for increasing and decreasing token supply.
The ERC-20 standard has dominated the crypto asset space for many years, and the reasons are clear. With relative ease, anyone can deploy a simple contract to serve a wide range of use cases, including utility tokens and stablecoins. That said, ERC-20 does lack some of the features provided by other standards. It remains to be seen whether subsequent token standards will eventually take its place as the industry standard.
ERC-20 tokens are standardized digital assets built on Ethereum blockchain following specific technical rules. Unlike native cryptocurrencies like Bitcoin, ERC-20 tokens are created by smart contracts and represent value within the Ethereum network, enabling custom tokenomics and use cases.
ERC-20 tokens operate through smart contracts on Ethereum. They follow a standardized protocol that enables token transfers, balance tracking, and approvals. Each transaction is recorded on the blockchain, ensuring transparency and security while allowing users to send and receive tokens seamlessly.
ERC-20 defines a standardized interface for fungible tokens on Ethereum. Key features include: transfer of tokens between addresses, approval mechanism for spending, balance tracking, total supply management, and event logging. It ensures interoperability across wallets and decentralized applications.
Use Solidity smart contracts on Ethereum. Deploy via Remix IDE or Hardhat, implement ERC-20 standard interface with mint/transfer functions, then publish on mainnet. Requires gas fees for deployment.
ERC-20 is Ethereum's fungible token standard for interchangeable assets. BEP-20 is Binance Smart Chain's equivalent. ERC-721 creates non-fungible tokens (NFTs) with unique properties. Key difference: ERC-20 tokens are identical and divisible, while ERC-721 tokens are unique and indivisible.
Main risks include smart contract vulnerabilities, phishing attacks, private key theft, and fraudulent tokens. Use secure wallets, verify contract addresses, enable two-factor authentication, and only transact on legitimate platforms to protect your assets.











