Fixed Supply ERC-20 Launch Checklist

Write the invariant before writing Solidity: after deployment, totalSupply must equal the declared amount and no transaction may increase it. With OpenZeppelin ERC20, supply is created through _mint. A conventional fixed supply implementation calls _mint once in the constructor and contains no public, external, inherited, or role-gated mint entry point. ERC20Capped limits minting but does not by itself make supply fixed, because authorized minting can continue until the cap.

Convert the human amount to base units explicitly. For 100 million tokens at 18 decimals, the constructor mints 100_000_000 * 10 ** decimals(). Solidity integers have no decimal fraction. Keep this calculation visible in tests and deployment output so reviewers can reconcile the advertised amount with totalSupply.

Fixed supply says nothing about whether balances can be frozen, transfers taxed, accounts blocked, or the implementation upgraded. Audit inherited contracts and modifiers, not just functions named mint. A proxy administrator can replace a fixed implementation with a mintable one, so an upgradeable token is not credibly immutable unless the upgrade path and its controller are disclosed.

If ownership is needed for unrelated operations, list every owner capability and use a custody arrangement appropriate to the team. Renouncing ownership removes only functions protected by that ownership mechanism. It does not remove separate AccessControl roles, proxy admin rights, or external dependencies. Query each role onchain after deployment rather than relying on deployment script intent.

Unit tests should assert the initial recipient, exact totalSupply, transfer behavior, allowance behavior, and expected reverts. Search the ABI for unexpected administrative methods. Test the deployment script against a local fork or test network using the same constructor inputs, compiler version, optimizer runs, EVM target, and library addresses intended for the final chain.

On Base or another EVM network, record chain ID, deployer, transaction hash, contract address, bytecode hash, compiler settings, constructor arguments, and repository revision. Wait for sufficient confirmation before publishing the address. A valid transaction on the wrong chain can look convincing in a screenshot, so always pair an address with its network.

Run the checklist from a clean checkout and have a second person compare the results against the written specification. Evidence should be readable without access to private tooling.

• Freeze the name, symbol, decimals, human supply, base-unit supply, and initial recipient.
• Confirm there is one intended _mint call and no reachable mint, rebasing, reflection, or upgrade path that can increase supply.
• Run tests for total supply, balances, transfers, allowances, zero-address behavior, and privileged functions.
• Deploy with recorded compiler settings and verify source plus constructor arguments on the explorer.
• Read totalSupply, decimals, owner, roles, proxy slots, and recipient balance directly from the deployed contracts.
• Publish the canonical network, address, repository revision, allocation plan, vesting contracts, and known controls.

This checklist covers the technical supply property of a conventional ERC-20 and the evidence around deployment. It does not assess token economics, market demand, custody quality, tax treatment, regulatory classification, or contract security as a whole. Source verification proves that published source corresponds to deployed bytecode under stated settings; it is not an audit. A fixed totalSupply also does not prevent concentrated ownership, lost keys, bridged representations, or misleading offchain claims.