Deploy a plain ERC-20 without writing Solidity — and know which fields you can never change

Most first tokens are boring on purpose. Points for a community, a voucher, an entry credential, a test asset that has to behave like a real ERC-20 without you babysitting a tax mechanism. No fee on buy, no fee on sell, no fee on wallet-to-wallet transfer — just transfer and balanceOf.

That's the type I'd expect a "how do I make a token" article to open with, but most of them skip it, because a tax token has more knobs to describe. So here's the plain one, field by field, using the Standard token path on GTokenTool. The interesting part isn't the clicking. It's that four of the five fields are write-once, and the deploy UI won't stop you from filling them in badly.

What "standard" is buying you, and what it isn't

The live creator page describes this type in one sentence: "No buy, sell, or transfer tax. Once deployed, it is a standard ERC-20 token." Under Best for it lists community points, event credentials, test tokens, and projects that don't need automated marketing or rewards.

Under Keep in mind it says the two things people get wrong:

"The platform does not automatically provide marketing, liquidity, or holder rewards."
"You will still need to add liquidity and run the project yourself."

Read those as the actual contract with you. A tax token gives you machinery — a slice of every trade routed to a marketing wallet, or swapped into another coin and paid out to holders. A standard token gives you nothing extra, which is exactly why its behaviour is predictable and why nobody has to audit your fee math before trusting a balance. Liquidity, distribution, and any rewards scheme are your problem, using other tools. If that sentence disappoints you, you want a different token type; the seven chips at the top of the form exist for that reason.

The other thing "standard" means, mechanically: the contract source is the same reviewed source every other standard token on that chain got. You are not writing Solidity, and you are not compiling your own contract. You're supplying constructor arguments to a factory that already holds the compiled bytecode. That's the whole idea behind no-code deployers, and it's worth stating plainly because it changes what "safe" means here — the code is identical across deployments, so the risk moves to the arguments you pick.

The five fields

Standard token is the shortest form in the creator. The form header tells you the shape of what gets encoded: "Standard token · 4 constructor argument groups". Those four groups are [name, symbol], [decimals, supply], [owner], and an empty fourth one — no fee-address group, because there are no fees. Five visible inputs, and they map onto those groups:

Token name. Free text, e.g. My Token. It's the long name wallets and block explorers show. There's no uniqueness check and there can't be — thousands of tokens are called the same thing, and that's legal on-chain.

Token symbol. Short, e.g. MTK. Same caveat: symbols are not namespaces. USDT isn't reserved, which is why you should verify a token by address, never by ticker. Your deploy is a new instance either way.

Decimals. The form range is 0 to 18, and the hint under the field literally says "From 0 to 18". This is the one that people get creatively wrong. Decimals is the divisor every wallet, explorer, and DEX applies to your raw integer amounts: a balance of 1000000000000000000 with decimals = 18 displays as 1. Choose 18 unless you have a specific reason. Choose 6 only if you're imitating a stablecoin. Choosing something exotic because you liked the number is how you end up with holders seeing "1,000,000 MYTOK" for what you meant to be 1 token.

And here's the part the field doesn't warn you about: you cannot change it later. Decimals is read by every client that ever touches your token. Deploy with 6 and "fix" it to 18 by redeploying means a new contract address, a new token, and a community holding the old one. There is no migration that makes balances mean the same thing.

Total supply. Whole number of tokens, minted entirely at deploy. This type has no mint function — what you enter is what will ever exist, and the contract address, the supply and the decimals are fixed after that. So decide whether you want a supply that can never grow (most points/voucher cases: yes) before treating this box as editable. If you do need an elastic supply, a standard token from this form isn't the tool.

Owner address. The form hint: "Filled in with your address once you connect" — and the how-it-works section spells out the consequence: "The wallet you connect becomes the contract owner unless you set a different admin address." Overriding it is legitimate and sometimes right (a multisig, a treasury address you control from another machine). What's not legitimate is treating it as a cosmetic field: ownership is the address that can call the privileged functions later, including the one-way switch below. If you paste an address you can't sign from, you don't have a token with a dead owner — you have a token whose settings belong to whoever does.

To keep that straight, here's the whole locked list in one place: name, symbol, decimals and total supply are frozen in the constructor — the standard token's console has no field-editing section at all, so there is no "rename later". The contract address is frozen too, and it's known before you sign. The fifth input, the owner address, is the only one that still moves afterwards, and only by the owner's choice (transferOwnership) or by being removed for good. Four write-once fields plus one address you can't get back: that's the entire surface where a careless minute costs you a redeploy.

One transaction, and what it costs

The deploy is a single payable call into the factory: createInitToken(feeAddr, salt, byteCode, constructorArgs, typeId, class) with the platform fee attached as value. One signature, one transaction, contract exists.

The fee is per token type and per chain. On BNB Chain mainnet, a standard token costs 0.05 BNB and the page shows that number as "Deployment cost" before you sign. On BNB Chain Testnet every type costs 0.000001 BNB — that exists so you can walk the entire flow for the price of a few cents of test gas. Gas for the transaction is on top of the platform fee, and it's paid from the same wallet.

The part I'd want to be told before using any deployer: your configuration is simulated before your wallet is asked to sign. While it runs, the button area reports what it's doing and says explicitly that this check doesn't cost network fees. The FAQ answer on the creator page is the plain version:

"Do I pay if the deployment fails?" — "No. Invalid settings are shown before your wallet asks you to sign, and no transaction is sent."

That matters more than it sounds. A bad constructor argument encoded into a real transaction on a mainnet costs gas and can leave you with a contract you can't use. A validation failure in the simulation costs nothing and shows up as red text on the field that caused it.

The address exists before you deploy

The contract address is shown while you're still filling in the form, and the page says so: "The address is fixed before you deploy — nothing to do up front."

That's CREATE2. The address is a function of the factory, the salt, and the bytecode-plus-arguments — so it's computable before anything lands, and the deployer can tell you the address you'll get. Two consequences worth understanding:

The default salt is derived from the current timestamp. Which is good: if you and someone else fill in identical name, symbol, decimals, supply and owner, you still get two different addresses. A fixed salt would mean the second deployer collides with the first and reverts.

A "vanity" suffix is decoration, not privilege. There's a scan you can open if you want the address to end in something memorable (say 8888). It runs offline in your browser, costs no gas, and doesn't deploy until you like what it found — it just keeps trying salts until one produces an address ending you asked for. It changes how the address looks. It changes nothing about what the contract does, and nobody is supposed to trust a token because of its last four characters, so don't oversell it to your users either.

After you sign

Two things happen automatically or nearly so, and then you're on your own in a specific way.

Source verification. A standard token is in the set the platform verifies automatically after deploy, so the contract page on the block explorer gets its source without you filing anything. You can still do it by hand; you usually won't need to.

The console. This is where the "boring type" trade-off shows up. Every deployed token gets a console (Manage Tokens → the token), where the editable settings live. For a tax token that's a long list — fee columns, blacklist, holder-count distribution, buy limits, referral rewards, reward claiming. A standard token's console has two sections, because the contract has almost nothing to configure:

• Liquidity — lock the LP.
• Permissions — transfer ownership, or "Removes the contract owner by setting it to 0x0, after which nobody can change this contract's settings again."

Renouncing is the one button on this page that has no undo. The console states it in the past tense once it's done: "This contract's ownership has been renounced. None of the settings below can be changed, and it can't be undone." For a points token whose parameters genuinely should never move again, that's a feature you can hand to your community as proof. For anything you might later want to adjust, it's a door you welded shut. Decide which one you're in before you're standing in front of the button, ideally with a nice number of holders already asking.

And one honest limitation on the Liquidity side, because it looks like a bug the first time you hit it. Taxed token types record their quote token and their router on-chain, so the console can read the pool and prefill it. A standard token records neither, so there's nothing to read:

"A standard token records neither its quote token nor its router on-chain, so there is no pool to read here. Click "Lock liquidity" to open the LP lock page with this token filled in, then pick the other side of the pair to resolve the LP token."

Your token is filled in. You choose the other half of the pair (the BNB, or the stablecoin, or whatever you actually paired it with), and the lock page resolves the LP token from that. It's one extra click caused by the type having fewer on-chain fields, not by the lock being unavailable.

The other thing a standard token doesn't have: a launch-time switch. The types that can be deployed untradeable and open at a chosen moment are the taxed ones — this form has no such option, because with no buy/sell logic there's nothing to gate. Your token becomes tradeable the instant a pool with it exists. Which means the liquidity step is the launch. Plan it as the launch.

Do the throwaway run first

If you've never deployed anything, switch the network dropdown at the top of the page to BNB Chain Testnet and make a token with junk values. Not because the mainnet run will fail — the simulation catches most self-inflicted errors — but because the sequence of screens (fill → fee shown → simulate → sign → address + verified source → console with two sections) is much cheaper to learn on an asset you're going to forget about.

One trap in that sentence, since it bites people: switching networks in your wallet does not switch the site. The page keeps its own chain selection and it's the dropdown in the header. Deploying to a testnet you didn't intend, or mainnet you did intend to avoid, is usually a mismatch between those two switches rather than a mistake in the form.

Where this is the wrong tool

Worth being blunt so nobody reads this and deploys the wrong thing:

• You need a tax. This type has no fee fields to fill in — buy, sell and transfer are all zero, by design. Use a taxed type.
• You need rewards to holders, or LPs, or an NFT side. Not this contract. Those are their own types with their own consoles.
• You need supply you can print later. Standard deploy mints everything and has no mint.
• You need your users to trust a burn or a reflection mechanic. A plain ERC-20 has no such mechanism to verify.

And the flip side: if what you need is "a normal token, at a known address, that behaves exactly like the ERC-20 everyone's tooling already supports", then the boring type is the whole feature, and the five fields above are the entire amount of design work you owe before signing.

The creator is at gtokentool.com/en/tokenfactory, the written field guide (all seven types, taxes included) at /en/guide/create-token, the console after deploy at /en/managetokens, and the liquidity step at /en/createLiquidityAndBuy. Prices here are BNB Chain's; the same form runs on the other thirteen chains the site lists, mainnets and testnets included, and the fee number on the page is the one that applies to whichever chain you picked.