9 Common TRC-20 Mistakes and How to Avoid Them
Wrong decimals, lost ownership, no liquidity lock - dodge the costly rookie errors.
Updated
Most failed token launches fail for the same handful of avoidable reasons. Here are the nine most common TRC-20 mistakes and how to sidestep each one. Then work through the pre-launch checklist before you go live.
1. Wrong decimals
Setting an unusual decimals value (or copying 18 from Ethereum) can make balances display oddly and confuse integrations. Stick with 6 unless you have a real reason - see the parameters guide.
2. Typos in name or symbol
Name, symbol, supply and decimals are permanent. A typo means redeploying. Read them back carefully before confirming.
3. Holding too much supply in one wallet
If a single wallet holds most of the supply, buyers see dump risk and stay away. Plan a sensible distribution and vest team tokens.
4. No liquidity (or too little)
A token with no liquidity pool isn’t tradable; one with thin liquidity swings wildly and is easy to manipulate. Fund a real pool.
5. Not locking liquidity
Unlocked liquidity can be withdrawn at any time, which looks like a rug risk. Locking it is one of the strongest trust signals you can give.
6. Leaving the contract unverified
An unverified contract hides what the token does. Verify it so holders can read the code.
7. Enabling powerful features unnecessarily
Turning on mint or pause when you don’t need them adds trust cost for no benefit. Enable features deliberately - see the features guide.
8. Losing the deployer wallet
The wallet that receives the supply and ownership is critical. Secure it (ideally a hardware wallet) and back up the seed phrase offline. Lose it and you may lose control of your token.
9. Falling for scams during launch
Fake “listing services,” phishing DEX clones, and anyone asking for your seed phrase are all traps. No legitimate process ever needs your recovery phrase. Review the security checklist.
Mistakes that show up after launch
The first nine are mostly setup errors. A second wave catches projects once the token is live:
- Going quiet. A token with no updates looks abandoned. Community is the project - keep showing up. See marketing your token.
- Renouncing before you were ready. Renouncing is irreversible; do it once setup is complete, not in launch-day excitement. Read what renouncing means first.
- Overpromising. Guaranteeing returns or hyping unrealistic roadmaps destroys credibility fast and can create legal exposure.
- Ignoring holder questions about safety. If people ask whether liquidity is locked or the contract verified, answer with links to on-chain proof - don’t deflect.
Quick fix reference
| Mistake | Fixable after launch? |
|---|---|
| Wrong decimals / name / symbol | No - requires a fresh deployment |
| No or thin liquidity | Yes - add more to the pool |
| Unlocked liquidity | Yes - lock it |
| Unverified contract | Yes - verify on Tronscan |
| Poor distribution | Partly - improve going forward, can’t undo the past |
Frequently asked questions
What’s the most damaging mistake?
No liquidity (or unlocked liquidity). It makes a token untradable or untrustworthy, no matter how good the idea is.
Can I fix a mistake after deploying?
Parameters are fixed, but you can still add liquidity, verify the contract, and improve distribution. Some things require a fresh deployment.
I made a typo in the name - what now?
Name and symbol can’t be edited on-chain, so the clean fix is to deploy a new token with the correct details and, if you’d already distributed any, migrate holders. It’s cheap to redeploy - far cheaper than launching with a permanent error.
Is it a mistake to renounce ownership?
Only if you do it before you’re finished or when you still need owner functions. Done at the right time, renouncing is a strong trust signal - the mistake is renouncing prematurely.
How do I avoid all of these at once?
Work through the pre-launch checklist and the security checklist before you promote. Between them they catch every mistake on this page.