How to Create a Fixed Supply Coin on Sui
On Sui, a custom fungible asset is defined by a Move type and initialized with the framework's coin module. Initialization creates metadata and a TreasuryCap capability that authorizes supply changes. A credible fixed supply design mints the intended amount and permanently removes the capability in a way supported by the framework. This guide explains the capability model, testnet rehearsal, and verification. It is educational only, not financial advice, and does not support counterfeit branding or undisclosed controls.
Editorial research by Coinatio, checked against the primary documentation cited below. Educational content only.
- Sui supply control follows possession of capabilities rather than an EVM style owner variable.
- Package publication, minting, and capability destruction should be rehearsed as one auditable sequence.
- Object and transaction reads can independently confirm supply and metadata state.
- An immutable supply does not make metadata, distribution, or market claims trustworthy by itself.
Prerequisites and Move design
Install the Sui CLI from official documentation, select testnet, create a dedicated address, and obtain test SUI. Learn the object and capability model before modifying a coin example. Pin the Sui toolchain used to build and publish the package, and keep package source in version control with a clean revision.
Specify the coin type name, display name, symbol, description, icon URL, decimals, total displayed supply, and initial recipient. Convert displayed supply into base units carefully. The one time witness pattern allows the module initializer to call coin creation for the declared type. Review the current Sui framework signature rather than relying on an older tutorial because Move APIs evolve.
- Use original metadata and a durable icon location.
- Record the intended package address, module, coin type, decimals, and base unit supply.
- Decide whether metadata may be updated and disclose any retained metadata capability.
- Use testnet objects and funds for the complete rehearsal.
Publish, mint, and remove supply control
Build the package and review dependency addresses, compiler output, and published bytecode dependencies. Publish on testnet and inspect the created package, metadata object, and TreasuryCap. The initializer can transfer that capability to the publisher or use it in a controlled followup transaction, depending on the module design.
Mint the exact base unit quantity through the TreasuryCap, then transfer the resulting coin or balance to the disclosed recipient. Read the resulting supply before removing control. For permanent fixed supply, use the Sui framework's supported operation to consume the TreasuryCap so it cannot authorize future minting or burning. Capability destruction is irreversible, so package logic, quantity, decimals, and recipient must be verified first.
Checklist and independent verification
Capture the package publication digest and the transaction digest for minting and capability removal. Query the normalized Move module to confirm the coin type and inspect the metadata object. Query total supply using official RPC or CLI facilities, then reconcile it with the recipient's coin objects and any intentional distribution transfers.
Verification should distinguish package immutability from object mutability and supply authority. Sui packages are not governed like ordinary EVM proxies, but shared or owned objects and retained capabilities can still control application behavior. Review every capability created or transferred by the module, not only TreasuryCap.
- Checklist: network, gas owner, source revision, package dependencies, decimals, quantity, and recipient are correct.
- Checklist: TreasuryCap is consumed and metadata controls match the disclosure.
- Verification: package ID, full coin type, object IDs, transaction digests, and total supply are published.
- Verification: a second RPC endpoint returns consistent package and object data.
Limitations and responsible use
Destroying TreasuryCap prevents authorized supply changes through the standard coin mechanism, but it does not prove fair distribution, useful software, liquid markets, secure external applications, or accurate offchain content. Wrapped representations and unrelated contracts can also cause users to mistake one asset for another, so the full coin type is essential.
Do not describe package publication as endorsement by Sui. Avoid confusing names, hidden capabilities, fabricated partnerships, and claims of guaranteed scarcity value. Publish concentration and control information, arrange appropriate Move review, and obtain jurisdiction specific advice before offering an asset to the public.
Sources
This article explains technical and market-data concepts. It is not financial, legal, tax, or investment advice. Verify current chain state and primary documentation independently.
