The ERC-20 standard is the foundation of the token economy on Ethereum and EVM-compatible chains. It defines a common interface that allows tokens to be transferred, approved for spending by third parties, and integrated with wallets, exchanges, and DeFi protocols. Creating a token is straightforward, but doing it correctly — with proper security, tokenomics, and regulatory awareness — requires careful planning.
The ERC-20 Interface
The ERC-20 standard specifies six mandatory functions: totalSupply, balanceOf, transfer, transferFrom, approve, and allowance. It also defines two events: Transfer and Approval. These functions enable basic token operations — checking balances, transferring tokens directly, and authorising third-party contracts to spend tokens on behalf of the holder. The approve-transferFrom pattern is how DeFi protocols interact with tokens: a user approves a contract to spend a certain amount, then the contract calls transferFrom to move tokens during operations like swaps or deposits. Most implementations today extend the standard with additional features like minting, burning, pausing, and permit (gasless approvals via EIP-2612).
Implementation with OpenZeppelin
OpenZeppelin provides audited, battle-tested implementations of ERC-20 and its common extensions. Rather than writing token logic from scratch, inherit from their contracts:
- ERC20Burnable: Allows token holders to destroy their own tokens, reducing total supply. Useful for deflationary mechanics.
- ERC20Pausable: Enables an authorised address to pause all token transfers. Critical for emergency response during security incidents.
- ERC20Permit: Implements EIP-2612 gasless approvals, allowing users to approve token spending via off-chain signatures rather than on-chain transactions.
- ERC20Votes: Adds governance capabilities with delegation and voting power tracking based on token balance snapshots.
Deployment and Verification
Deploy using Hardhat or Foundry with a well-tested deployment script. Always deploy to a testnet first — Sepolia for Ethereum, Mumbai for Polygon — and verify all functionality before mainnet deployment. Verify the contract source code on Etherscan or the relevant block explorer immediately after deployment. Verified source code builds trust and allows users and auditors to review the contract. Configure constructor arguments carefully: token name, symbol, initial supply, and any admin addresses. Consider using a proxy pattern (UUPS or Transparent Proxy) if you anticipate needing to upgrade the contract, though this adds complexity and trust assumptions.
Regulatory Considerations
Creating a token is a technical exercise, but distributing it is a regulatory one. Under Malta's VFA framework and the EU's MiCA regulation, tokens may be classified as virtual financial assets, utility tokens, or electronic money tokens, each with different compliance requirements. A token offering may require a whitepaper approved by a VFA agent, registration with the MFSA, and compliance with prospectus requirements depending on the offering size. At Born Digital, we advise our clients to engage legal counsel before any token launch. We handle the technical implementation — smart contract development, auditing, deployment, and exchange integration — while working alongside legal teams to ensure compliance.