Skip to main content

Fungible Tokens

Sui provides two standards for creating fungible tokens. Both produce Coin<T> objects that are fully interoperable with wallets, DeFi protocols, and address balances. The difference is in how you create, configure, and manage the token's metadata and supply.

What is the difference between the Coin Standard and the Currency Standard?​

FeatureCoin StandardCurrency Standard
Creation functioncoin::create_currencycoin_registry::new_currency or coin_registry::new_currency_with_otw
Metadata storageStandalone CoinMetadata objectCentralized in CoinRegistry at address 0xc
Supply modelsUncontrolled onlyFixed, burn-only, or uncontrolled
Regulatory supportcreate_regulated_currency_v2make_regulated() during initialization
Metadata updatesRequires TreasuryCapDedicated MetadataCap (can be frozen or deleted)
RPC discoveryRequires knowing CoinMetadata object IDQueryable from the central registry
StatusActiveRecommended for new projects

Which standard should I choose?​

Use the following guidance to pick the right standard for your project:

Recommended: Currency Standard

For new tokens, use the Currency Standard. It provides richer supply controls, centralized metadata discovery, and a dedicated MetadataCap for metadata management.

How do I create a new token?​

  • Most projects: Use coin_registry::new_currency. You can call this at any time after publishing your package. See Create Fungible Tokens: Currency Standard.

  • Need a One-Time Witness (OTW) proof: Use coin_registry::new_currency_with_otw in your module's init function. This requires a two-step publish-then-finalize process.

  • Need the legacy Coin Standard: Use coin::create_currency in your module's init function. See Create Fungible Tokens: Coin Standard.

Configuring supply​

Only the Currency Standard supports supply model configuration. Coin Standard tokens always use uncontrolled supply, where the TreasuryCap holder can mint and burn freely.

  • Fixed supply: Mint the total supply during initialization, then call make_supply_fixed to lock the TreasuryCap inside the Currency. No further minting or burning is possible.
  • Burn-only (deflationary): Mint the initial supply, then call make_supply_burn_only to prevent future minting while still allowing burns.
  • Uncontrolled: The default. The TreasuryCap holder can mint and burn freely.

Adding regulatory controls​

Both standards support regulated tokens with deny-list capabilities. The Currency Standard simplifies this with make_regulated(allow_global_pause, ctx) during initialization, which returns a DenyCapV2 for managing the deny list. See Regulated Tokens for deny-list management.

Migrating an existing token​

If you have an existing Coin Standard token, the Currency Standard provides migration functions to register your coin in the CoinRegistry while preserving its existing CoinMetadata object ID. See the Currency Standard reference for migration details.

Example patterns​

These guides show common token configurations in action:

Migrate a Coin Standard token to the Coin Registry​

Before you migrate an existing Coin Standard token, review how migration behaves:

  • migrate_legacy_metadata registers your CoinMetadata in the CoinRegistry and shares the resulting Currency. You can call it only once, and only if no Currency exists for the type yet.
  • Until you claim the MetadataCap, update_from_legacy_metadata copies changes from CoinMetadata into the Currency. After you claim the cap, you can update metadata only through the set_* functions.
  • You cannot delete the legacy CoinMetadata after migration. delete_migrated_legacy_metadata is disabled and aborts.
  • A migrated Currency does not record its treasury cap ID automatically. Call set_treasury_cap_id with your TreasuryCap to register it.
  • For regulated coins, anyone can call migrate_regulated_state_by_metadata with the RegulatedCoinMetadata object, and only once. You can also call migrate_regulated_state_by_cap with your DenyCapV2.