Skip to main content

Fungible Assets

Overview​

Fungible assets on Polymesh represent digitized value such as shares, bonds, funds, stablecoins, and more. They are managed using the standardized Polymesh asset framework, ensuring all assets benefit from built-in compliance, settlement, and lifecycle management features. For a high-level introduction to assets and the Polymesh asset standard, see Assets on Polymesh.

Fungible assets are interchangeable tokens with divisible or indivisible supply. Ownership is represented by balances held by different on-chain identities. They allow access to all core features such as compliance, settlement, corporate actions, metadata, and agent permissions, all available natively on-chain. For more on these features, see the relevant dedicated pages:

Asset Creation​

To create a fungible asset, users specify the asset type (e.g., Equity, Bond, Fund), divisibility, and optional metadata. Each asset is assigned a unique Asset ID and can have a unique ticker and external identifiers (such as ISINs, CUSIPs, etc.). For a step-by-step guide, see Asset Creation.

Issuance and Distribution​

After creation, issuers or their appointed agents can issue tokens to portfolios or accounts associated with their identity. Tokens can then be distributed to investors through a security token offering or directly using the settlement and compliance engines. See Settlement and Security Token Offerings for more on fundraising and distribution.

Key Features Unique to Fungible Assets​

Issuance and Redemption​

  • Issuance: An agent of the fungible asset can mint (issue) tokens to a portfolio or account under their on-chain identity (control of a portfolio can be assigned to another identity before issuing assets). This increases the total supply and the agents balance. Tokens are issued by calling the asset::issue method, specifying the asset_id, amount, and an AssetHolderKind (Account, DefaultPortfolio, or UserPortfolio) selecting the target.
  • Redemption: Tokens can be redeemed (burned) from a portfolio or account owned by an appropriately permissioned agent of the asset, reducing both the total supply and the portfolio or account's balance. Tokens are redeemed by calling the asset::redeem method, specifying the asset_id, value, and an AssetHolderKind selecting the source to redeem the tokens from.

Allowances​

asset::approve(asset_id, spender, amount) lets an asset holder authorize another account (spender, typically a smart contract or other third party) to move up to amount of the asset on their behalf, without granting the spender any broader identity or portfolio permission. Calling approve again replaces any existing allowance for that (owner, spender, asset_id) combination rather than adding to it. Setting amount to 0 removes the allowance. The current allowance can be queried via the AssetApi::allowance(owner, spender, asset_id) runtime API.

Unlimited allowances

Setting amount to the maximum value of the on-chain Balance type (Balance::MAX, i.e. the maximum u128 value) grants an unlimited allowance: it is never decremented as the spender draws it down via transfer_funds. This is the standard way to grant an allowance without needing to track or periodically top up a specific remaining amount.

The spender draws down the allowance by calling settlement::transfer_funds, naming the owner's account as the source — see Direct Transfers. This pairing (approve + transfer_funds) mirrors the ERC-20 approve/transferFrom pattern, and is the recommended way for a smart contract to move a user's tokens without requiring that user to co-sign every individual transfer. approve emits an Approval event when the allowance is set, and each draw-down via transfer_funds emits AllowanceSpent with the amount spent and the remaining allowance (unless the allowance is unlimited, in which case it isn't decremented). Allowances only apply to fungible assets — NFTs have no allowance concept.

Divisibility​

  • Fungible assets can be created as divisible or indivisible. Divisibility is set at creation, but an indivisible asset can later be made divisible using the asset::make_divisible method (callable by the asset owner or agent). Once an asset is made divisible, this change is permanent and cannot be reversed.
  • Divisibility affects the granularity of balances and transfers. For example, a divisible asset can represent shares with decimals, while an indivisible asset might represent whole-number units.
info

Decimals: All fungible assets on Polymesh use 6 decimals of precision. On-chain, balances are stored as integers, where 1 unit is represented as 1,000,000. If using the Polymesh SDK, it automatically converts between user-facing decimal values and the on-chain integer representation. Applications and user interfaces not using the SDK should account for this when displaying or entering amounts.

Corporate Actions & Checkpoints​

  • Corporate Actions: Fungible assets support on-chain corporate actions such as distributions and voting. These actions are tightly integrated with the asset's compliance and settlement features, allowing issuers to manage complex processes like dividend payments, shareholder meetings, and other corporate events directly on-chain. See Corporate Actions for more information.
  • Checkpoints: Corporate actions rely on checkpoints, which are a feature of fungible assets only. Checkpoints are snapshots of all holder balances at a specific point in time. Checkpoints are essential for many corporate actions and compliance activities, such as dividend distributions, voting, and regulatory reporting. See Checkpoint Management for details.

Transfer Restrictions​

  • Transfer Restrictions: In addition to identity-based on-chain compliance rules, Polymesh provides advanced transfer restriction features for fungible assets via the statistics pallet. These allow issuers to enforce count and percentage ownership restrictions such as a maximum investor count, maximum ownership percentage, and claim-based restrictions (e.g., jurisdiction, accreditation claim count restrictions). See Transfer Restrictions for details.

Further Reading​