Creating an Ethereum token means deploying a smart contract that implements a standard interface, usually ERC-20 for fungible tokens or ERC-721 and ERC-1155 for NFTs, so that wallets, exchanges and DeFi protocols can work with it automatically. Writing the contract takes days. Getting the design, security, distribution and legal position right is where the real work is.
This guide walks through the decisions in the order you will face them, with honest notes on where projects usually go wrong.
Start with why the token exists
Before choosing a standard, write one sentence describing what the token does that a database entry or a payment in an existing currency could not. Good answers include: it represents a share in a pooled vault, it is required to use a protocol, it gives governance rights over a treasury, it is a transferable claim on a real asset, or it is a collectible whose ownership must be portable between applications. Weak answers ("to raise money", "every project has one") tend to produce tokens with no lasting demand and, in many jurisdictions, regulatory exposure.
Choosing the right token standard
Standards are defined as Ethereum Improvement Proposals (EIPs). Implementing the standard exactly is what makes your token work in MetaMask, on Uniswap and in custody systems without custom integration. The canonical text for the fungible standard is EIP-20.
| Standard | What it represents | Typical uses | Notes |
|---|---|---|---|
| ERC-20 | Interchangeable units with balances | Utility, governance, stablecoins, reward points | Most widely supported; pair with ERC-2612 permit for gasless approvals |
| ERC-721 | Unique items, one owner each | Art, collectibles, membership passes, deeds | Metadata via tokenURI; storage of media off-chain is the norm |
| ERC-1155 | Many token types in one contract, fungible or not | Game items, editions, ticket tiers | Batch transfers save gas; marketplace support is good but slightly behind ERC-721 |
| ERC-4626 | Shares in a yield-bearing vault | Lending deposits, staking vaults, yield strategies | Standardizes deposit, withdraw and share accounting; watch for inflation attacks on empty vaults |
| ERC-2981 | Royalty information for NFTs | Creator royalties | Signals royalty amounts; payment is up to the marketplace |
| ERC-3643 and similar permissioned standards | Transfer-restricted tokens tied to verified identities | Security tokens, regulated real-world assets | Transfers check an on-chain identity registry and compliance rules |
You will still see older proposals such as ERC-223 and ERC-777 offered as "upgrades" to ERC-20. ERC-223 never became a finalized standard with broad support, and ERC-777's hooks introduced reentrancy risk that contributed to real exploits; OpenZeppelin removed its ERC-777 implementation in Contracts 5.0. For new projects, ERC-20 plus ERC-2612 is the safer choice.
If you are building NFTs specifically, the guide to NFT token development goes deeper on metadata, minting mechanics and marketplaces.
Design decisions inside an ERC-20
Supply model
Fixed supply minted once at deployment is the simplest and easiest to trust. A mintable token needs a clear answer to who can mint, under what limits and with what oversight. Many teams combine a hard cap enforced in code with a minter role held by a vesting or emissions contract rather than a person.
Decimals
Eighteen decimals is the convention and what most tooling assumes. Stablecoins sometimes use six to mirror cent-level precision. Whatever you choose, integrators must handle it correctly, and mistakes here have caused real pricing bugs in DeFi.
Access control and admin powers
Every admin function (mint, pause, blacklist, upgrade) is both a feature and a risk. Use role-based access control rather than a single owner, place roles behind a multisig, and add a timelock so holders can see changes before they take effect. If you intend the token to be decentralized, renounce roles you do not need once launch is complete.
Pausing and blocklisting
Regulated stablecoins and security tokens usually need the ability to freeze addresses; community tokens usually should not have it. Decide deliberately, document it, and expect sophisticated holders to check.
Upgradeability
Proxies (transparent or UUPS) let you fix bugs after launch, but they also let administrators change the rules. For a simple ERC-20, an immutable contract built on audited libraries is often the better trade. For complex logic or regulated assets, upgradeability with a timelock and multisig is common.
Things to avoid
- Transfer taxes and reflection mechanics. They break many DeFi integrations, confuse accounting and are frequently associated with scams.
- Hidden owner privileges or functions that can change balances.
- Rewriting standard logic from scratch instead of building on audited implementations such as OpenZeppelin Contracts.
Tokenomics and distribution
The contract is the easy part. Distribution decides whether the token is credible. Write down allocations (team, investors, community, treasury, liquidity), vesting schedules enforced by contract rather than promises, and what creates ongoing demand. Common mechanics include:
- Vesting contracts with cliffs and linear release for team and investors.
- Merkle airdrops, where a root of eligible addresses is stored on-chain and users claim with proofs, which is far cheaper than sending to each address.
- Liquidity provisioning on a DEX, with LP tokens locked or held by a transparent treasury.
- Governance via ERC-20 votes extensions and on-chain governor contracts, if holders will control parameters.
Projects whose token is central to a DeFi protocol should also read the guide to DeFi token development.
Mainnet or layer 2?
Ethereum mainnet offers the deepest liquidity and strongest security, but every transfer pays mainnet gas. Layer 2 rollups such as Arbitrum, Optimism, Base and ZKsync Era inherit much of Ethereum's security and make transfers far cheaper, which matters for tokens used in frequent, small transactions. Many projects deploy on mainnet and use the canonical bridge for L2 representations, or launch natively on one L2. Avoid deploying the same token independently on several chains without a clear bridging model; you end up with multiple unconnected supplies. The guide to scaling with layer 2 and interoperability covers the trade-offs.
The development process
- Specification. Document the standard, supply, roles, admin powers, upgrade policy, vesting and distribution. This document is what your auditor will check the code against.
- Implementation. Build on audited libraries, pin the compiler version, and keep custom logic minimal.
- Testing. Unit tests for every function and role, fuzz tests on transfers and approvals, and invariant tests (total supply always equals the sum of balances, the cap is never exceeded).
- Testnet deployment. Deploy to Sepolia or the relevant L2 testnet, run the full launch sequence including vesting and airdrop claims, and let others try to break it.
- Audit. Even a standard token benefits from an independent review of configuration and admin powers; anything custom requires one. See smart contract audits.
- Mainnet deployment. Deploy from a secure machine or hardware wallet, verify the source on a block explorer, and transfer roles to the multisig immediately.
- Post-launch. Publish contract addresses in one canonical place, submit token metadata to wallets and explorers, monitor admin functions, and keep an incident plan.
Cost and timeline
These are estimates with the assumptions stated, not quotes:
| Scope | Assumed effort | Typical timeline |
|---|---|---|
| Standard ERC-20 from audited libraries, fixed supply, multisig ownership | One experienced Solidity developer, light review | One to two weeks including testing and deployment |
| ERC-20 with vesting, airdrop claims, governance votes | One to two developers plus an external audit | Four to eight weeks |
| Permissioned security token with identity registry and compliance rules | Smart contract, backend and compliance engineers; legal involvement | Several months |
Audit fees scale with code size and complexity, so the cheapest way to reduce them is to write less custom code. Gas for deployment depends on network conditions and is small relative to everything else on L2s.
Legal and regulatory considerations
How a token is marketed and sold matters as much as what the code does. In the United States, the SEC and courts apply securities-law tests to token sales, and payment stablecoins now have a dedicated federal framework under the GENIUS Act signed in July 2025. In the European Union, MiCA regulates crypto-asset issuers and service providers, with specific rules for asset-referenced and e-money tokens and requirements such as a white paper for many public offerings. Tokens representing shares, debt or fund interests are generally securities in most jurisdictions and need the corresponding regime; the guide to security token offerings covers that route. Plan KYC, sanctions screening and geographic restrictions into the sale mechanics, not as an afterthought.
Common failure modes
- A single externally owned account holds mint or upgrade rights and its key is compromised.
- Liquidity is thin, so a small sale crashes the price and the project spends its treasury defending it.
- Vesting is promised in a document but not enforced in a contract, and holders lose trust.
- Fee-on-transfer logic breaks integrations with DEXs and lending markets.
- The token is launched on several chains with separate supplies and no reconciliation.
For fungible tokens on other networks, compare with BEP-20 tokens on BNB Smart Chain. If your token is meant to hold a stable value, the design problems (reserves, redemption, attestations) are different enough to need their own planning.
Frequently asked questions
How much does it cost to deploy an ERC-20 token?
The deployment transaction itself costs gas, which varies with network congestion and is much cheaper on layer 2s than on mainnet. The larger costs are development, testing, audit and legal work, which together dominate any deployment fee.
Can I create a token without writing code?
Token generator tools exist and can produce standard contracts. They are fine for experiments. For anything holding real value, you still need to understand the admin powers the generated contract includes and who controls them.
Can I change my token after deployment?
Only if it was deployed behind an upgradeable proxy or has parameters controlled by admin roles. An immutable token cannot change; you would need to deploy a new one and migrate holders.
What is the difference between ERC-20 and ERC-1155?
ERC-20 contracts each manage one fungible token. ERC-1155 manages many token IDs in one contract, each of which can be fungible or unique, with batch operations. Use ERC-20 for a single currency-like token and ERC-1155 for collections of items.
How do I get my token listed on exchanges?
Anyone can create a liquidity pool on a decentralized exchange. Centralized exchanges run their own due-diligence and listing processes, including legal review. Treat any service that promises a listing for a fee with caution.
Do I need an audit for a simple ERC-20?
If you use audited library code unchanged and keep admin powers minimal, a careful review of configuration may be enough. Any custom logic, vesting, staking or fee mechanics should be audited before mainnet.