Fungible Token

Overview

Fungible-token standards maintain balances by account and quantity rather than unique ownership of individual token IDs. ERC-20 and many native multi-asset frameworks are common examples.

Interchangeability simplifies payments, trading, accounting, and liquidity pools. Applications can aggregate units without tracking which specific token was received. This differs from NFTs, where each token ID can have distinct attributes or market value.

Protocol-level fungibility does not guarantee economic equality across representations. A bridged USDC token can differ from native USDC even when both target one dollar. Frozen units can also become unusable while unrestricted units remain transferable.

Tokens can rebase, charge transfer fees, or redistribute balances. These behaviors complicate the assumption that sending a stated amount produces the same amount at the destination. Integrations should inspect actual contract behavior.

Legal or compliance systems can attach address history and restrictions to otherwise fungible tokens. Privacy limitations can make market participants prefer or reject particular coins or UTXOs, reducing practical fungibility.

Applications should identify the exact network, contract, decimals, and issuer. Fungibility is a design property within the token system, not proof of stable value, unrestricted transfer, or equivalence with similarly named assets on another chain.

Custody and payment systems should test whether a token is practically fungible across addresses and venues. Blacklists, sanctions screening, bridge provenance, and tokenized claims can create differential acceptance. The protocol balance may be interchangeable while compliance and redemption treatment are not.

Fungible Token, Semi-Fungible Token, and Omnichain Fungible Token may appear in the same workflow. Every component connected to Fungible Token should therefore be validated independently so a related asset or mechanism is not credited as the intended token.