Tokens

Token creation is for teams that need a standard Supra Fungible Asset without publishing a custom Move package. The factory creates the token, mints its initial supply, and returns a metadata object address that wallets, explorers, and every Trust Stack product use as the token address.

When to use it

Use this product when you want to:

• create a fixed-supply token whose supply cannot be increased through the current controller;
• create a capped token whose controller may mint later, but never above its immutable cap;
• distribute, lock, vest, stream, airdrop, or stake the resulting Fungible Asset; or
• let holders optionally burn only tokens held in their own accounts.

It is not a token-sale contract, liquidity pool, bridge, tax token, blacklist, pause system, or administrator seizure mechanism.

Before you start

You need:

• StarKey connected to Supra Testnet;
• enough SUPRA for the 50 SUPRA protocol fee and network gas;
• the final token name, symbol, decimals, and supply model; and
• optional HTTPS or IPFS icon and project URLs.

Supply settings are economically important. A fixed-supply token and a capped-mintable token should not be presented to users as equivalent.

Create a token

1. Open Create token and connect StarKey.
2. Enter the name, symbol, decimals, and positive initial supply.
3. Choose Fixed supply or Capped mintable. For a capped token, enter the maximum supply.
4. Decide whether holders may burn tokens from their own balances.
5. Add optional icon and project URLs.
6. Select Review token and inspect the base-unit supply, retained capabilities, recipient, live creation fee, and network.
7. Sign the transaction. Do not treat a wallet submission alone as success.
8. Wait for the finalized TokenCreated event, then save the metadata object address and transaction hash.

Practical example

Suppose a project creates Example Rewards (EXR) with 8 decimals, an initial supply of 1,000,000 EXR, and a maximum supply of 5,000,000 EXR.

• The creator initially receives 1,000,000 EXR.
• The controller may mint up to another 4,000,000 EXR.
• The cap can never be exceeded.
• If holder burn is enabled, Alice may burn Alice's EXR, but the controller cannot use that feature to burn Bob's balance.

If the project does not need future minting, selecting Fixed supply removes the current controller's mint path after creation.

Fees and costs

The creation fee is transferred only when token creation succeeds. If creation aborts, the protocol fee transfer and token creation roll back atomically, although the network may still charge gas for the failed transaction. The wallet signs a maximum acceptable fee, so execution aborts if the live fee exceeds the reviewed limit.

The live testnet fee is 50 SUPRA and the immutable cap remains 25,000 SUPRA. Governance may move the fee within that cap, and an approved governor-multisig change applies when it executes. Always review the live amount shown by the dApp before signing. See Fee governance.

Supply models and authority

Controller transfer uses a propose-and-accept flow. The current controller may irreversibly renounce mint or burn authority. Anyone evaluating the token should verify its current controller, cap, and capability state rather than relying only on its name or symbol.

Input rules

• Name: required, at most 32 UTF-8 bytes
• Symbol: letters and numbers, at most 10 characters, normalized to uppercase
• Decimals: integer from 0 through 18; 8 is the common Supra convention
• Initial and maximum supply: exact decimal input that must fit a Move u64 after conversion
• Icon and project URIs: optional HTTPS or IPFS values, at most 512 bytes

The form converts the human amount using the selected decimals. Review both the display supply and base units before signing; decimals cannot be changed after creation.

After creation

Save and share:

• the metadata object address;
• the creation transaction hash;
• the supply model and maximum supply;
• the controller address and enabled capabilities; and
• the metadata URLs and their operational availability policy.

Creation is presented as complete only when the configured RPC returns a successful receipt whose event matches the reviewed identity, supply, creator, recipient, and capability flags. You can then use the metadata address in token locks, vesting, multi-send, and other products.

Common problems

• Insufficient SUPRA: keep enough for both the protocol fee and gas.
• Supply does not fit: reduce the supply or decimals so the base-unit amount fits u64.
• Duplicate-looking token: identity comes from the metadata address, not the name or symbol.
• Unexpected mint risk: verify whether the token is fixed or capped and who controls minting.
• Transaction submitted but not shown: check the hash in SupraScan and wait for RPC reconciliation before retrying.