Fungible token guide
Plan a token before you create it.
A token is more than a name and a symbol. Define its purpose, supply, and controls before choosing how to implement it.
Before deployment
Start with a token specification
A fungible token represents interchangeable units. A balance of ten units usually behaves the same regardless of which transfer delivered them. That makes this model different from an NFT, where a token identifier distinguishes one item from another.
On EVM-compatible networks, ERC-20 is a common interface for fungible tokens. It describes functions such as balances, transfers, and allowances. It does not decide your token’s purpose, create demand, or make the contract secure. Those questions require separate work.
The planning checklist
Four decisions to write down
-
Define the purpose
Describe what a unit represents and what holders can do with it. If a normal database would serve the same purpose, explain why transferable on-chain ownership is useful for this project.
-
Choose supply and precision
Decide whether the supply is fixed, capped, or able to grow. Decimals affect how balances are displayed; they do not create value. For example, 1,000 display units with two decimals correspond to 100,000 base units.
-
Map the permissions
Record who may mint additional units, pause transfers, burn balances, or upgrade the contract, if those features exist. A cap is only meaningful when every privileged action respects it.
-
Plan the initial distribution
List the intended allocations and any release schedule. Check that allocations add up to the initial supply, and distinguish tokens already minted from tokens that may be minted later.
A small example, without a live token
Imagine a workshop issuing 1,000 demonstration units on a test network. The plan assigns 600 to practice accounts and keeps 400 for exercises. The contract uses zero decimals because the exercises only need whole units. Further minting is disabled in the intended design.
This specification is simple enough to test: the two allocations must total 1,000; a transfer must change the two balances correctly; and an account without permission must fail when attempting a restricted action. A name and symbol alone cannot establish those properties.
From specification to testing
Review the complete lifecycle
Test deployment, transfers, allowances, and any administrative functions in a local environment or on a test network. Allowances let another contract spend up to an approved amount; they deserve the same attention as direct transfers. Check failure cases as well as successful actions.
Before any real deployment, resolve key custody, contract review, documentation, and the effect of losing an administrative key. If the design is upgradeable, explain who can change the logic. Publishing source code makes inspection easier, but it is not a security review.
Looking for individually identified artwork instead? Follow the NFT minting guide . For the distinction between deployment and issuance, read what minting means .
Give each permission a reason
Use the same ownership and control questions when a token becomes an access pass.