FA2 (Tezos)

What Is FA2 on Tezos?

FA2 is a unified token standard for smart contracts on the Tezos blockchain.

It defines a common interface that wallets, decentralized applications, block explorers, marketplaces, games, and other crypto tools can use to interact with Tezos tokens.

FA2 is formally specified in Tezos Improvement Proposal 12, or TZIP-12.

The standard can support fungible tokens, non-fungible tokens, non-transferable assets, and contracts that manage several token types at the same time.

This flexibility allows one FA2 contract to manage a single cryptocurrency, a collection of NFTs, multiple in-game assets, or a combination of different token models.

FA2 does not determine the economic value, legal status, supply, or purpose of a token.

Instead, it standardizes important technical operations such as transferring tokens, checking balances, and authorizing operators.

An FA2 token is not stored directly inside a user’s Tezos account in the same way as tez, the native asset of Tezos.

The FA2 smart contract maintains a ledger that records which account owns each token or token balance.

The official Tezos FA2 documentation describes FA2 as a flexible standard that allows custom token behavior while maintaining compatibility with existing applications.

What Does FA Mean in FA2?

FA stands for Financial Application.

The name reflects the standard’s role in defining reusable interfaces for financial assets and tokenized applications on Tezos.

FA2 is newer and more flexible than the earlier FA1.2 token interface.

The number 2 identifies the standard family rather than a token version chosen independently by each issuer.

A project does not become FA2-compatible merely by adding “FA2” to its token name or metadata.

Its smart contract must implement the required TZIP-12 interfaces and behavior.

Why Does Tezos Need a Token Standard?

A blockchain allows developers to write many different smart contracts, but completely different token interfaces would make integrations difficult.

A wallet would need custom code for every token contract if each contract used different transfer and balance functions.

A marketplace would also need to learn a different approval process for every NFT collection.

FA2 provides predictable entrypoints and data structures that reduce this integration problem.

A compatible wallet can recognize how to request a balance or prepare a transfer without understanding every internal storage detail.

A compatible marketplace can request operator permission through a standardized process.

A block explorer or indexer can identify token movements and organize balances by contract address and token ID.

Standardization improves interoperability, but it does not guarantee that every contract using the interface is safe or honest.

The Tezos token documentation warns that anyone can create a token contract and define potentially harmful or restrictive behavior.

How Does an FA2 Token Work?

An FA2 token is controlled by a smart contract originated on Tezos.

The contract stores a ledger representing token ownership or balances.

For a fungible token, the ledger generally maps an account and token ID to a quantity.

For an NFT, the ledger may map a unique token ID to its owner or record a balance of one for the owner.

When a transfer occurs, the FA2 contract checks the sender’s authority and available balance.

The contract then subtracts tokens from the source account and adds them to the destination account.

The smart contract can also apply custom restrictions before accepting the transfer.

For example, a token may allow only owner transfers, support approved operators, pause transfers, or prohibit transfers entirely.

All valid state changes are recorded on Tezos and can be examined through compatible blockchain tools.

How Is an FA2 Token Identified?

An FA2 token is uniquely identified by its smart contract address and token ID together.

The token ID is a nonnegative integer assigned by the contract.

Two tokens can use the same token ID when they belong to different FA2 contracts because the contract addresses distinguish them.

A token described only as token ID 0 is therefore not uniquely identified.

Users must also confirm the contract address.

If an FA2 contract supports only one token type, the token ID must be 0 under the standard.

If the contract manages several token types, it can assign distinct token IDs to those assets.

The SmartPy FA2 overview confirms that the contract address and token ID form the complete onchain token identifier.

What Types of Tokens Can FA2 Support?

Fungible Tokens

A fungible token consists of interchangeable units that have the same properties and value within the contract.

One unit can generally be exchanged for another unit of the same token without changing the holder’s economic position.

FA2 fungible tokens can represent payment assets, governance units, loyalty points, stable-value assets, wrapped assets, or other divisible cryptocurrencies.

The metadata decimals field tells wallets where to display the decimal point, but balances are stored as whole natural-number units.

Non-Fungible Tokens

An FA2 NFT represents a distinct token identified by a unique token ID.

The token may be associated with digital art, game items, memberships, certificates, event access, or real-world records.

Metadata can describe the media, creator, attributes, and other information connected with the NFT.

Ownership of an NFT does not automatically transfer copyright, intellectual property, or legal ownership of an offchain object.

Those rights depend on the issuer’s terms and applicable law.

Multi-Asset Contracts

One FA2 contract can manage many different token IDs.

A game could use one contract for currencies, weapons, land items, character assets, and collectible rewards.

An NFT project could manage an entire collection from one contract.

A financial application could issue several related fungible assets under one interface.

Using one contract can simplify batch operations and reduce the number of separate contracts that applications must integrate.

Hybrid Token Contracts

An FA2 contract can combine different token behaviors within one implementation.

For example, one token ID could represent a fungible asset while other IDs represent unique NFTs.

A project can also combine transferable and non-transferable assets under carefully defined policies.

Applications must not assume that every token ID inside the same FA2 contract has identical supply, decimals, transfer rules, or metadata.

Non-Transferable Tokens

FA2 can support assets that cannot be freely transferred after issuance.

These tokens may represent credentials, badges, reputation, licenses, or records tied to one account.

A transfer attempt can fail with the standard FA2 transaction-denied error when the contract’s policy blocks transfers.

Users should verify transfer rules before acquiring a token because a displayed wallet balance does not prove that the asset can be sold or moved.

What Are the Required FA2 Entrypoints?

An FA2-compatible contract must provide three standard entrypoints named transfer, balance_of, and update_operators.

These entrypoints create the common interface that external applications use.

Developers may add other entrypoints, but additional features do not replace the required interfaces.

The SmartPy FA2 entrypoint documentation explains the parameters and expected behavior of these operations.

Transfer Entrypoint

The transfer entrypoint moves tokens from one account to one or more destination accounts.

Each transfer item specifies the source address, destination address, token ID, and amount.

The entrypoint accepts batches rather than limiting each call to one transfer.

A batch can include several transfers involving different accounts and token IDs.

The contract verifies that each referenced token exists.

It also verifies that the source has enough tokens and that the caller has permission to move them.

The transaction fails if a required condition is not satisfied.

Balance_of Entrypoint

The balance_of entrypoint requests balances for one or more account and token ID pairs.

It uses a callback contract to receive the requested balance information.

This callback design allows another smart contract to request balances and receive the results through an internal Tezos operation.

Offchain applications can also use indexers or standardized views when appropriate.

A balance query must identify both the owner address and token ID.

Knowing only the account address is insufficient when one contract manages multiple token types.

Update_operators Entrypoint

The update_operators entrypoint allows token owners to add or remove authorized operators.

Each authorization identifies the owner, operator, and token ID.

Only the token owner can normally change operator permissions for that owner’s tokens.

The contract may reject operator updates when its transfer policy does not support operators.

Operator permissions should be removed when a marketplace, game, or application no longer needs them.

What Are Batch Transfers?

Batch transfers allow several token movements to be included in one call to the transfer entrypoint.

A single batch can send one token type to several recipients.

It can also transfer several token IDs managed by the same contract.

This structure can reduce repeated wallet prompts and contract calls.

It is especially useful for games, NFT collections, treasury distributions, and applications that manage many asset types.

The entire Tezos operation follows atomic execution rules.

If a required transfer in the call fails, the related contract execution does not leave a partially completed state.

Applications should still limit batch size because larger operations require more computation and storage processing.

What Is an FA2 Operator?

An operator is an account or smart contract authorized to transfer a specific token type on behalf of its owner.

A user may authorize a marketplace as an operator so the marketplace can complete a sale after a buyer accepts an offer.

An operator permission is associated with an owner, operator address, and token ID.

The authorization does not automatically apply to every token in the owner’s wallet.

However, for the specified token ID, the operator can generally transfer any amount that the owner holds under the standard operator model.

The permission is not a limited numerical allowance that decreases after each transfer.

This makes operator approval convenient, but it also creates risk when the approved application is malicious or compromised.

The owner can remove an operator through the update_operators entrypoint when the contract’s policy supports that action.

How Do FA2 Transfer Policies Work?

FA2 allows contracts to define different permission policies while preserving a shared transfer interface.

The standard can describe whether transfers are supported and whether operators are permitted.

The SmartPy transfer-policy documentation provides common policy models for FA2 implementations.

No-Transfer Policy

A no-transfer policy prevents token holders and operators from transferring the affected tokens.

This model can support credentials, identity records, badges, and other account-bound assets.

Owner-Transfer Policy

An owner-transfer policy allows owners to move their own tokens but does not support operators.

A marketplace that depends on operator authorization may be unable to work with these tokens.

Owner-or-Operator Policy

An owner-or-operator policy allows the token owner or an approved operator to transfer the token.

This is a common model for tradable tokens and NFTs.

Pauseable Transfers

A custom FA2 implementation may allow an administrator to pause transfer and operator activity.

Pausing can help respond to a security incident.

It also gives the administrator significant control over whether holders can move their assets.

Users should verify whether pausing authority exists, who controls it, and whether it can be removed.

Does FA2 Require Minting?

No, FA2 does not require a mint entrypoint.

A contract can initialize all tokens when it is originated and provide no method for creating more.

Another implementation can include an administrator-controlled mint function.

A game may mint new items when players complete specific actions.

An NFT contract may mint a new token ID for each new collectible.

The Tezos minting and burning tutorial explains how optional features can be added through a contract library.

Investors should review actual mint authority instead of assuming that FA2 establishes a fixed maximum supply.

Does FA2 Require Burning?

No, a burn entrypoint is also optional.

Burning permanently removes token units according to the contract’s accounting rules.

A contract may let users burn their own tokens.

Another contract may restrict burning to an administrator or provide no burning mechanism.

Burn permissions affect supply, redemption, game mechanics, and token economics.

The existence of a burn function does not guarantee that the asset is deflationary because minting may exceed burning.

How Does FA2 Token Metadata Work?

Token metadata describes information associated with a particular token ID.

Common fields include the token name, symbol, decimals, description, and links to media.

The FA2 token metadata documentation explains that each token ID is associated with its own metadata object.

Metadata can be stored directly in the contract or referenced through an external URI.

NFT metadata is frequently stored in a JSON document referenced by the contract.

The InterPlanetary File System is often used to provide content-addressed storage for these documents and media files.

An external metadata link does not guarantee that the linked information will remain available forever.

Files should be pinned and backed up to reduce the risk of disappearance.

What Are the Standard Metadata Fields?

The name field provides a display name for the token.

The symbol field provides a short identifier used by wallets and applications.

The decimals field tells interfaces how to display a fungible balance.

An empty metadata key can point to an external JSON document containing additional information.

Custom fields can describe artwork, attributes, creators, licensing terms, or application-specific data.

Wallets may ignore unknown custom fields.

Metadata improves presentation but does not override the actual contract ledger or transfer logic.

A token can display a familiar name or symbol while being issued by an unrelated contract.

The contract address and token ID remain the reliable technical identifiers.

Token Metadata vs. Contract Metadata

Token metadata describes an individual token ID.

Contract metadata describes the FA2 smart contract itself.

Contract metadata can identify the contract’s name, version, authors, interfaces, source information, and available views.

TZIP-16 contract metadata provides a standard structure for publishing this information onchain or through an external URI.

A multi-asset contract can have one contract metadata document and many separate token metadata objects.

Applications should not confuse the contract’s display name with the name of every token managed by that contract.

What Does the Decimals Field Mean?

The decimals field controls how applications display a token’s integer balance.

Assume a contract records a raw balance of 1,000,000 and the token uses six decimals.

A wallet displays that amount as 1.000000 token.

The contract still stores a natural-number balance rather than a floating-point value.

NFTs usually use zero decimals because each unit is indivisible.

An incorrect decimals value can cause a wallet to display a misleading quantity.

Decimals do not determine the token’s market price or maximum supply.

FA2 vs. Tez

Tez is the native cryptocurrency of the Tezos blockchain.

FA2 tokens are assets managed by smart contracts.

Tez balances are part of the protocol’s account accounting, while FA2 balances are records in a token contract’s storage.

Network transaction fees are paid in tez even when a user transfers an FA2 token.

Holding an FA2 token does not automatically provide enough tez to pay for an onchain transaction.

A wallet may therefore show a valuable token balance while being unable to move the token until the account receives enough tez for fees and storage costs.

FA2 vs. FA1.2

FA1.2 is an earlier Tezos token interface designed for fungible tokens.

FA2 supports a wider range of assets, including fungible tokens, NFTs, non-transferable tokens, and multi-asset contracts.

FA2 also uses token IDs and batch-oriented operations.

The operator model differs from a numerical allowance model because an approved FA2 operator can generally transfer the owner’s available balance for the specified token ID.

An FA1.2 token does not automatically become an FA2 token.

Migration requires a deliberate contract and asset-conversion process when an issuer chooses to change standards.

Both standards can continue to exist on Tezos.

FA2 vs. NFT

FA2 is a token interface, while NFT describes a non-fungible type of asset.

An NFT on Tezos can be implemented through an FA2-compatible contract.

However, not every FA2 token is an NFT.

The same standard can manage ordinary fungible balances and many other token models.

Calling an asset FA2 explains its technical interface but does not fully explain its economic characteristics.

FA2 vs. a Multi-Asset Contract

FA2 allows multi-asset contracts, but an FA2 contract does not need to contain multiple token types.

A single-token fungible contract can still follow FA2.

A one-collection NFT contract can also follow FA2.

Multi-asset support is a capability of the standard rather than a requirement that every implementation must use.

How Do Wallets Display FA2 Tokens?

A wallet can use the contract address, token ID, ledger information, metadata, and indexer data to display an FA2 asset.

The wallet may show the token’s name, symbol, balance, image, and transfer options.

Some tokens may not appear automatically when their metadata is missing or the wallet has not indexed the contract.

A missing display does not necessarily mean that the onchain balance is zero.

Users should confirm the contract address, token ID, and blockchain data through a compatible explorer or indexer.

A wallet interface should not be treated as the final authority when it conflicts with the contract’s actual storage.

How Do Marketplaces Use FA2 Operators?

A marketplace may ask a token owner to add the marketplace contract as an operator.

This permission allows the marketplace to transfer the specified token after a sale is completed.

The owner does not need to sign a separate token-transfer transaction at the exact moment a buyer accepts the listing.

The marketplace should use the permission only under its published sale rules.

A malicious marketplace could attempt an unauthorized transfer while the approval remains active.

Users should verify the operator address before approving it.

They should also remove permissions for applications they no longer trust or use.

What Are FA2 Standard Errors?

FA2 defines standard error names so wallets and decentralized applications can interpret common failures consistently.

The FA2 error documentation lists the standard error categories used by compatible implementations.

FA2_TOKEN_UNDEFINED means that a requested token ID does not exist in the contract.

FA2_INSUFFICIENT_BALANCE means that the source does not own enough tokens for the requested transfer.

FA2_NOT_OPERATOR means that the caller lacks permission to transfer the owner’s tokens.

FA2_NOT_OWNER means that an owner-only action was requested by another account.

FA2_TX_DENIED means that the contract’s policy rejected the transfer.

FA2_OPERATORS_UNSUPPORTED means that the contract does not permit the requested operator behavior.

Contracts can define additional custom errors for features outside the standard.

Security Risks of FA2 Tokens

FA2 compatibility does not guarantee smart contract security.

A contract may contain a flaw that changes balances incorrectly or allows unauthorized minting.

An administrator may have permission to pause transfers, mint unlimited tokens, modify metadata, or control other important behavior.

A malicious contract can display a familiar token name while using unrelated economic rules.

Operator permissions can expose assets when users approve an unsafe application.

External metadata can disappear or change when it is not stored through an integrity-protected method.

Unverified custom entrypoints can create behavior that standard wallet interfaces do not reveal.

Users should review the contract address, source code, audit history, minting controls, transfer policy, metadata storage, and administrator powers.

Operator Permission Risk

An FA2 operator approval is powerful because it is tied to a token ID rather than a small one-time amount.

The operator may move the owner’s available balance of that token type while authorization remains active.

A deceptive application may disguise an operator request as a harmless login or account connection.

Wallet users should read the transaction details and verify the operator address.

Disconnecting a wallet from a website does not necessarily remove an onchain operator authorization.

The user must submit the appropriate remove-operator action when revocation is required.

Minting and Supply Risk

The FA2 standard does not impose a universal maximum supply.

A token issuer may retain the ability to create additional tokens.

New minting can dilute existing holders or reduce the scarcity of an NFT collection.

An administrator key compromise can create unauthorized supply when minting power is centralized.

Users should determine who can mint, whether a cap exists, and whether the authority can be changed.

Metadata claims about fixed supply should be confirmed against actual contract behavior.

Transfer Restriction Risk

An FA2 token can use a policy that limits or completely prevents transfers.

A token can therefore appear in a wallet but remain impossible to sell or send.

An administrator may also have a pause mechanism when the implementation includes one.

Transfer restrictions can serve legitimate security, identity, or compliance purposes.

They can also create unexpected custody and liquidity risk for holders.

Users should test or verify transfer rules before assigning financial value to an unfamiliar token.

Metadata and Media Risk

Onchain ownership does not guarantee permanent access to offchain media.

An NFT may reference an image or document hosted outside the blockchain.

The file can become unavailable when hosting ends or an unpinned storage object is removed.

A mutable web address can also serve different content later.

Content-addressed storage improves integrity because changing the file changes its content identifier.

Availability still depends on someone retaining and serving the data.

Collectors should review the metadata URI, storage method, content hash, and backup plan.

How Developers Can Create FA2 Contracts

Developers can implement TZIP-12 directly, but using a maintained library can reduce interface and testing mistakes.

The SmartPy FA2 library provides base classes for fungible tokens, NFTs, and single-asset contracts.

It also provides optional modules for features such as administration, minting, burning, and transfer policies.

Developers should choose only the features required by the project.

Unused administrator powers can increase risk without improving functionality.

Every custom entrypoint should preserve the standard’s required behavior and error expectations.

Contracts should be tested on a Tezos test environment before mainnet deployment.

FA2 Development Best Practices

Use the exact TZIP-12 parameter structures for required entrypoints.

Test single transfers, batch transfers, zero-value transfers, and insufficient balances.

Test every supported and unsupported operator action.

Verify that undefined token IDs produce appropriate failures.

Document minting, burning, pausing, and administrator permissions clearly.

Publish contract and token metadata through stable, integrity-protected locations.

Use standard error names for failures covered by FA2.

Test wallet, indexer, marketplace, and application integrations.

Review storage growth and transaction costs for large batches or collections.

Obtain an independent security review before managing valuable assets.

What Is FA2.1?

FA2.1 is a proposed evolution of the FA2 token interface.

It is associated with TZIP-26 and adds concepts such as events, onchain views, finite allowances, and Tezos tickets.

Current SmartPy documentation describes FA2.1 as a draft.

Developers should not assume that every FA2 wallet or application automatically supports FA2.1-specific features.

Existing FA2 contracts remain distinct deployments and do not change automatically when a newer proposal is developed.

Projects considering FA2.1 should study its additional mechanisms and current tooling support carefully.

Common Misconceptions About FA2

FA2 is not a cryptocurrency by itself.

It is a standard that token smart contracts can implement.

FA2 does not mean that every token is fungible.

FA2 does not mean that every token is an NFT.

One FA2 contract does not always manage multiple assets.

The token ID alone does not uniquely identify an FA2 token.

FA2 compatibility does not guarantee a fixed supply.

Minting and burning are not required by the standard.

An FA2 operator is not necessarily limited to one token unit or one transfer.

Metadata does not determine actual ownership or transfer rights.

A visible wallet balance does not prove that the token can be transferred or sold.

FA2 compliance does not prove that a contract has been audited or is free from malicious behavior.

Frequently Asked Questions

What does FA2 mean on Tezos?

FA2 means Financial Application 2, a unified Tezos token standard formally defined by TZIP-12.

Is FA2 a cryptocurrency?

No, FA2 is a smart contract interface that can be used to create many different cryptocurrencies and digital assets.

Is FA2 only for NFTs?

No, FA2 supports fungible tokens, NFTs, multi-asset contracts, non-transferable assets, and custom token models.

Can one FA2 contract contain multiple tokens?

Yes, one contract can manage several token IDs with different supplies, owners, metadata, and behaviors.

How is an FA2 token uniquely identified?

It is identified by the combination of its Tezos contract address and token ID.

What token ID does a single-token FA2 contract use?

A contract supporting only one token type must use token ID 0.

Where are FA2 balances stored?

They are stored in the ledger maintained by the FA2 smart contract.

Are FA2 tokens stored directly in a wallet?

The wallet controls the account, while the token contract’s ledger records that account’s balance or ownership.

What are the required FA2 entrypoints?

The required entrypoints are transfer, balance_of, and update_operators.

What does the transfer entrypoint do?

It moves one or more token amounts from source accounts to destination accounts through a batch-oriented interface.

What does balance_of do?

It requests balances for account and token ID pairs and sends the results to a callback contract.

What does update_operators do?

It allows token owners to add or remove accounts authorized to transfer specified token IDs on their behalf.

What is an FA2 operator?

An operator is an account or contract authorized to move a specified token type belonging to another account.

Can an operator transfer all of an owner’s tokens?

For the authorized token ID, the operator can generally transfer the owner’s available balance while the approval remains active.

Can an FA2 operator approval be removed?

Yes, the owner can submit a remove-operator action when the contract’s transfer policy supports operators.

Does disconnecting a wallet remove an operator?

No, disconnecting a website session does not automatically revoke an onchain operator permission.

Can FA2 tokens be non-transferable?

Yes, an FA2 implementation can use a policy that rejects all ordinary transfers.

Can an FA2 contract pause transfers?

It can when the implementation includes an administrator-controlled pause feature.

Does FA2 require a mint function?

No, minting is optional and depends on the contract’s design.

Does FA2 require a burn function?

No, burning is also an optional feature.

Does FA2 guarantee a maximum supply?

No, supply limits and minting authority are defined by each individual token contract.

What is FA2 token metadata?

It is information associated with a token ID, such as its name, symbol, decimals, description, and media links.

What is FA2 contract metadata?

It is information about the smart contract itself, including its name, version, interfaces, source information, and views.

What does the decimals field do?

It tells wallets how to display the token’s integer balance with a decimal point.

Do decimals make a token divisible?

They provide a display convention for integer units, while the contract’s transfer and supply logic determines the asset’s practical divisibility.

Are FA2 transaction fees paid in the token?

Tezos protocol fees are generally paid in tez even when the transaction transfers an FA2 token.

What is the difference between tez and an FA2 token?

Tez is the native Tezos cryptocurrency, while an FA2 token is managed by a smart contract ledger.

What is the difference between FA1.2 and FA2?

FA1.2 focuses on fungible tokens, while FA2 supports broader token types, token IDs, batch transfers, and multi-asset contracts.

Can a wallet automatically detect every FA2 token?

Not always, because detection depends on indexing, metadata, contract support, and the wallet’s integration.

Can an FA2 token have fake metadata?

Yes, anyone can create a contract with a misleading name, symbol, image, or description.

Does FA2 compliance mean a token is safe?

No, compliance shows interface compatibility rather than proving security, value, legitimacy, or legal status.

Can an FA2 NFT lose its image?

Yes, externally stored media can become unavailable when it is not preserved or hosted reliably.

What is FA2.1?

FA2.1 is a draft evolution of FA2 that proposes features including events, onchain views, finite allowances, and tickets.

Does FA2.1 automatically replace FA2?

No, existing FA2 contracts remain separate deployments, and support for FA2.1-specific features depends on current standards and tooling.

Conclusion

FA2 is the unified Tezos token standard defined by TZIP-12.

It provides a common interface for fungible tokens, NFTs, non-transferable assets, hybrid token systems, and multi-asset smart contracts.

Every FA2 token is identified by the combination of its contract address and token ID.

The standard requires transfer, balance_of, and update_operators entrypoints.

Its batch-oriented design allows several token movements or requests to be handled through one contract call.

Operator permissions allow applications to transfer specified token types on behalf of owners, but users must revoke permissions they no longer need.

FA2 gives developers significant freedom to define transfer policies, supply rules, minting, burning, administration, and custom features.

That flexibility improves support for many crypto use cases while making contract-level due diligence essential.

Users should verify the contract address, token ID, metadata, supply controls, transfer rules, operator permissions, source code, and administrator authority before interacting with an unfamiliar FA2 asset.

FA2 standardization improves compatibility across the Tezos ecosystem, but it does not guarantee that a token is secure, valuable, transferable, or legitimate.