Token Program and Token-2022: understand a token’s features

Identify the program before interpreting the token

Solana has the original Token Program and the Token Extension Program, commonly called Token-2022. They are separate deployed programs with separate addresses. A mint's base owner identifies which program manages that issuance.

Both support familiar ideas such as a mint, holding accounts and transfers. Token-2022 extends the model with optional additional state and instructions. A parser built only for a simple original-program account can miss important fields or fail on a different layout.

The program address also matters when deriving an associated token account or constructing an instruction. Supplying the original program by habit for every mint can produce the wrong derivation or an unusable request.

Start with the exact mint on the intended cluster, read its base owner and use tools that understand that program. A ticker or a coloured verification label is not the format contract.

Features are selected for an issuance

Extensions can live on a mint or holding account and add a defined behaviour. Many require planning at initialisation, and some combinations are incompatible. A catalogue of extensions describes possible designs, not the enabled state of every Token-2022 asset.

A transfer fee changes how a moved amount is divided between available receipt and withheld fee. A non-transferable configuration restricts ordinary movement between holders. A transfer hook invokes additional programmed checks or behaviour. A permanent delegate provides a designated role with its own defined capabilities.

Other features address metadata, default state or presentation. Read each feature in terms of the action you intend to perform. A display conversion and an increase in raw spendable token quantity are different mechanisms.

For a token review, list the actual enabled extensions and the current state relevant to a transfer or deposit. This is more useful than deciding that the newer or older program is automatically preferable.

Displayed units can change while the raw holding stays fixed

The Scaled UI Amount extension lets a mint apply a configurable multiplier to its displayed balance. A wallet must interpret that feature before presenting the holding. Dividing the raw integer by the decimal scale alone does not reproduce every extension-aware display.

Take a fictional holding of 1,000,000 raw units with six decimals. Its unscaled quantity is one. A UI multiplier of two displays two units while the raw holding remains 1,000,000. If a corresponding display price changes from 100 per old unit to 50 per adjusted unit, the shown value remains 100. The unit adjustment alone did not create economic profit.

The Interest Bearing extension uses another conversion model: time and configured rate affect the calculated UI amount while ordinary raw balances remain unchanged until a token instruction changes them. A rate stored in a mint is not by itself proof of an issuer's backing or a redeemable return. Scaled UI Amount and Interest Bearing cannot be enabled together under the documented extension rules.

For a builder, preserve raw integers for holdings and use the actual mint's conversion rules for entry and display. Record the conversion context when interpreting historical UI quantities. For a user, investigate the enabled feature before treating a growing displayed count as a new transfer. Tokenized-asset examples show why consistent quantity and price units matter.

A capped transfer fee changes the net receipt

Work through a transfer-fee token

Choose a hypothetical token whose effective transfer fee is 1% with a maximum of 2 whole tokens per transfer. These are teaching settings, not a description of USDC or another live issuance.

Moving 100 tokens produces a 1-token fee under those settings. The recipient gets 99 available tokens, and the withheld fee is tracked in the destination account's extension state. A nominal amount of 100 therefore differs from the holder's newly available balance.

Moving 300 tokens at the same settings would calculate 3 tokens before the cap. The cap limits the fee to 2, leaving 298 available to the recipient. Real instructions use integer base units and the program's rounding rules, so builders must apply precision correctly.

Fee collection has separate authorities and instructions. A holder's ordinary available balance does not automatically include withheld amounts that the configured fee-withdrawal mechanism controls. Read the active fee configuration and any pending update when constructing a transfer.

For a swap, also ask which amount the route's output bound measures. A product must account for the token's actual transfer behaviour when quoting and validating the result.

Map the authorities behind the features

A remaining mint authority answers who can issue additional units under the program. A freeze authority answers a different question about holding-account restrictions. Removing one role does not remove all other controls.

Extensions introduce their own roles where defined. The authority that changes a transfer-fee configuration and the authority that withdraws withheld fees can be distinct. A hook adds another program whose code and administrative controls matter to the transfer path.

A permanent delegate differs from an ordinary delegate granted by a particular holder. Read that extension's documented power and current key rather than inferring it from a familiar wallet approval screen.

Keep the permission map specific: role, current authority, affected action and whether the relevant setting can change. That map explains what a user or integrating protocol needs to account for.

Check the destination’s supported configuration

A wallet may display an asset while a trading venue, deposit service or lending market cannot process one of its features. Display support, transfer construction and product acceptance are separate capabilities.

For an integration, use the correct program and derive or create holding accounts with the required space. Include additional accounts or instructions required by the enabled extensions. Simulate the actual configured asset rather than testing only a plain token with the same decimal count.

For a user, obtain the receiving product's current support information and review the constructed transaction. A service can reject a transfer flow that another wallet handles. Sending first and hoping an indexer recognises it is a poor way to establish compatibility.

After execution, reconcile source debit, destination available quantity and any withheld or charged components. A single transfer amount field may not explain all of those outcomes.

Build a short, usable token specification

Record the cluster, mint, owning program and decimals. Add enabled features, material authorities and the specific operations your product supports. For changing settings, keep the observation time.

Then test representative operations: creation where needed, receipt, transfer and the intended application action. Include a rejected or unsupported configuration in the tests so your UI can explain it.

Our account guide explains holding layout and derivation. Minimum received connects transfer behaviour to swap output. Together, they turn token-program selection into an observable set of rules.

Common questions