Complete Guide to ERC-20 Contracts

·

Ethereum has revolutionized digital ownership by enabling developers to create custom tokens that power decentralized applications, governance systems, and financial instruments. Among the most widely adopted standards on the Ethereum blockchain is ERC-20, a technical specification for fungible tokens—essentially digital currencies within the ecosystem.

This comprehensive guide dives deep into the inner workings of ERC-20 contracts, using OpenZeppelin’s widely trusted implementation as a reference. Whether you're building your own token, auditing smart contracts, or simply seeking to understand how blockchain-based assets function, this article provides clear, actionable insights grounded in real-world code.

By the end, you'll grasp not only how ERC-20 works but also the security considerations, design patterns, and best practices that make it both powerful and safe when implemented correctly.

Understanding the ERC-20 Standard

The ERC-20 (Ethereum Request for Comments 20) standard defines a common set of rules that all Ethereum-based tokens must follow. This ensures interoperability across wallets, exchanges, decentralized finance (DeFi) platforms, and other smart contracts.

Instead of every token having a unique interface, ERC-20 creates uniformity. As a result, any application that supports ERC-20—like MetaMask or Uniswap—can automatically support new tokens without additional development.

👉 Discover how blockchain assets are traded securely with advanced tools.

The Role of Interfaces in Smart Contracts

To achieve consistency, ERC-20 relies on an interface—a blueprint that specifies which functions a contract must implement. While interfaces don't contain logic, they ensure all compliant contracts expose the same methods.

OpenZeppelin's IERC20.sol is the most widely used interface definition. It translates the human-readable EIP-20 specification into Solidity code.

Here’s a breakdown of its core components:

pragma solidity >=0.6.0 <0.8.0;

This line specifies the Solidity compiler version range. Pinning both minimum and maximum versions prevents unexpected behavior due to breaking changes in newer releases—a crucial step for security and predictability.

Core Functions Defined in IERC20

Events: Keeping the Network Informed

Smart contracts emit events to notify external systems of state changes:

event Transfer(address indexed from, address indexed to, uint256 value);
event Approval(address indexed owner, address indexed spender, uint256 value);

These events allow off-chain applications like wallets and explorers to track transactions and approvals in real time.

Inside the ERC-20 Contract Implementation

While the interface defines what a token should do, the actual contract implements how. OpenZeppelin's ERC20.sol provides a secure, extensible foundation built around best practices.

Let’s explore its structure and functionality.

Import Statements and Dependencies

import "../../GSN/Context.sol";
import "./IERC20.sol";
import "../../math/SafeMath.sol";
🔐 Security Note: Before Solidity 0.8.0, arithmetic operations could wrap around silently (e.g., 0 - 1 = 2^256 - 1). SafeMath mitigates this risk by reverting on unsafe calculations.

State Variables: Tracking Token Data

All persistent data in a smart contract is stored in state variables, declared at the contract level:

mapping(address => uint256) private _balances;
mapping(address => mapping(address => uint256)) private _allowances;
uint256 private _totalSupply;
string private _name;
string private _symbol;
uint8 private _decimals;

Each serves a specific purpose:

📌 Important: Despite being marked private, these values are not secret. Everything on the blockchain is public and readable by anyone.

What Are Decimals?

Tokens often need divisibility—just like dollars have cents. Ethereum uses wei, where 1 ETH = 10¹⁸ wei.

The _decimals field defines how many digits come after the decimal point. Most tokens use 18, matching ETH, but some use 6 or 9 depending on use case.

For example:

Constructor: Initializing the Token

constructor(string memory name_, string memory symbol_) public {
    _name = name_;
    _symbol = symbol_;
    _decimals = 18;
}

The constructor runs once when the contract is deployed. It sets the token’s name and symbol. By convention, parameters end with _ to distinguish them from state variables.

💡 You can override _decimals during deployment if needed using _setupDecimals().

Public View Functions

These functions let external apps retrieve basic token info:

function name() public view returns (string memory) { return _name; }
function symbol() public view returns (string memory) { return _symbol; }
function decimals() public view returns (uint8) { return _decimals; }
function totalSupply() public view override returns (uint256) { return _totalSupply; }
function balanceOf(address account) public view override returns (uint256) { return _balances[account]; }

They are marked view, meaning they don’t modify state and can be called for free.

Token Transfers and Allowances

How transfer() Works

function transfer(address recipient, uint256 amount) public virtual override returns (bool) {
    _transfer(_msgSender(), recipient, amount);
    return true;
}

Rather than handling logic directly, transfer() delegates to _transfer(), an internal function. This pattern minimizes code duplication and reduces audit surface area.

Using _msgSender() instead of msg.sender ensures compatibility with meta-transactions (gasless transactions).

The Internal _transfer Function

function _transfer(address sender, address recipient, uint256 amount) internal virtual {
    require(sender != address(0), "ERC20: transfer from the zero address");
    require(recipient != address(0), "ERC20: transfer to the zero address");
    _beforeTokenTransfer(sender, recipient, amount);
    _balances[sender] = _balances[sender].sub(amount, "ERC20: transfer amount exceeds balance");
    _balances[recipient] = _balances[recipient].add(amount);
    emit Transfer(sender, recipient, amount);
}

Key points:

👉 Learn how secure digital asset management powers modern DeFi platforms.

Secure Allowance Management

Allowances enable third-party spending—critical for DeFi interactions like swapping tokens on Uniswap.

The Risk of Front-Running

A major vulnerability arises when updating allowances from non-zero to non-zero values:

  1. Alice sets Bill’s allowance to 5 tokens.
  2. Later, she increases it to 10.
  3. Bill sees her transaction and front-runs it by spending the first 5 before the update confirms.
  4. Then he spends another 10—totaling 15, exceeding Alice’s intent.

This exploit is known as front-running and occurs because transaction ordering isn’t guaranteed on Ethereum.

OpenZeppelin’s Solution: increaseAllowance and decreaseAllowance

Instead of setting allowances directly, these helper functions adjust them incrementally:

function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
    _approve(_msgSender(), spender, _allowances[_msgSender()][spender].add(addedValue));
    return true;
}

function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
    _approve(_msgSender(), spender, _allowances[_msgSender()][spender].sub(subtractedValue));
    return true;
}

This approach eliminates the race condition:

Minting and Burning Tokens

Two key internal functions control supply:

_mint(address account, uint256 amount)

Creates new tokens:

function _mint(address account, uint256 amount) internal virtual {
    require(account != address(0), "ERC20: mint to the zero address");
    _beforeTokenTransfer(address(0), account, amount);
    _totalSupply = _totalSupply.add(amount);
    _balances[account] = _balances[account].add(amount);
    emit Transfer(address(0), account, amount);
}

Note: Minting emits a Transfer from address(0)—indicating newly created tokens.

_burn(address account, uint256 amount)

Destroys existing tokens:

function _burn(address account, uint256 amount) internal virtual {
    require(account != address(0), "ERC20: burn from the zero address");
    _beforeTokenTransfer(account, address(0), amount);
    _balances[account] = _balances[account].sub(amount);
    _totalSupply = _totalSupply.sub(amount);
    emit Transfer(account, address(0), amount);
}

Burning reduces total supply and emits a transfer to address(0).

⚠️ These functions are internal—they must be exposed via custom logic in derived contracts (e.g., staking rewards or deflationary mechanisms).

Hook Functions: Extending Behavior Safely

OpenZeppelin includes _beforeTokenTransfer(), a hook function called before every transfer:

function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual {}

It’s empty by default but can be overridden to add logic such as:

Because it runs before state changes, it helps enforce business rules without modifying core functions.

Frequently Asked Questions (FAQ)

Q: Can anyone see my token balance?
A: Yes. All data on Ethereum is public. Even private variables can be read directly from storage—there are no secrets on-chain.

Q: Why use SafeMath if Solidity 0.8+ has built-in checks?
A: In Solidity versions before 0.8.0, arithmetic operations didn’t revert on overflow/underflow. SafeMath fills that gap. If you're using 0.8+, native math is safe by default.

Q: What happens if I lose my private key?
A: You lose access permanently. There is no recovery mechanism for Ethereum addresses or token holdings.

Q: Can I change a token’s name after deployment?
A: No. Once deployed, all state—including name and symbol—is immutable unless explicitly designed otherwise (which breaks ERC-20 expectations).

Q: How do wallets know how many decimals my token uses?
A: Wallets call the decimals() function automatically and format balances accordingly.

Q: Is it safe to approve large allowances?
A: Only if you trust the contract. If compromised, an approved spender could drain your balance. Always review contracts before approving spending.

👉 Stay ahead with secure crypto tools trusted globally.

Final Thoughts

Understanding ERC-20 contracts is essential for anyone involved in Ethereum development or DeFi participation. OpenZeppelin’s implementation sets a gold standard for security and maintainability through:

When building your own token, always inherit from audited libraries rather than writing from scratch. Audit only what you modify—and do so rigorously.

With this knowledge, you’re equipped to design secure tokens, interact confidently with DeFi protocols, and contribute meaningfully to the evolving Web3 landscape.

Core Keywords: ERC-20 contract, Ethereum token standard, OpenZeppelin ERC20, Solidity smart contract, blockchain token development, DeFi token guide, SafeMath library