FA1.2 (Tezos)

What Is FA1.2 on Tezos?

FA1.2 is a fungible token standard for smart contracts on the Tezos blockchain.

It defines a common interface for transferring tokens, approving token spending, checking balances, checking allowances, and reading the total token supply.

FA1.2 is formally defined by Tezos Improvement Proposal 7, also known as TZIP-7.

The standard is designed specifically for fungible tokens, meaning that each unit of a particular FA1.2 asset is interchangeable with every other unit of the same asset.

An FA1.2 contract can represent a payment token, governance token, wrapped cryptocurrency, stable-value asset, loyalty point, application currency, or another divisible digital asset.

FA1.2 is a smart contract interface rather than a cryptocurrency by itself.

Each FA1.2 token is created and managed by its own Tezos smart contract.

The contract maintains a ledger that maps Tezos account addresses to token balances.

Users interact with the contract to transfer tokens or authorize another account or application to spend a limited quantity on their behalf.

FA1.2 does not determine a token’s price, legal status, economic purpose, maximum supply, or administrative structure.

Those characteristics depend on the individual token contract and the project that controls it.

What Does FA1.2 Mean?

FA stands for Financial Application.

The number 1.2 identifies the version of the fungible asset interface defined by TZIP-7.

The standard developed from earlier Tezos fungible-token interface work and added a formal approval system for delegated token transfers.

The term FA1.2 commonly refers both to the standard and to tokens implemented according to that standard.

However, the smart contract is the component that technically follows FA1.2.

A token does not become FA1.2-compatible merely because its issuer uses the term in a name, symbol, website, or marketing description.

The deployed contract must expose the required entrypoints with the expected parameter types and behavior.

Why Was FA1.2 Created?

Smart contracts can define token behavior in many different ways.

Without a shared standard, every wallet and decentralized application would need custom integration code for every fungible token.

One token might use one name for transfers, while another might use a completely different parameter structure.

Balance queries and spending permissions could also behave differently across contracts.

FA1.2 provides a predictable interface that reduces this fragmentation.

Wallets can prepare token transfers through a known transfer entrypoint.

Applications can request spending permission through a known approve entrypoint.

Indexers can identify balance changes and present token activity in a consistent format.

Development tools can check whether a contract exposes the expected FA1.2 interface.

The current Octez FA1.2 documentation includes dedicated tools for checking compatibility, transferring tokens, approving spenders, and reading token information.

Standardization improves interoperability, but it does not guarantee that a particular contract is secure, valuable, or honestly managed.

How Does an FA1.2 Token Work?

An FA1.2 token is managed by a Tezos smart contract that stores a ledger of account balances.

When tokens are issued, the contract assigns balances to one or more account addresses.

A holder transfers tokens by calling the contract rather than sending the tokens directly through Tezos protocol-level balance accounting.

The contract verifies the source account, destination account, requested amount, caller authorization, and available balance.

If the checks succeed, the contract subtracts the amount from the source balance and adds it to the destination balance.

If the checks fail, the transaction reverts and the ledger remains unchanged.

An account can also approve another account or smart contract to spend a limited amount from its balance.

The approved amount is known as an allowance.

Each delegated transfer normally reduces the remaining allowance by the amount transferred.

The contract can provide balance, allowance, and total-supply information through standardized query interfaces.

What Is Fungibility?

Fungibility means that individual units of an asset are interchangeable.

One unit of a particular FA1.2 token has the same contract-defined properties as another unit of that token.

A holder usually does not need to track which exact token unit was received.

The account ledger records quantities rather than unique token identities.

This makes FA1.2 suitable for assets intended to function as currencies, credits, voting units, collateral, or divisible claims.

FA1.2 is not designed to assign a unique identity and separate metadata record to every individual unit.

Unique digital assets are generally implemented through a more flexible token standard designed to support non-fungible tokens.

How Is an FA1.2 Token Identified?

An FA1.2 token is primarily identified by the Tezos smart contract address that manages it.

FA1.2 represents one fungible token type per contract rather than using many token IDs for unrelated assets.

When FA1.2 metadata uses the token metadata structure associated with later Tezos standards, its token ID must be 0.

The token name and ticker symbol are not reliable unique identifiers.

Different contracts can use the same name, symbol, image, and decimal settings.

A malicious issuer can also copy the branding of a legitimate asset.

Users should verify the complete contract address through trustworthy project documentation before transferring, approving, or purchasing an FA1.2 token.

What Are the Main FA1.2 Entrypoints?

The FA1.2 interface defines entrypoints for transfers, approvals, balance queries, allowance queries, and total-supply queries.

The official Octez interface reference lists transfer, approve, getBalance, getAllowance, and getTotalSupply as the main FA1.2 operations.

Individual contracts may include additional entrypoints for minting, burning, pausing, administration, redemption, or other project-specific behavior.

Additional entrypoints are not automatically part of the FA1.2 standard.

Transfer Entrypoint

The transfer entrypoint moves a specified token amount from one address to another address.

The call identifies a source address, destination address, and transfer amount.

When the caller is moving tokens from its own account, the contract verifies that the account has enough tokens.

When the caller is moving tokens from another account, the caller must have sufficient allowance from that owner.

A delegated transfer reduces the spender’s remaining allowance.

The transfer fails when the balance or allowance is insufficient.

The FA1.2 transfer entrypoint combines direct owner transfers and delegated transfers within one interface.

Approve Entrypoint

The approve entrypoint allows a token holder to authorize a spender to transfer a limited amount of the holder’s tokens.

The spender may be another user account or a smart contract.

Applications can use this mechanism to collect payments, supply liquidity, lock collateral, complete trades, or perform other authorized actions.

The approval does not immediately move the tokens.

It creates an allowance that can be used in later transfer calls.

The holder continues to own the tokens until a permitted transfer occurs.

GetBalance Entrypoint

The getBalance entrypoint returns the FA1.2 token balance associated with a specified address.

The reported balance is stored in the token contract rather than in the protocol-level tez balance.

A wallet, indexer, or application can use this information to show how many tokens an account controls.

Current Octez tools can evaluate supported balance queries offchain without requiring the user to inject a separate information-return transaction.

GetAllowance Entrypoint

The getAllowance entrypoint returns the remaining amount that one address may transfer from another address.

The query identifies both the token owner and the approved spender.

A result of zero means that the spender currently has no remaining FA1.2 allowance from that owner.

A positive result shows the maximum amount that can still be transferred under the recorded permission.

GetTotalSupply Entrypoint

The getTotalSupply entrypoint returns the total number of FA1.2 token units recognized by the contract.

The total supply can change when the implementation includes minting or burning functionality.

A total-supply query does not reveal how concentrated the tokens are among holders.

It also does not reveal whether additional tokens can be created later.

What Is an FA1.2 Allowance?

An FA1.2 allowance is a limited spending authorization granted by a token owner to another address.

Assume an owner approves an application to spend 100 tokens.

The application can transfer up to 100 tokens from the owner’s balance, subject to the contract’s rules.

If the application transfers 30 tokens, the remaining allowance normally becomes 70 tokens.

The application cannot transfer more than the owner’s available balance even when the recorded allowance is larger.

The application also cannot use the allowance for a different FA1.2 token contract.

Allowances remain recorded onchain until they are used, changed, or reset.

Disconnecting a wallet from a website does not automatically cancel an allowance.

The holder must submit an onchain approval update when revocation is required.

How Does FA1.2 Differ From an Operator Permission?

FA1.2 uses numerical allowances.

The owner chooses a maximum quantity that the spender may transfer.

The allowance generally decreases as transfers occur.

An operator-based token model commonly grants permission for a particular token type without specifying a decreasing numerical amount.

This difference can affect wallet interfaces and application security.

An FA1.2 approval for 50 units should not be displayed as though it grants unlimited control.

Likewise, an operator authorization should not be interpreted as a one-time numerical allowance.

Why Must FA1.2 Allowance Changes Be Handled Carefully?

Changing an existing token allowance can create a race condition.

A spender may attempt to use the old allowance before the owner’s replacement approval is confirmed.

The spender may then attempt to use the new allowance after it becomes active.

TZIP-7 addresses part of this problem by forbidding a direct change from one nonzero allowance to another nonzero allowance.

The owner generally needs to set the allowance to zero before assigning a new nonzero amount.

The TZIP-7 allowance specification also explains that resetting to zero is not by itself a complete guarantee against every adversarial timing scenario.

A careful user should wait for the zero-allowance transaction to be included before granting a replacement allowance.

High-value applications should also examine whether the spender used any allowance while the update was pending.

FA1.2 Allowance Example

Assume a wallet holds 1,000 units of an FA1.2 token.

The owner approves a decentralized application to spend 200 units.

The application later transfers 75 units to a smart contract.

The owner’s token balance falls to 925 units.

The application’s remaining allowance falls to 125 units.

If the application attempts to transfer 150 additional units, the transaction fails because the remaining allowance is too small.

The owner can reduce the allowance to zero when the application no longer needs access.

Does FA1.2 Support Unlimited Approvals?

An FA1.2 holder can approve a very large numerical amount when the contract accepts it.

Some applications may treat this as an effectively unlimited approval.

A large allowance reduces the need for repeated approval transactions.

It also increases the amount at risk if the approved contract is compromised, malicious, or used incorrectly.

Users should approve only the amount reasonably required when practical.

Old or unnecessary allowances should be reset to zero.

How Are FA1.2 Balances Stored?

An FA1.2 implementation normally stores balances in a ledger within the token contract.

The ledger maps each holder’s address to a natural-number token quantity.

Some implementations store balances and allowances together in a structured ledger entry.

TZIP-7 describes a standardized indexable layout in which an owner record can contain both its balance and a map of spender allowances.

Not every historical implementation must use identical internal storage as long as its public behavior matches the required interface.

Applications should interact through the standard entrypoints or reliable indexed data rather than assuming a particular private storage layout.

Does FA1.2 Use Token IDs?

FA1.2 is a single-token contract standard and does not use token IDs to distinguish many independent token types in ordinary transfers.

When FA1.2 token metadata is represented through the metadata format shared with newer standards, the token ID is fixed at 0.

A contract that needs many separate fungible tokens under one address is generally better suited to a multi-asset standard.

Users should not assume that token ID 0 uniquely identifies an FA1.2 asset without also knowing its contract address.

How Does FA1.2 Metadata Work?

The original FA1.2 interface focuses primarily on ledger and allowance behavior.

TZIP-7 does not independently define a complete contract metadata system.

Its current token metadata guidance uses the same general token metadata form associated with the Tezos multi-asset standard.

The token ID used for FA1.2 metadata must be 0.

Metadata can include the token name, symbol, decimals, description, and other display information.

Contract-level information can also be published according to TZIP-16 contract metadata.

TZIP-16 supports metadata stored onchain or referenced through offchain locations such as content-addressed storage or web services.

Metadata helps wallets and explorers display an asset, but it does not control the actual ledger unless the contract explicitly uses it in business logic.

What Does Decimals Mean for an FA1.2 Token?

FA1.2 balances are stored as whole natural-number units.

The decimals metadata field tells wallets where to place the decimal point for display.

Assume a raw contract balance is 1,500,000 and the token uses six decimals.

A wallet would display the balance as 1.5 tokens.

The smart contract still records 1,500,000 smallest units.

Decimals do not determine the market price, total supply, or scarcity of the token.

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

Does FA1.2 Define a Maximum Supply?

No, FA1.2 does not require a fixed maximum supply.

The contract exposes a way to read total supply, but the issuer may add custom minting or burning functionality.

A token may begin with a fixed supply and have no method for creating more.

Another token may allow an administrator, governance contract, or defined protocol process to mint additional units.

Users should inspect the deployed contract and administrative permissions before assuming that supply is permanently limited.

A published supply figure describes the current state and does not necessarily describe future issuance.

Does FA1.2 Require Minting?

No, minting is not one of the required FA1.2 entrypoints.

A contract may create its entire supply during deployment.

It may also include a custom minting function controlled by an administrator or another smart contract.

The minting policy should identify who can create tokens, whether a supply cap exists, and whether the authority can be transferred or removed.

Unauthorized or unlimited minting can dilute existing holders and disrupt token markets.

Does FA1.2 Require Burning?

No, burning is also optional.

A custom burn function can permanently reduce balances and total supply according to the contract’s rules.

The function may allow holders to burn their own tokens or may be restricted to an administrator.

Sending tokens to an inaccessible address does not always update the contract’s reported total supply.

A true contract-level burn should reduce both the relevant balance and the total-supply accounting when that is the intended design.

FA1.2 vs. Tez

Tez is the native cryptocurrency of the Tezos blockchain.

FA1.2 tokens are created and managed by smart contracts.

Tez balances are maintained directly by the Tezos protocol.

FA1.2 balances are maintained in the storage of an individual token contract.

Tezos transaction fees are generally paid in tez even when the transaction transfers an FA1.2 token.

Holding an FA1.2 balance does not automatically provide enough tez to pay for a token transfer or approval transaction.

The Tezos token documentation explains the distinction between protocol-level tez and tokens represented through smart contract ledgers.

FA1.2 vs. FA2

FA1.2 is designed specifically for one fungible token managed by one smart contract.

FA2 is a newer and more flexible token interface.

FA2 can support fungible tokens, NFTs, non-transferable assets, hybrid models, and multiple token IDs in one contract.

FA1.2 uses numerical spender allowances.

Standard FA2 commonly uses token-specific operator permissions rather than decreasing numerical allowances.

FA1.2 provides separate single-request transfer structures, while FA2 uses batch-oriented transfer and balance-query structures.

FA2 also provides more explicit support for custom transfer policies.

Current SmartPy guidance recommends FA2 for newly created token contracts because it supports a wider range of use cases.

This recommendation does not make existing FA1.2 contracts invalid.

Current Octez tools continue to provide dedicated FA1.2 support.

FA1.2 vs. FA2.1

FA2.1 is a proposed evolution of the FA2 family that includes features such as finite allowances, events, onchain views, and ticket-related functionality.

Its finite-allowance concept addresses a use case familiar from FA1.2 while retaining the broader multi-asset structure of FA2.

Current SmartPy documentation describes FA2.1 as a draft.

Existing FA1.2 contracts do not automatically change when newer standards are proposed.

Wallet and application support should be verified separately for each standard.

Can an FA1.2 Token Be Converted to FA2?

An FA1.2 contract cannot normally be transformed into FA2 merely by changing its label.

The two standards use different interfaces and permission models.

A project that wants to migrate may deploy a new FA2 contract and create a controlled conversion process.

The process may lock or burn old tokens and issue corresponding new tokens.

Another design may take a balance snapshot and distribute replacement assets.

Migration creates technical, governance, security, and user-experience risks.

Users should verify the official migration contract and avoid unsolicited links claiming to exchange old tokens.

Can FA1.2 Support Wrapped Crypto Assets?

Yes, an FA1.2 contract can represent a wrapped cryptocurrency on Tezos.

A wrapped token is a separate smart contract asset intended to track another asset through a custody, bridge, minting, or redemption mechanism.

The FA1.2 interface standardizes transfers and allowances but does not guarantee that the wrapped token is fully backed.

Users must evaluate reserves, redemption conditions, custodian controls, bridge security, minting authority, and proof of backing.

The official Tezos guidance on wrapped tokens emphasizes that a wrapped asset is technically separate from the original cryptocurrency.

Can FA1.2 Support Stable-Value Tokens?

Yes, an FA1.2 token can be designed to target the value of a fiat currency, commodity, cryptocurrency, or another reference asset.

FA1.2 itself does not maintain the target value.

Price stability depends on the issuer, collateral, reserves, redemption mechanism, market liquidity, oracle system, and economic design.

A token can comply with FA1.2 while losing its intended peg.

Technical compliance should not be treated as evidence of reserve quality or price stability.

How Do Wallets Display FA1.2 Tokens?

A wallet can identify an FA1.2 contract, query the user’s balance, and read available metadata.

It may display the token name, symbol, decimal-adjusted balance, logo, and transaction history.

Some wallets rely on indexers instead of reading every contract directly.

The Tezos indexer documentation explains that indexers organize FA1.2 and FA2 token information for easier application access.

A token may fail to appear automatically when its metadata is missing, unsupported, or not yet indexed.

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

Users can verify the contract and ledger information through compatible blockchain tools.

How Do Decentralized Applications Use FA1.2?

A decentralized application can request approval to spend a defined amount of an FA1.2 token.

After approval, the application can call the token contract to transfer tokens from the owner’s balance.

This pattern can support deposits, swaps, collateral, subscriptions, auctions, lending, payments, and other crypto activities.

The application should not request a larger allowance than it reasonably needs.

The user should verify the token contract, spender address, and approved amount before signing.

The application should also handle insufficient balances, insufficient allowances, and changed approvals safely.

Can FA1.2 Transfers Be Batched?

The core FA1.2 transfer entrypoint describes one source, one destination, and one amount per call.

However, a Tezos operation can contain multiple contract calls.

Current Octez tools support batch transfer commands involving a single source and multiple recipients across FA1.2 contracts.

Batching can improve convenience for distributions and treasury operations.

A failure within an atomic sequence can cause the related operation to fail rather than leaving a partially completed result.

Large batches can also consume substantial gas and require careful testing.

FA1.2 Standard Errors

TZIP-7 defines errors associated with insufficient allowances and unsafe allowance changes.

A transfer can fail when the owner does not have enough tokens.

A delegated transfer can fail when the spender’s allowance is smaller than the requested amount.

An approval can fail when it attempts to replace one nonzero allowance directly with another nonzero allowance.

Individual implementations may use additional error names for administration, pausing, minting, burning, or other custom features.

Applications should display errors in language that helps users understand whether the problem involves balance, allowance, authorization, or contract policy.

Security Risks of FA1.2 Tokens

FA1.2 compatibility does not prove that a smart contract is secure.

A contract can expose the correct entrypoints while containing faulty or malicious internal logic.

An administrator may be able to mint new supply, pause transfers, freeze accounts, change metadata, or replace critical addresses.

A compromised approved spender can transfer tokens up to the available allowance.

A copied name and symbol can make a fraudulent token appear legitimate.

A wrapped token can become undercollateralized even when its FA1.2 ledger works correctly.

Users should examine contract source code, audit information, administration, supply controls, allowances, and redemption rules.

Allowance Security Risk

An allowance gives another address direct authority over part of the owner’s token balance.

A malicious application can use the allowance immediately after approval.

A compromised contract can use permissions granted before the compromise.

A large unused allowance can remain active for a long period.

Users should review the spender address carefully and avoid approving unexplained transactions.

Allowances that are no longer required should be reset to zero.

Private keys and recovery phrases are never required to grant or revoke an FA1.2 allowance.

Administrative Control Risk

Custom FA1.2 contracts may include a privileged administrator.

The administrator may control minting, burning, pausing, account freezes, blacklists, fees, or contract upgrades.

These powers can support security and compliance operations.

They can also create centralization and abuse risks.

Users should determine whether the administrator is one account, a multisignature contract, a governance system, or an immutable rule.

They should also determine whether administrative powers can be transferred or permanently removed.

Supply and Dilution Risk

A token can display a limited current supply while retaining unlimited future minting authority.

Additional issuance can reduce each existing unit’s share of the total supply.

A supply cap is meaningful only when it is enforced by the deployed contract or an equally strong governance restriction.

Promises made in websites or social posts do not override onchain minting permissions.

Users should distinguish circulating supply, total supply, and possible future supply.

Fake Token Risk

Anyone can deploy a Tezos smart contract using a familiar token name or symbol.

Wallet metadata can make an unrelated token look similar to a recognized asset.

The contract address is more reliable than the display name.

Users should obtain the verified contract address from trustworthy primary project sources.

An unsolicited token arriving in a wallet should not be treated as valuable without independent verification.

Links included in unknown token metadata may lead to phishing websites.

Smart Contract Risk

A programming error can allow unauthorized transfers, incorrect balances, locked tokens, or broken supply accounting.

Formal interface compliance does not prove that every internal branch behaves correctly.

An independent audit can reduce risk but cannot guarantee that no vulnerability exists.

Contracts with complex minting, redemption, fee, upgrade, or collateral logic require analysis beyond the basic FA1.2 entrypoints.

The Tezos token risk guidance recommends checking source-code availability, audits, supply limits, and transfer rules.

Private Key and Wallet Security

FA1.2 token ownership ultimately depends on control of the Tezos account authorized to manage the recorded balance.

An attacker who obtains the account’s private key can sign transfers and approvals.

No legitimate token contract needs the user’s recovery phrase to show a balance or prepare a transaction.

The Octez key-management documentation emphasizes secure storage and signing practices for tez and FA token operations.

Users should verify transaction details on the signing device before approving an operation.

How to Verify an FA1.2 Token

Confirm the complete Tezos contract address through a trustworthy primary source.

Check whether the contract exposes the required FA1.2 interface.

Review the token name, symbol, decimals, and total supply.

Determine who can mint, burn, pause, freeze, or upgrade the token.

Inspect existing allowances before interacting with a new application.

Review independent security assessments when valuable assets are involved.

For wrapped or stable-value tokens, verify reserves and redemption rules separately from the FA1.2 interface.

Do not rely on a ticker symbol, wallet icon, or social-media message as proof of authenticity.

FA1.2 Development Best Practices

Developers should follow the exact TZIP-7 entrypoint types and authorization behavior.

Direct owner transfers and allowance-based transfers should be tested separately.

Tests should cover zero balances, insufficient balances, insufficient allowances, and zero-value transfers.

Allowance changes should follow the standard protection against direct nonzero-to-nonzero updates.

Minting, burning, pausing, and administration should be documented clearly when included.

Metadata should use stable and integrity-protected storage where practical.

Applications should use the caller identity appropriate to the immediate contract interaction rather than trusting an unrelated transaction origin.

Developers should test integrations with wallets, indexers, and Octez tools.

High-value contracts should receive independent security review before deployment.

Common Misconceptions About FA1.2

FA1.2 is not the native cryptocurrency of Tezos.

FA1.2 is not an individual token or project.

It is a standard that fungible-token contracts can implement.

FA1.2 does not support unique NFTs as its primary token model.

FA1.2 compliance does not guarantee a fixed supply.

Minting and burning are not mandatory standard entrypoints.

An approval does not immediately transfer tokens.

Disconnecting a wallet does not revoke an onchain allowance.

A token’s name or symbol does not uniquely identify its contract.

FA2 becoming the preferred standard for new development does not erase existing FA1.2 contracts.

A correct FA1.2 interface does not guarantee that the token is safe, backed, transferable under every condition, or financially valuable.

Frequently Asked Questions

What is FA1.2 on Tezos?

FA1.2 is a Tezos fungible-token smart contract standard defined by TZIP-7.

What does FA stand for in FA1.2?

FA stands for Financial Application.

Is FA1.2 a cryptocurrency?

No, it is an interface used to create and manage fungible cryptocurrencies and other tokenized assets.

Is FA1.2 still supported?

Yes, current Octez documentation continues to provide dedicated FA1.2 compatibility, transfer, approval, and query tools.

Is FA1.2 the newest Tezos token standard?

No, FA2 is newer and more flexible, while FA2.1 is currently described as a draft evolution of the FA2 family.

Should developers create new FA1.2 tokens?

Current Tezos development guidance generally recommends FA2 for new token contracts, although project requirements and legacy integrations may differ.

Can FA1.2 create NFTs?

FA1.2 is designed for fungible tokens rather than unique non-fungible assets.

Can one FA1.2 contract manage many token types?

The standard represents one fungible token type per contract.

How is an FA1.2 token identified?

It is primarily identified by the Tezos contract address that manages its ledger.

What token ID does FA1.2 use for metadata?

The token ID used in the shared token metadata format must be 0.

Where are FA1.2 balances stored?

They are recorded in the storage ledger of the FA1.2 smart contract.

What is the FA1.2 transfer entrypoint?

It moves a specified amount from a source address to a destination address after balance and authorization checks.

What is the FA1.2 approve entrypoint?

It gives a spender permission to transfer up to a specified quantity from the owner’s token balance.

What is an FA1.2 allowance?

An allowance is the remaining amount that an approved address can transfer from a token owner’s balance.

Does an allowance decrease after use?

Yes, a delegated transfer normally reduces the remaining allowance by the amount transferred.

Does connecting a wallet create an allowance?

No, an allowance is created only when the user signs and submits the relevant approval operation.

Does disconnecting a wallet revoke an allowance?

No, the owner must update the onchain allowance, normally by setting it to zero.

Can I change one nonzero allowance directly to another?

TZIP-7 forbids direct nonzero-to-nonzero allowance changes as protection against a known race condition.

How should an allowance be changed?

The holder should first set the allowance to zero, wait for confirmation, and then assign the new amount after checking for intervening spending.

Does FA1.2 require minting?

No, a minting function is optional and depends on the individual implementation.

Does FA1.2 require burning?

No, burning is also an optional custom feature.

Does FA1.2 guarantee a supply cap?

No, users must review the contract’s actual minting authority and supply rules.

How can I check an FA1.2 balance?

A compatible wallet, indexer, contract query, or Octez FA1.2 balance command can read the ledger balance.

How can I check an FA1.2 allowance?

The getAllowance interface or a compatible indexer can report the remaining permission between an owner and spender.

How can I check FA1.2 total supply?

The getTotalSupply interface returns the current supply recorded by the token contract.

Are FA1.2 transaction fees paid with the token?

Tezos protocol transaction fees are generally paid in tez.

Can FA1.2 represent a wrapped cryptocurrency?

Yes, but FA1.2 compliance does not guarantee reserves, redemption, or bridge security.

Can FA1.2 represent a stable-value asset?

Yes, but the standard itself does not guarantee that the asset maintains its intended price.

Can an FA1.2 administrator freeze tokens?

A custom implementation may include freezing or pausing powers even though they are not required by the standard.

Can an FA1.2 token be migrated to FA2?

A project can create a separate migration process, but the old contract does not automatically become FA2-compatible.

Is an FA1.2 token safe because it follows a standard?

No, standard compliance improves interface compatibility but does not guarantee secure code, honest administration, backing, liquidity, or value.

Conclusion

FA1.2 is the Tezos fungible-token standard formally defined by TZIP-7.

It establishes a shared interface for transfers, approvals, balances, allowances, and total-supply information.

An FA1.2 smart contract maintains a ledger that maps Tezos addresses to interchangeable token balances.

Its numerical allowance system lets holders authorize applications or other accounts to transfer a limited quantity of tokens.

Allowances require careful management because they remain active onchain and can create race-condition or contract-compromise risks.

FA1.2 does not require minting, burning, pausing, freezing, metadata administration, or a fixed maximum supply.

Those features depend on the individual contract implementation.

FA2 is now the more flexible standard for new Tezos token development, but FA1.2 contracts remain supported and continue to be used.

Users should verify the contract address, allowance amount, supply controls, administrator authority, metadata, audit history, and redemption terms before interacting with an unfamiliar FA1.2 token.

FA1.2 standardization improves compatibility across Tezos wallets, applications, indexers, and development tools, but it does not guarantee that a token is secure, legitimate, liquid, or valuable.