Questions, answered

ERC-20 is the standard interface for fungible tokens on Ethereum. Any contract that implements its required functions — total supply, balances, transfers, allowances — is an ERC-20 token, which means wallets, exchanges and block explorers already know how to read and display it.

No. You configure the token in the builder using plain-language settings, then deploy through your wallet. The contract is generated from standard ERC-20 architecture.

Configuration typically takes a few minutes. Deployment itself depends on the selected network's block times and the gas price you accept in your wallet — usually minutes, not hours.

Any self-custody Web3 wallet that can connect to EVM networks and sign transactions — for example MetaMask or Coinbase Wallet. The wallet must hold enough ETH on the selected network for the service price plus the network fee.

Yes, for two things: the service price shown live in the builder (starting at 0.02 ETH) and the network fee, which is paid separately at deployment and varies with congestion.

Ethereum Mainnet (Chain ID 1), Base (8453), Arbitrum One (42161) and OP Mainnet (10). Select the deployment network in the builder before continuing.

Start at 0.02 ETH. Add only the token features you need: most optional features cost 0.005 ETH each, while Trading Fees, Anti-Bot and Auto Liquidity cost 0.01 ETH each. The builder totals your exact service price live. The network fee is always separate.

No. Gas is set by the selected network, paid from your wallet at deployment, and varies with congestion. The builder keeps the two costs visibly separate: service price versus network fee.

Gas is the market price of network block space. When many people transact at once, the price rises; when the network is quiet, it falls. Your wallet suggests a fee before you sign, and you choose what to accept.

The service price is the fee for generating and preparing your token contract through ERC20Maker. Gas, by contrast, goes to network validators — never to us.

On EVM networks, a transaction that reverts still consumes the gas spent executing it. That is network behavior, not something the generator controls. Review every setting in the builder summary before signing.

The total number of tokens that exist. Initial supply is set at deployment — from thousands to billions — and the builder shows the exact figure in your summary before you continue.

Decimals define how divisible a token is. With 18 decimals (the standard), one token can be split into fractions as small as 0.000000000000000001. Almost every project uses 18 because all major tooling expects it.

Only if you enabled minting at deployment. A mintable token can issue new supply under the rules fixed in the contract; a fixed-supply token can never increase. Decide before you deploy.

Mintable means the contract keeps the ability to create new tokens after deployment — for rewards, treasury refills or phased distribution. Minting rights belong to the addresses configured at deployment.

Burnable means tokens can be permanently destroyed, reducing circulation. Projects use burning to model deflationary tokenomics, where shrinking supply meets steady demand.

Pausable means transfers can be temporarily halted — for example during an incident — and resumed later. It is a safety switch many teams enable for the early life of a token.

A cap on the size of any single transfer, expressed as a percentage of total supply. It discourages sudden whale dumps in thin markets.

A cap on how much of the supply a single wallet can hold. Often combined with max transaction to encourage wider distribution at launch.

Blacklisted addresses are blocked from sending or receiving your token. Projects use it against malicious or sanctioned addresses.

With whitelisting enabled, transfers are restricted to approved addresses — useful for private rounds, allowlists and staged rollouts.

Percentages taken on buys and sells and routed to a marketing wallet you control — for example 4% on buys and 6% on sells. Entering 4 means 4%; the builder never uses confusing decimal formats.

The Ethereum address that receives trading-fee revenue. Confirm it carefully before deploying: fees sent to a mistyped address cannot be recovered.

Anti-bot adds temporary launch protections that make automated sniping harder in the first blocks after trading opens. It reduces bot advantage; it does not eliminate it.

Auto-liquidity automatically routes a share of trading fees into the token's liquidity pool, so market depth builds as trading volume grows.

You do. Deployment is signed from your wallet, and ownership-related controls (such as minting or pausing, if enabled) belong to the addresses you configure.

No. The workflow is non-custodial: private keys never leave your wallet and funds never pass through our systems.

Your contract address is immediately usable: add the token to your wallet, verify the source on the relevant network explorer, and share the address with your community.

It is returned when your deployment transaction confirms, and it appears on the relevant network explorer. Copy it from there rather than from memory or chat messages.

Yes. Publish the exact source and compiler settings on the relevant network explorer so anyone can compare the source with the deployed bytecode. Ethereum deployments use Etherscan; see the verification guide in the docs.

Yes. Paste the contract address into MetaMask's import-tokens screen; symbol and decimals usually fill in automatically. The docs include step-by-step instructions.

The generator deploys the token; listing is a separate step you do yourself by creating a liquidity pool on a decentralized exchange and pairing your token with ETH or another asset.

No audit is claimed. Generated contracts follow standard ERC-20 architecture and can be published on a block explorer so the code is inspectable — but inspectable is not the same as audited.

No. Nothing here guarantees price, liquidity, exchange listings or demand. Never commit funds you cannot afford to lose, and never promise returns to others.

No. Verification proves the deployed code matches the published source. It does not prove the code is bug-free or the project honest. Read verified code critically.

Only within the rules fixed at deployment — for example, minting if it was enabled. Core settings like total supply behavior, fees and limits cannot be edited afterwards.

Smart-contract behavior, market risk and regulation in your jurisdiction. Read the disclaimer, verify your contract, keep your deployer keys secure, and comply with the laws that apply to issuing a token.