Launch an ERC20 in 3 minutes

What you are deploying

An ERC20 is a fungible token contract: every unit is interchangeable, balances are tracked per address, and transfers follow the IERC20 interface that every wallet and DEX expects. Ethereum Toolset generates a contract that inherits OpenZeppelin's audited ERC20 implementation — you choose extensions on top, not a hand-rolled token from scratch.

ERC20 — base fungible token with transfer, approve, and balanceOf
Ownable — single admin address set at deploy time via constructor
Burnable — holders can destroy their own tokens (deflationary supply)
ERC20Permit (EIP-2612) — gasless approvals via off-chain signatures
ERC20Votes — checkpoints balances for on-chain governance weight

Choose the right extensions

Open the Token Creator and work through the extension checklist. For a project token that may later power a DAO, the recommended stack is Burnable + Permit + Votes. Skip Mintable unless you have a documented inflation schedule — unlimited mint keys are the most common governance failure mode.

Burnable — community can reduce circulating supply; no admin key required
Permit — users sign approvals off-chain; pairs with DEX routers that support permit()
Votes — required if you plan to deploy a Governor DAO later
Mintable — only enable with a hard cap or timelocked minter role
Pausable — emergency stop for transfers; use sparingly on fungible tokens

Configure extensions

Configure name, symbol, and supply

Set a human-readable name (e.g. "Acme Protocol Token") and a 3–5 character uppercase symbol (e.g. "ACME"). Enter initial supply in whole token units — the wizard multiplies by 10**decimals internally. The full supply is minted once to the owner address you provide; there is no hidden premine logic outside what you configure.

Name — displayed in wallets and block explorers; can include spaces
Symbol — short ticker; keep it unique to avoid confusion on aggregators
Decimals — default 18 matches ETH wei granularity; 6 is common for stablecoin-style UX
Initial supply — minted entirely to the owner at construction; plan allocations off-chain or via separate vesting contracts
Owner address — use a multisig or hardware wallet, not a hot deployer key

The generated constructor pattern

Ethereum Toolset emits a constructor that wires OpenZeppelin parents in the correct order and mints the initial supply in a single _mint call. This is the pattern every auditor expects — no custom transfer logic, no manual slot management.

AcmeToken.solsolidity

import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import {ERC20Burnable} from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol";
import {ERC20Permit} from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol";
import {ERC20Votes} from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Votes.sol";
import {Ownable} from "@openzeppelin/contracts/access/Ownable.sol";

contract AcmeToken is ERC20, ERC20Burnable, ERC20Permit, ERC20Votes, Ownable {
    constructor(address initialOwner)
        ERC20("Acme Protocol Token", "ACME")
        ERC20Permit("Acme Protocol Token")
        Ownable(initialOwner)
    {
        _mint(initialOwner, 1_000_000_000 * 10 ** decimals());
    }

    // Required overrides when combining Votes + Permit
    function _update(address from, address to, uint256 value)
        internal
        override(ERC20, ERC20Votes)
    {
        super._update(from, to, value);
    }
}

Connect wallet and deploy

Switch your wallet to the target network (Sepolia for testing, mainnet for production). Review the compiled bytecode summary and constructor arguments on the review step — these are ABI-encoded and sent to Etherscan during verification. Sign the deployment transaction and wait for confirmation.

Test on Sepolia first — deploy, transfer, burn, and test permit() before mainnet
Record the deployed address, tx hash, and owner address in your runbook
Constructor args are immutable — a typo in the owner address cannot be fixed without redeploying
Gas varies by extension count; Votes + Permit adds roughly 200–400k gas over plain ERC20

Deploy now

Verify on Etherscan automatically

After deployment, Ethereum Toolset submits the exact compiler input and constructor arguments to Etherscan's verification API. Verified source lets users read your contract, confirms you deployed the audited OpenZeppelin patterns, and enables the Read/Write Contract tabs for permit and delegate calls.

Verification matches bytecode — wrong compiler version or optimizer settings fail silently
Constructor arguments must be ABI-encoded exactly as deployed
Once verified, add the token logo and metadata on Etherscan's token update form
Share the contract link with your community so they can confirm extensions before interacting

Verification walkthrough

Post-deploy checklist

A successful deploy is the beginning, not the end. Transfer ownership to your multisig, renounce only if you truly want an immutable token, and plan liquidity and governance separately.

Transfer Ownable to a multisig via transferOwnership() — never leave admin on a hot key
If using Votes, publish delegate instructions and link to your future Governor guide
Distribute tokens via separate vesting contracts rather than manual transfers from the owner wallet
List the token on CoinGecko/CoinMarketCap only after liquidity and verification are live
Monitor Transfer events with the Event Decoder to audit large movements early

Governor DAO guide