The gap between deploying an ERC-20 token and launching one successfully is where most projects come unstuck. The contract itself is the easy part — it's a few hundred lines of well-audited Solidity. The hard parts are the tokenomics, the vesting mechanics, the liquidity strategy, the regulatory question you haven't answered yet, and the audit that will take longer than you budgeted.
This checklist covers the full stack: technical, operational, and legal. Work through it before you deploy to mainnet.
Technical: the smart contract layer
Token contract fundamentals
A standard ERC-20 implementation from OpenZeppelin is the right starting point. Do not write the base token logic from scratch. You should extend it, not replace it.
Decisions you need to make before deployment:
- Fixed vs mintable supply: Can new tokens be minted after deployment? By whom? Under what conditions?
- Burnable: Can tokens be burned? By the holder, or only by a privileged role?
- Pausable: Can token transfers be paused? This is common for compliance reasons but requires a trusted admin key
- Access control: Who holds admin, minter, and pauser roles? Multisig, timelock, or DAO governance?
- Blacklisting: Required for some regulated tokens; a significant centralisation trade-off for others
Vesting and token distribution contracts
If tokens are being allocated to team, advisors, or investors, vesting contracts are non-negotiable. A cliff-plus-linear-vesting pattern is standard:
- Cliff period (e.g. 6–12 months): no tokens release
- Linear vesting over the remaining period (e.g. 24–36 months): tokens release proportionally
The vesting contract should be separate from the token contract and should allow the recipient to claim tokens when vested — not push them automatically, which wastes gas.
Deployment checklist
- Deploy and test on a public testnet (Sepolia for Ethereum)
- Verify contract source code on Etherscan
- Confirm constructor arguments match intended supply and initial distribution
- Test all minting, burning, and pause functions if applicable
- Set up Gnosis Safe multisig for all admin roles before mainnet deployment
- Time-lock admin role changes (48–72 hour delay minimum for upgradeable contracts)
Security: the audit
No token that will hold real value should launch without an independent smart contract audit. This is not optional.
What an audit covers:
- Reentrancy vulnerabilities
- Integer overflow/underflow (less common with Solidity 0.8+ but still relevant in assembly)
- Access control flaws
- Logic errors in custom mechanics (vesting, staking, bonding curves)
- Denial-of-service vectors
What an audit does not cover:
- Tokenomic design (whether the model is sustainable)
- Legal classification of the token
- Market manipulation risks
Reputable audit firms include Trail of Bits, OpenZeppelin, Certik, Hacken, and Code4rena for competitive audits. Allow 3–6 weeks for the process and budget for remediation time — most audits find at least a few medium-severity issues that need fixing before resubmission.
Liquidity: Uniswap and beyond
Getting your token listed on a DEX requires creating a liquidity pool. On Uniswap v3, this means:
- Choosing a fee tier (0.05%, 0.3%, or 1%) — most new tokens use 1%
- Providing initial liquidity in an ETH/token or USDC/token pair
- Deciding whether to use liquidity locking (time-locked LP tokens signal commitment to investors)
A common mistake: launching with insufficient initial liquidity, which makes the token trivially price-manipulable in the first hours. Even modest liquidity (relative to market cap) significantly reduces this risk.
If you plan to apply for CEX listings, most exchanges require an audit report, a whitepaper, a working product or clear roadmap, and a minimum liquidity/market-cap threshold.
Legal: the questions you must answer first
| Question | Why it matters |
|---|---|
| Is this token a security in the jurisdictions where you'll sell or market it? | Securities tokens require registration or an exemption (Reg D, Reg S in the US) |
| Are you selling to US persons? | US securities law has extraterritorial reach; many projects geo-block US IPs |
| Do your team/advisor allocations require a lockup from a legal perspective? | Some jurisdictions treat unrestricted team token unlocks as a market manipulation risk |
| Do you need to implement KYC for token sale participants? | Required for most SAFT or private sale structures |
| What's your DAO/governance structure and is it legally recognised? | DAOs are increasingly treated as general partnerships in the US absent formal structure |
This is not legal advice — it's a list of questions you need to answer with qualified legal counsel before launch. The legal work typically takes as long as the technical work.
How we build token launch systems
Our blockchain development service covers the full technical stack: ERC-20 contracts with custom mechanics, vesting and distribution systems, staking integrations, and audit preparation. We write clean, well-documented Solidity that auditors can work through efficiently — which reduces the cost and duration of the audit process.
We don't advise on tokenomics or legal structure, but we work alongside founders who are managing those advisors in parallel, and we coordinate timelines so the technical build doesn't block the legal review or vice versa.
The short version
An ERC-20 token launch is a contract deployment, a vesting system, a liquidity strategy, an audit, and a legal analysis — all of which need to happen in the right order. The token contract is the shortest part of the timeline. The audit and legal review are the longest. Build the checklist before you start, not after the contract is already on mainnet.