Aptos Fungible Asset Standard vs Sui Coin Type: What’s the Difference?

25 September 2026

Both Aptos and Sui are Move-based blockchains, but they implement token standards in fundamentally different ways. Aptos uses a Fungible Asset (FA) standard built on top of its object-based Move framework, while Sui uses a Coin type that is a core part of its object-centric data model. The practical difference is that Sui’s Coin is a single, unified type with built-in transfer and storage semantics, whereas Aptos’s FA standard is a more modular, configurable framework that separates the asset’s logic from its storage.

The core distinction: one type vs. A framework

Sui coin: A single built-in type

On Sui, a coin is defined as:

struct Coin<T> has key, store {
 id: UID,
 balance: Balance<T>
}

This is a generic type. The <T> is a phantom type parameter that identifies the specific coin - for example, Coin<SUI> for the native token or Coin<MY_TOKEN> for a custom one. The important part is that every Sui coin, regardless of what it represents, uses the same Coin struct. The type system enforces that you can only send a Coin<A> to a function expecting Coin<A>, not a Coin<B>.

Sui’s coin is owned - it lives inside an object, and that object can be transferred, wrapped, or destroyed. The balance itself is a separate Balance<T> object that holds the actual value. This split allows Sui to optimize storage and transfers. When you send a coin, Sui can simply move the Balance object from one owner to another without copying data.

Aptos fungible asset: A configurable standard

Aptos’s Fungible Asset standard is a more recent design, introduced to replace the older 0x1::coin module. It defines a FungibleAsset type that is also generic, but the key difference is that it separates the asset metadata from the asset store. The standard introduces two main structs:

struct FungibleAsset { ... } // holds the value
struct FungibleStore { ... } // holds a mapping of assets to owners

The critical difference is that Aptos’s FA standard allows for customizable behavior. You can define your own FungibleAsset with additional fields, or you can use the default implementation. The standard is designed around dispatchable functions - meaning that when you call transfer, the asset’s module gets a chance to run custom logic (e.g., blacklist certain addresses, apply fees, or enforce whitelists).

Sui’s Coin, by contrast, has no such hooks. Transfer is a built-in operation on the Coin type that cannot be overridden. If you want custom behavior on Sui, you wrap the coin in another object and define your own transfer function.

Storage and ownership models

Sui: Object Ownership

In Sui, a coin is always stored inside an object. That object has a single owner (an address) or is shared (for shared state). The object can be:

• Owned: Only the owner can transfer or spend it.
• Immutable: No one can modify it (used for created coins that are frozen).
• Shared: Anyone can read and modify it (rare for coins, used for liquidity pools).

This object model means that coin ownership is explicit. The Move runtime on Sui tracks object ownership and enforces access control at the object level. If you own a Coin<T> object, only you (or a module you authorize) can call functions that take it as a parameter.

Aptos: Account-Balanced Storage

Aptos uses a global storage model by default, where each address has a storage map. The FA standard stores balances in a FungibleStore that is associated with an address. This is closer to a traditional account model - you don’t hold a "coin object", you have a balance stored in your account’s storage.

The store is a resource that can be modified only by the module that defines the asset (or by the store’s owner). This distinction matters because:

• On Sui, you move a coin from one object to another. The coin is a first-class citizen.
• On Aptos, you modify the balance in a store. The store is the first-class citizen.

This means that Aptos’s FA standard is more akin to an ERC-20 token, while Sui’s Coin is more like an ERC-721 (non-fungible token) that happens to hold a balance.

Upgradeability and Extensibility

Aptos: modular and upgradeable

The FA standard is designed to be extended. You can:

• Add custom fields to your FungibleAsset (e.g., a frozen flag or a tax_rate field).
• Override default functions like deposit or withdraw to add logic.
• Use the standard’s ref mechanism to gain "mint" and "burn" capabilities that can be stored separately from the asset itself.

This makes Aptos’s FA standard more flexible for complex financial instruments. If you need a token that enforces transfer limits or has a built-in rebase mechanism, the FA standard gives you the tools to do it cleanly.

Sui: composable, not upgradeable

Sui’s Coin type is deliberately simple. You cannot override its transfer function - that’s a language-level operation. Instead, you build composability by wrapping the coin in your own struct:

struct MyToken {
 coin: Coin<MY_TOKEN>,
 // custom fields
}

You then define your own transfer function that operates on MyToken. This is more verbose, but it has a distinct advantage: Sui’s object model makes it trivial to reason about what can and cannot happen. Since coins are just objects, and objects have strict ownership rules, you can always tell who controls what. There are no hidden hooks or unexpected behavior.

How to Choose

Use Sui if you want maximal safety and simplicity, and you’re comfortable composing custom logic from small, verifiable pieces. The object model forces you to be explicit about state changes, which reduces the risk of bugs.

Use Aptos if you want a more traditional token experience with built-in configurability. If you’re porting an Ethereum project and want to replicate ERC-20 patterns, the FA standard will feel more familiar. It also supports module upgrades, which can be a plus for long-lived projects that need to fix bugs or add features after launch.

Practical implications for developers

When you build on Sui, you spend most of your time thinking about objects and ownership. You ask: "Who owns this coin? What happens if I transfer it? Can this function move the coin out from under me?" The answers are always visible in the code.

When you build on Aptos, you spend more time thinking about events and global state. You ask: "What happens when this store is modified? Does the asset’s module allow this operation? What if the module is upgraded?" The answers depend on the specific implementation.

Neither model is inherently better. They are different trade-offs. Sui trades flexibility for verifiability; Aptos trades rigidity for extensibility. Your choice should depend on which trade-off you’re more comfortable living with.

Back to sui & aptos