Since Ethereum grew in adoption, standards had to be created to create solid, cross-platform software apps. Ethereum Improvements Proposals (EIPs) are usually the way people discuss new standards for the blockchain development ecosystem. One such proposal is a standard for fungible tokens: ERC-20. Introduced in 2015, ERC-20 (also referred to as EIP-20) is the first and most popular token standard in Ethereum.
The ERC-20 token standard allows developers to create fungible tokens (i.e., that can be exchanged for one another) with smart contracts. This standard has become a popular way to create tokens on the Ethereum blockchain, leading to the creation of a wide variety of digital assets for different purposes.
ERC-20 defines a set of API methods and events to ensure that all tokens created using this standard are compatible with other Ethereum tokens. The API methods are:
totalSupply(): Returns the total number of tokens in circulation;
balanceOf(address _owner): Returns the token balance of a specific address;
transfer(address _to, uint256 _value): Transfers a specified number of tokens from the senderβs account to the specified recipient;
transferFrom(address _from, address _to, uint256 _value): Allows a third party to transfer tokens from one account to another;
approve(address _spender, uint256 _value): Enables a token owner to permit a third party to spend tokens on their behalf;
allowance(address _owner, address _spender): Returns the number of tokens that an account is allowed to spend on behalf of a token owner.
The events defined in the ERC-20 standard include:
Transfer: Triggered when tokens are transferred between accounts;
Approval: Triggered when a token owner approves another account to spend tokens on their behalf.
Besides all those methods and events, ERC-20 tokens also have these three important fields:
name: The name of the token (e.g Binance USD);
symbol: The ticker that represents the currency (e.g BUSD);
decimals: The number of decimals supported when displaying balances to humans.
Required Tools For Building Your Own Token
Building a brand new ERC-20 token doesnβt really require a huge setup, you can do everything from your own browser using Remix, for example. Remix is a complete IDE for Solidity development that runs on the browser and can handle nearly all simple projects. Although Remix is not recommended for more complex projects, you can use its tools for interacting with your smart contracts and building POCs without spending much time setting up a development environment.
For more complex and bigger projects, using a framework like Hardhat (for JS/TS developers) or Brownie (for Python devs) is probably the best path to follow. In this tutorial, we will cover the ERC-20 token creation process using Hardhat, so feel free to dive into its documentation to learn more about what it has to offer.
How To Create An ERC-20 Token
Now letβs get our hands on the code and build our brand new ERC-20 token. If you never created a smart contract before with Solidity, we recommend you to read this article, itβs a good introduction to this topic.
Step 0 β Installing Global Dependencies (optional)
In order to use Hardhat, you need to have NodeJS (and NPM) installed on your machine. If you donβt have it yet, install them from this source. NPM is installed together with NodeJS and should be available from your terminal after installation.
Step 1 β Setting Up the Development Environment
First of all, create a new folder where the project will be located. Once you have created the folder, run the following command inside it:
npx hardhat
If everything is fine, you should see something like this:
If you are proficient in TypeScript, donβt hesitate to create the project using TS, but for this article, we will select the JavaScript option by pressing enter/return. For the next questions, we will just press enter to use the default options. Once all questions were answered, NPM (Node Package Manager) will do the hard work installing all project dependencies and, yes, that can take some time, but donβt worry!
Step 2 β Knowing the Project Structure
After the setup process is done, you can open the project folder with an IDE (or modern text editors), and you will see this folder structure:
This is how Hardhat organizes new projects by default:
contracts: The folder containing all relevant source code (Solidity smart contracts);
scripts: Where useful scripts for interacting with the blockchain are located;
test: An important folder that will keep all automated tests for you to test your contracts and improve their security;
hardhat.config.js: All Hardhat settings are placed inside this file;
package.json: The file that stores general info about your project such as name, version, and dependencies;
package-lock.json: Used for storing info about your installed dependencies versioning. This file is generated automatically, and you should never edit this file manually.
And, of course, thereβs another folder: node_modules. That folder is handled automatically by the package manager and contains all external dependencies. You should never modify its content manually.
Now, if thatβs your first time using Hardhat, take some time to look into each of these folders and files to feel more comfortable with this structure.
Step 3 β Installing External Dependencies
As we talked before, standards like ERC-20 are discussed and improved by the community. One of the biggest organizations in this world is OpenZeppelin, a huge player that is responsible for developing some of these well-known standards. We will use their contracts to help us to develop our ERC-20 token.
For installing OpenZeppelinβs contracts, we will use this command:
npm install @openzeppelin/contracts --save-dev
We will use NPM because Hardhat comes with NPM by default and moving to Yarn requires more configurations. The --save-dev flag tells NPM that these dependencies should be used just for development and that these files should not be included in future JavaScript builds.
Step 4 β Creating the Smart Contract
After installing OpenZeppelinβs contracts, we will clean our folders, removing contents from contracts, scripts and tests. Once the project structure is clean, we will create a new file Token.sol. inside the contracts folder.
Now that we have our smart contract file created, we just have to fill it with useful code, right? So letβs start with the basics. This code will be the base to build our smart contract:
After writing that piece of code, letβs import the dependencies from OpenZeppelin and use it on our smart contract. For that, we should add this line to the top of the file (ideally, between the pragma version and contract declaration):
All dependencies were loaded, and now we can use them in the code. Letβs make our Token contract extend the ERC20 contract. For that, we use the is keyword to tell Solidity that the contract is extending another. Thatβs how it should like:
...
contract Token is ERC20 {
...
If your code editor is already working fine with Hardhat, you are probably seeing the following compilation error:
Thatβs because our contract should implement some features and initialize ERC20 inherited code. For that, we will use it on the constructor. Letβs add then the code to initialize the inherited contract code, and it will look like this:
// SPDX-License-Identifier: MIT
pragma solidity 0.8.17;
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
contract Token is ERC20 {
constructor() ERC20("Rocket Token", "ROCKET") {
}
}
The code is almost done, letβs just do one thing: mint some tokens at the time of deployment. We will call the _mint function from ERC20 to send one million tokens to the deployer:
Thatβs pretty much a functional ERC-20 token. If you deploy it, it will work fine, deploying a new token on the network with 1M supply. Easier than you thought, right? But we will now cover how to extend and modify some features from the ERC-20 standard.
Step 5 β Modifying and Extending Default ERC-20 Behaviors
Nowadays itβs very common to see some tokens with additional features like taxes and rewards directly built into their contracts. We will see now how to add some simple features to our smart contract.
Modification #1 β allowing users to burn their tokens:
After creating our script, we will add our wallet private keys to make a real transaction on the blockchain. For that, edit the hardhat.config.js file as the following:
In the case, we are using ETH Goerli Testnet. If you want to use a mainnet network, replace the goerli object with a valid network config.
Now you will need to input your walletβs mnemonic to use it to authenticate and deploy the smart contract to the network. Create a .env file in the root of the project with the following content:
MNEMONIC=rifle enter coyote much acid smooth dolphin stairs south cattle immense paper
The mnemonic here is random and is connected to a wallet without funds. Replace the content with a walletβs mnemonic with enough funds to cover the deployment expenses.
After all that, we should be able to run the deployment script with this command:
npx hardhat run scripts/deploy.js --network goerli
In this context, the name βgoerliβ refers to the name of the network inside the networks object defined in hardhat.config.js.
And thatβs the expected output:
We can now find the contract in the blockchain explorer:
We will verify the source code of the contract. The simplest way of doing that is flattening the contract code (joining all smart contracts into just one file) and uploading it to Etherscan. Letβs do it:
npx hardhat flatten > output.sol
The flattened code will be written in the βoutput.solβ file.
After clicking Verify and Publish, we select these values above
Before submitting our code, the flattened file probably has one issue: it has more than one SPDX license identifier. To solve that, we will remove all SPDX lines from the file except the first one.
Weβll let just the first of the five occurrences, removing others.
After solving the issue, weβll copy-paste it into the Etherscan verification step:
If everything is correct, you will see this message:
Now the contract code is verified, and itβs publicly visible to all users.
Compliance Concerns
Itβs very important to follow all ERC-20 standards. The specified behaviors from ERC-20 are trusted by all sources that implement ERC-20 tokens as part of the software. For example, yours should β and should only β emit Transfer events when transfers are performed between users. These events are trusted as proof of funds being moved between accounts and, if not properly executed, can be an issue for exchanges and wallets tracking transactions and balances.
Some other behaviors are expected to happen when dealing with ERC-20 tokens. Such as:
Transfers should return a bool value representing the transaction success;
Transfers of zero tokens should be treated as normal transfers and emit the Transfer event;
Minting and burnings are treated as transfers, so they should emit a Transfer event. When minting new tokens, _from is 0x0. When burning, _to is 0x0.
Always refer to the original documentation to avoid building contracts that break the ERC-20 standard.
Final Words
As covered in this article, creating an ERC-20 token smart contract can be simple, but still, itβs very tricky, and rules should be followed to avoid issues. One good way to check your contract compliance is by writing automated tests. Hardhat has a good testing suite of tools, and you can test everything that could happen with your smart contracts. Donβt hesitate to create lots of tests to ensure every single possible case.
For a developer, documentation is always your best friend. Always consult the official language documentation and the framework specification. Have fun and send your new token to some friends!
The blockchain industry has been grappling with scalability issues, which have hindered widespread adoption due to its technical constraints. As the demand for blockchain, decentralized applications (dApps), and transactions increases, the limitations of existing networks become increasingly apparent. High transaction fees and network congestion have plagued platforms like Ethereum, hampering their ability to support large-scale
The experimental semi-fungible token standard, ERC-404, combines elements from ERC-20 and ERC-721 tokens. Despite rising popularity, it has yet to secure an official Ethereum Improvement Proposal (EIP) designation. However, its unique attributes, such as enabling fractional ownership of NFTs and enhancing liquidity, coupled with the potential for automated NFT minting and burning processes, suggest a
Decentralized applications (dApps) are software that run on a decentralized network, often using blockchain technology. These applications can serve various purposes for end users, such as brokers, art collectors, traders, investors, and documents of public trust. However, their functionality and value attract malicious groups aiming to exploit vulnerabilities for financial gain. This article explores real-world examples of dApp security breaches, their attack vectors, and the lessons learned.