Web3 Development · 5 min read ·

Token Launch Checklist: ERC-20 Contract to Mainnet

A practical ERC-20 token launch checklist covering contract design, audits, tooling, liquidity, deployment, verification, and post-launch operations on Ethereum mainnet.

Launching an ERC-20 token isn’t “deploy a contract and tweet.” Most failures happen in the boring middle: mis-specified token mechanics, sloppy role management, unverified contracts, broken liquidity setup, and missing operational runbooks. Below is a pragmatic checklist we use at ChainMagic Studio to take an ERC-20 from spec to Ethereum mainnet with fewer surprises.

1) Start with a token spec, not a Solidity file

Before code, define the contract’s behavioral guarantees in plain English. Your spec should answer:

  • Supply model: fixed supply vs. mintable vs. capped minting. If mintable, who mints, under what conditions, and can minting be permanently disabled?
  • Transfer rules: fully permissionless, allowlist/denylist, transfer fees, max wallet, cooldowns. (Be honest: most “anti-bot” rules harm UX and integrations.)
  • Admin powers: what can be changed post-launch? If “owner can pause transfers,” specify when and how you plan to relinquish that power.
  • Upgradeability: immutable contract vs proxy. Immutability is simpler and trust-minimizing; proxies demand stronger governance and monitoring.
  • Token economics + distribution: allocations, vesting schedules, cliffs, unlock cadence, and whether team/treasury tokens live in timelocks.

If you can’t explain your token’s edge cases to an exchange or auditor in one page, you’re not ready to code.

2) Choose a battle-tested ERC-20 implementation

Re-inventing ERC-20 is where subtle bugs breed. Use OpenZeppelin:

  • ERC20 as the base
  • ERC20Capped, ERC20Burnable, Pausable, AccessControl as needed
  • Prefer AccessControl over a single Ownable when you have multiple operators

Avoid “tax tokens” and reflection mechanics unless you have a strong reason and have tested across real DEX flows. Transfer hooks and fee-on-transfer behavior frequently break integrations (routers, lending protocols, payment processors).

3) Design roles and governance like an adversary

Role design is a security system. Common roles:

  • DEFAULT_ADMIN_ROLE: should be a multisig, not an EOA
  • MINTER_ROLE / PAUSER_ROLE: only if required; keep scope narrow
  • UPGRADER_ROLE (proxy only): ideally behind a timelock

Checklist:

  • Every privileged function must be justified and documented.
  • Create a role revocation plan: which roles will be renounced, when, and by which transaction.
  • If you’re using a proxy, treat upgrades as production deploys: versioning, changelogs, and time-delayed governance.

4) Implement distribution safely (vesting, airdrops, treasury)

Most “token hacks” are actually distribution mistakes.

  • Vesting: Use audited vesting contracts (e.g., OpenZeppelin vesting patterns or established vesting protocols). Avoid hand-rolled vesting logic.
  • Treasury custody: Use a multisig (Gnosis Safe) with a sensible threshold (e.g., 2/3 or 3/5). Document signer key management.
  • Airdrops: Prefer Merkle claim contracts over massive on-chain loops. Test claim UX and edge cases (double-claims, partial claims, invalid proofs).

Real-world example: projects often allocate liquidity but forget to transfer tokens to the deployer/multisig before creating pools. That turns launch hour into a scramble of hotfixes.

5) Testing: cover integration realities, not just unit tests

A token “works” when it behaves correctly under DEX routers, multisigs, and real wallets.

Minimum test suite:

  • Unit tests: mint/burn, transfers, allowances, transferFrom, role changes
  • Invariant/property tests: supply never exceeds cap; balances conserved except mint/burn
  • Fork tests: run against a mainnet fork to simulate Uniswap pool creation, adding liquidity, swaps, and approvals
  • Event correctness: analytics and explorers rely on events; don’t break expectations

Tooling we like: Foundry for speed + fuzzing; Hardhat if your team is invested in its plugin ecosystem.

6) Security review: audit scope and “pre-audit hygiene”

Audits are not a magic stamp; they’re a structured review. You still need:

  • Slither/Mythril static analysis
  • Dependency pinning (lock OpenZeppelin versions)
  • No hidden backdoors: avoid “rescue” functions that can drain user funds or arbitrary transfer hooks
  • Threat model: list attacker types (MEV bots, compromised admin keys, malicious integrators)

If budget allows, do an independent audit for anything beyond vanilla ERC-20. If you can’t afford a full audit, restrict features and keep the contract immutable.

7) Pre-deployment: finalize parameters and environments

Before mainnet:

  • Confirm token name/symbol/decimals (18 is standard; deviations break assumptions)
  • Freeze addresses: multisig, timelock, treasury, vesting admin, fee recipient (if any)
  • Establish deployment keys policy (hardware wallets; minimal exposure)
  • Rehearse on Sepolia and on a mainnet fork with the exact parameters

Write a deployment runbook with each transaction listed in order and the expected resulting state.

8) Mainnet deployment: deterministic, verifiable, repeatable

Mainnet deployment checklist:

  • Use a clean machine environment and pinned compiler settings
  • Save artifacts: bytecode, ABI, compiler version, optimizer runs
  • Consider CREATE2 if you need deterministic addresses (and can manage complexity)

Immediately after deployment:

  • Verify on Etherscan (source + constructor args)
  • Publish your ABI and integration notes
  • Tag the release in your repo and store deployment metadata (chainId, addresses, tx hashes)

Unverified contracts are a credibility hit and slow down exchange and wallet integrations.

9) Liquidity and market mechanics (Uniswap V2/V3)

Liquidity is where many launches implode.

Decide:

  • V2 vs V3: V2 is simpler for broad liquidity; V3 is capital-efficient but requires active management.
  • Initial price discovery: fixed price liquidity, Dutch auction, or third-party launch platforms.

Operational checklist:

  • Create the pair/pool with correct token ordering
  • Add liquidity from the treasury/multisig, not from a random EOA
  • If locking liquidity, understand what you’re locking (V2 LP tokens vs V3 NFT positions)
  • Test a buy and sell flow with a fresh wallet

Be cautious with “anti-bot” launch tricks. MEV is real, but restrictive transfer logic often blocks legitimate routers and wallets.

10) Post-launch operations: monitoring, upgrades, and incident response

The launch is the beginning of production operations.

  • Monitoring: track transfers, large holder movements, liquidity changes, and role events. Use tools like Tenderly, OpenZeppelin Defender, and custom alerts.
  • Admin key security: multisig signers with hardware wallets; rotate compromised keys immediately.
  • Incident runbook: pausing (if available), communications plan, and criteria for rolling forward vs. freezing.
  • Documentation: publish token address, decimals, verification link, and official channels to reduce phishing.

If you planned to renounce ownership or revoke roles, do it on schedule—and announce it with transaction links.

Conclusion: the best token launches are boring

A successful ERC-20 mainnet launch is mostly disciplined execution: a crisp spec, minimal features, tight role management, real-world testing (DEX flows), verifiable deployments, and an ops plan that assumes things will go wrong. If you want the launch to feel exciting, make the product exciting. Make the token contract boring.