Aptos network upgrade to adopt Fungible Asset standard

Aptos is preparing a network upgrade that will allow token holders to vote on activating the Fungible Asset (FA) standard, a modern replacement for the older coin module [1]. The change promises type‑safe, customizable fungible tokens built on Move Objects, aiming to improve extensibility and on‑chain observability.

Key takeaways

• The FA standard uses Move Objects for metadata and balance tracking, unlike the legacy Coin struct [2].
• Fungible assets are “hot‑potato” resources that are destroyed after each transaction, with balances stored in a FungibleStore [1].
• Primary fungible stores are created deterministically and can be permissionlessly instantiated, which may introduce denial‑of‑service risks [1].
• The upgrade will enable voting mechanisms that let the community decide when to enable the FA standard on the mainnet [1].

From Coin to Fungible Asset: technical shift

The original Aptos coin model distinguishes tokens by compile‑time types (e.g., Coin<Otter>), stores them in a CoinStore, and includes a frozen flag that issuers can use to block transfers [1]. This design has been labeled “legacy” because its rigid struct layout hampers extensibility and makes off‑chain observability difficult. The new Fungible Asset model replaces the Coin struct with a FungibleAsset that carries a metadata object and an amount field [1]. Because metadata is defined at runtime, developers can attach additional context—such as asset name, symbol, or custom attributes—through Move Objects [2].

Balances are no longer kept in a CoinStore; instead, a FungibleStore object holds the total amount and a reference to the metadata [1]. Deposits destroy the temporary FungibleAsset and update the store’s balance, while withdrawals recreate a transient asset for the recipient. This pattern prevents the freezing bypasses possible with custom wallets in the legacy model [1].

Voting and network upgrade implications

Aptos plans to introduce a governance vote that will enable the FA standard across the network. The proposal leverages the primary fungible store module, whose deterministic address is derived from the owner and metadata [1]. While permissionless creation of primary stores simplifies onboarding, it also carries a risk: the create_primary_store function aborts if a store already exists, potentially opening a denial‑of‑service vector if attackers repeatedly attempt creation [1]. The upgrade documentation recommends using ensure_primary_store_exists to mitigate this issue.

The FA standard’s reliance on the Object module (introduced in AIP‑10) means that any asset represented as an object can also be expressed as a fungible asset, allowing a single object to be split into interchangeable ownership units [1]. This tight coupling enhances flexibility for real‑world assets and currencies but also adds complexity that developers must manage, especially around zero‑value asset creation and destruction, which could lead to arithmetic errors if not properly handled [1].