Solana Token-2022 extensions explained

Token program vs Token-2022 program

Solana stores token balances in separate SPL token accounts, each owned by either the legacy Token program or the Token-2022 program. The two are not interchangeable: a wallet address that holds USDC (classic Token) may also hold a Token-2022 mint in a different associated token account keyed to the new program ID.

Classic SPL Token has been frozen in feature scope for years. New protocol needs — regulatory transfer taxes, richer metadata without Metaplex, programmable transfer rules — required a new program rather than breaking every existing mint. Token-2022 reimplements the core mint/transfer/burn/approve instructions and adds an extension TLV region appended to mint and token account data.

From a user perspective, sends and receives look the same in a modern wallet. The differences show up in fee deductions, approval prompts, and block explorer labels. From a developer perspective, you must explicitly target the Token-2022 program ID when creating mints or deriving associated token addresses.

How extensions work

Extensions are optional features selected when the mint is initialized. Each extension reserves space in the mint account (or sometimes in holder token accounts) and registers handlers inside the Token-2022 program. You cannot add most extensions after the fact without a dedicated migration path — design choices at launch are sticky.

Think of a Token-2022 mint as a base coin plus a checklist of capabilities:

• Mint-level extensions — apply to every holder (transfer fee config, metadata pointer, permanent delegate).
• Account-level extensions — per-wallet state (e.g. withheld transfer fees waiting to be harvested, confidential balance ciphertext).
• Instruction hooks — external programs invoked on transfer, burn, or mint events.

Wallets and aggregators read extension headers to simulate transactions accurately. A swap that forgets to account for a 1% transfer fee will fail simulation or deliver fewer tokens than quoted — which is why mature interfaces call transaction simulation before asking you to sign.

Common extensions you will encounter

Transfer fee

The most visible extension in the wild. Each transfer withholds a percentage or fixed fee (configured at mint creation) that accumulates in a fee vault until the mint authority or a designated harvester withdraws it. Real-world stablecoins and exchange-issued assets use this for compliance revenue or protocol funding. Always check the quoted receive amount — sending 100 tokens does not mean the recipient gets 100 if a fee applies.

Transfer hook

Points to a separate program that must approve (or reject) every transfer instruction. Hooks enable allowlists, travel-rule checks, soulbound-style restrictions, or custom accounting. They add compute units and can break composability if a downstream program does not invoke the hook correctly. Treat hooked tokens like smart contracts with extra gates.

Metadata pointer

Stores a pointer from the mint to an external metadata account (often Metaplex Token Metadata, but not required). Lets fungible tokens ship name, symbol, and URI without legacy workarounds. Explorers and wallets use the pointer to render icons — if it is missing or malicious, you may see a blank or spoofed logo.

Interest-bearing / scaled UI amount

Some mints accrue interest on-chain or expose a scaled UI multiplier so the number shown in wallets increases over time while raw token amounts stay compatible with DeFi math. Rebasing and yield-bearing stablecoins experiment here. Read the protocol docs — APY display in a wallet may not match claimable underlying assets.

Permanent delegate and default account state

A permanent delegate can move tokens from any holder's account without per-wallet approval — powerful for regulated settlement, dangerous if the delegate key is compromised. Default account state can initialize new holder accounts as frozen until explicitly thawed, useful for permissioned launches.

Confidential transfer (overview)

Uses zero-knowledge proofs so encrypted balances can move without revealing amounts on ledger. Uptake is niche compared to public SPL tokens; wallets need explicit support. This guide stays at awareness level — if you are not deliberately opting into a confidential mint, you are unlikely to hold one accidentally.

Associated token accounts and program IDs

Associated token accounts (ATAs) are still derived from wallet + mint, but the token program ID is part of the seed recipe. Classic USDC and a Token-2022 USDC wrapper are different mints with different ATAs — sending to the wrong address loses funds or bounces. SDKs expose TOKEN_2022_PROGRAM_ID alongside the legacy constant; integrators must pass the correct one to getAssociatedTokenAddress and transfer instructions.

The account model is unchanged: each token balance is its own account paying rent (or holding a rent-exempt minimum). Token-2022 accounts are slightly larger when extensions allocate per-holder state.

Approvals, delegations, and security

Token-2022 supports the same approve/delegate pattern as classic SPL tokens, but extensions can change what a delegate is allowed to do or trigger hooks on delegated transfers. Before approving a DEX or staking contract to spend your tokens, understand whether the mint has transfer fees (you may approve more than the counterparty receives) or a permanent delegate (a third party may already have global move rights).

Our token approvals guide covers revoking stale delegations on legacy mints; the same revoke instruction applies to Token-2022 accounts when you use the matching program ID. Spam airdrops increasingly use Token-2022 because extensions let scammers attach misleading metadata — treat unknown mints like any other unsolicited token.

• Verify the mint address on the issuer's official site, not just the ticker symbol in a wallet list.
• Simulate before signing — fee-on-transfer mints change effective amounts.
• Check Solscan's program label — it will say Token-2022 when the mint uses the new program.
• Revoke unused approvals after trying a new protocol.

For developers: creating and integrating Token-2022 mints

Creation flows mirror classic tokens: allocate a mint account owned by Token-2022, initialize extensions in the same transaction (order matters — consult the program docs for required initialization sequence), then mint to holder ATAs. Anchor and @solana/spl-token ship helpers for common extension bundles.

When building a payment verifier, do not assume every incoming transfer uses the legacy program. Parse the transaction's token instructions and read the mint's owner field. Merchants accepting only SOL can ignore Token-2022 entirely; merchants accepting arbitrary SPL payments should whitelist mints and program IDs. See verify a Solana payment for SOL-first patterns, then extend with mint-specific rules.

Transfer hooks and confidential transfers are the highest integration cost — your program must invoke the Token-2022 transfer instruction in ways that satisfy the hook's account metas. Jupiter and other aggregators maintain allowlists of routable mints; new extension-heavy tokens may not be swappable day one.

Token-2022 vs classic SPL — quick comparison

Key takeaways

• Token-2022 is Solana's extensible SPL token program — same mint/account mental model, extra features in the mint header.
• Transfer fees and hooks are the extensions users feel most — always simulate sends and read receive amounts carefully.
• Program ID matters for ATAs, approvals, and revokes; classic and Token-2022 mints are parallel universes.
• Extensions are mostly fixed at mint creation — issuers choose compliance and composability trade-offs up front.
• Verify mint addresses and treat unknown Token-2022 airdrops with the same skepticism as any spam token.

Related reading

• SPL token accounts — mints, ATAs, and the classic program most tokens still use
• Token approvals — delegate spending limits and how to revoke them
• Solana account model — rent, owners, and why each token balance is its own account
• Transaction simulation — dry-run transfers before signing, essential for fee-on-transfer mints