Types of Assets
On Sui, there are a variety of fungible, non-fungible, and other types of asset standards, each with their own defined usage patterns and capabilities. Choosing the correct standard for your use case is important to enable the correct set of features in your application.
Fungible tokens: Coin standard​
The Coin standard defines fungible tokens that have key and store abilities. Coin supports wrapping and public transfers. It uses the sui::coin module. Coin refers to a single object wrapper for a fungible asset.
The Coin<T> type represents open-loop fungible tokens. Coins are denominated by their type parameter, T, which is also associated with metadata (like name, symbol, decimal precision, and so on) that applies to all instances of Coin<T>.
Fungible tokens created using the Coin standard are referred to as coins.
When you create a coin using the coin::create_currency function, the publisher of the smart contract that creates the coin receives a TreasuryCap object. The Coin standard uses CoinMetadata to define the coin's metadata.
When to use Coin​
Use the Coin standard if you are:
-
Working with legacy code or maintaining an existing coin that was created with the
sui::coinmodule -
Creating a coin that does not require advanced supply tracking or regulatory features
-
Familiar with the
CoinMetadata<T>object for metadata storage
Address balances​
Address balances tie fungible assets to a Sui address using directly. It replaces the UTXO-style Coin<T> model, where balances are calculated by summing all Coin<T> objects owned by an address. With the address balance functionality, each Sui address can have one address-owned balance for each currency they own, with the total balance being the sum of all Coin<T> objects plus the address balance. Coin<T> and address balances can exist together, however address balances provide several advantages over using Coin<T> alone.
For the full specification, see SIP-58: Sui Address Balances.
Fungible tokens: Currency standard​
The Currency standard is an example of an open-loop system. It supports free-flowing, wrappable, freely transferable fungible assets that you can store in any application. It uses the sui::coin_registry module and the Currency object for metadata. Currency refers to the object that is created in Coin Registry, which describes the currency properties and setup.
The Currency<T> type represents open-loop fungible tokens. Currencies are denominated by their type parameter, T, which is also associated with metadata like name, symbol, and decimal precision that applies to all instances of Currency<T>.
Fungible tokens created using the Currency standard are referred to as coins.
You can create coins with the Currency standard using coin_registry::new_currency and coin_registry::new_currency_with_otw:
-
Standard creation (
coin_registry::new_currency): Recommended for most cases. You can call this method any time after the coin type is published. -
One-Time Witness creation (
coin_registry::new_currency_with_otw): Uses a One-Time Witness for uniqueness proof. Requires a two-step publish and finalize process.
The Coin and Currency standards are both used to create fungible tokens. However, they use different creation methods and store metadata in a different type of object.
Coin creates tokens using coin::create_currency while Currency uses sui::coin_registry.
Coin uses CoinMetadata while Currency uses Currency.
Fungible tokens created on Sui using the Coin or Currency standard are referred to as coins.
For fungible tokens created on Sui using the Closed-Loop Token standard, the documentation uses the term tokens. In practice, the terms for both these objects are often interchangeable.
Coin Registry​
The Coin Registry system provides a centralized approach to currency management through the sui::coin_registry module. The registry is a shared object located at address 0xc that stores metadata, supply information, and regulatory status for all registered coin types.
When to use Currency​
Assets can offer specialized abilities while following the Currency Standard. For example, you can create regulated coins that allow their creator to add specific addresses to a deny list, so that the identified addresses cannot use the coin as inputs to transactions.
Use the Currency standard if you are:
- Creating a new coin and want to use Coin Registry
- Need advanced supply chain management, such as fixed supply, burn-only supply, or uncontrolled supply
- Need regulatory tracking such as deny lists
- Need enhanced integration options with wallets, exchanges, and apps
- Need future-proofing options and access to ongoing registry improvements
Learn more about using Currency.
Permissioned assets​
Permissioned Asset Standard is currently available on Testnet. It is not yet live on Mainnet.
The Permissioned Asset Standard (PAS) enables asset ownership through Account objects. Account objects can hold assets and enforce transfer controls and compliance checks. Accounts can only hold one asset, independent of its types, and the asset can only move between Accounts through hot potato requests that must be approved and resolved in the same programmable transaction block (PTB).
PAS uses Sui Address Balances. PAS balances are managed by PAS on behalf of the wallet address. They are held in a derived Account object, however, transfers always target the wallet address, not the Account address.
PAS assets are stored in Sui objects and can be queried using the same data access methods as any other address-owned data.
Learn more about Permissioned Asset Standard.
Fungible tokens: Closed-Loop Token standard​
The Permissioned Asset Standard (PAS) provides a new and improved alternative to the Closed-Loop Token (CLT) standard. It is recommended to use PAS in place of CLT.
The Closed-Loop Token standard creates a fungible token that only has the key ability. Closed-loop tokens cannot be wrapped, stored as a dynamic field, or freely transferred (unless a custom policy allows it). Due to this restriction, tokens created with this standard can only be owned by an account and cannot be stored in an application. However, they can be spent. The standard uses the sui::token module.
Fungible tokens created using the Closed-Loop Token standard are referred to as tokens.
Using the Closed-Loop Token standard, you can limit the applications that use the token and set up custom policies for transfers, spends, and conversions. Some applications might need a token that you can only use for a specific service, or that an authorized account can only use, or a token that you can block certain accounts from using. A real-world analogy would be a bank account that is regulated, bank-controlled, and compliant with certain rules and policies.
Refer to Closed-Loop Token for more information.
Non-fungible tokens: Sui objects​
Sui uses an object model, meaning every entity on Sui has a unique ID. Whether your application interacts with a pool of fungible tokens or a collection of non-fungible tokens, the application's smart contract interacts with individual objects. Therefore, Sui does not require an NFT standard that pairs globally unique IDs with relevant smart contract addresses to create unique token instances, such as how the ERC-721 standard works.
Consider the following example Move smart contract, where the NFT's name attribute is a field on the object that defines the NFT itself. The TestnetNFT struct defines the NFT with id, name, description, and url fields.
public struct TestnetNFT has key, store {
id: UID,
name: string::String,
description: string::String,
url: Url,
}