Deep Dive into Solana Token-22: Architecture, Features, and Integration

Deep Dive into Solana Token-22: Architecture, Features, and Integration
Introduction
Solana’s Token-22 standard (also known as Token-2022 in the Solana Program Library) is a next-generation token program designed to extend the original SPL token standard with richer functionality and flexibility​

quicknode.com
. It was developed to introduce new protocol-level token features – like native support for transfer fees, on-chain hooks, confidential transfers, extended metadata, and more – without disrupting existing SPL tokens​spl.solana.com
​spl.solana.com
. In this detailed technical deep-dive, we’ll explore the purpose and architecture of Token-22, its key extensions, and how it builds on (and remains compatible with) the original SPL Token standard (for comparison, think of SPL Token as “Token-20” akin to ERC-20). We will examine how Token-22 interacts with Solana’s runtime (including its privacy and compliance layers), provide code snippets for using new features like Transfer Hooks and ZK-powered confidential transfers, and discuss considerations for integrating Token-22 with existing Solana dApps and tooling. 

Overview of the Token-22 Standard
Token-22 is essentially a superset of the original SPL Token program​

spl.solana.com
. It introduces an extension model that adds new optional features to tokens while preserving the same base interface and account structure used by today’s SPL tokens. This design allows developers to opt-in to advanced capabilities on a per-mint or per-account basis, all under a new token program ID separate from the original. In practice, Token-22 retains all the original token instructions and data layouts, then extends them with new instructions and fields for the added functionality​spl.solana.com
​spl.solana.com
. The token program ID for Token-22 is TokenzQdBN...PxuEb, distinct from the legacy SPL Token program (TokenkegQ...5DA)​explica.co
. By using a new program deployed at a different address, Solana was able to add features without affecting the safety or behavior of existing tokens​spl.solana.com
. 

Purpose and Motivation: The primary motivation behind Token-22 was to avoid the need for ad-hoc token program forks. Previously, projects that needed custom token logic (e.g. native fees or special transfer rules) would fork the SPL token program, creating incompatible token variants and ecosystem fragmentation​

spl.solana.com
. Because Solana transactions must include all relevant programs, dealing with multiple token program implementations became complex for wallets and dApps​spl.solana.com
. Token-22 addresses this by incorporating common extensions directly into a standard program that everyone can adopt. This way, wallet providers and on-chain programs only need to trust and integrate one well-audited token program (Token-22) to gain support for a broad range of advanced token behaviors​spl.solana.com
​spl.solana.com
. The end goal is to enrich the token functionality available on Solana while maintaining compatibility and composability across the ecosystem. 

High-Level Architecture: Token-22’s architecture builds on Solana’s account model by appending extension data to the end of token account and mint account state. Every Token-22 token account starts with the same 165-byte layout as a standard SPL token account (containing owner, balance, etc.), and every mint account starts with the same 82-byte base as an SPL mint​

spl.solana.com
. New extension-specific fields are stored after these base bytes. This means a Token-22 account can be distinguished from a regular SPL account by the presence of extra data beyond byte 165, but otherwise the core fields align exactly​spl.solana.com
. A conceptual illustration of this is shown below, where optional extension data “blocks” are stacked onto the base account data​ 
: 

Diagram: A Token-22 token account retains the standard 165-byte core (blue), followed by any enabled extension data (green) appended in a TLV-style structure.​

spl.solana.com
 

By structuring data this way, the Token-22 program can ensure that existing SPL-compatible tools (which read only the first 165 bytes) still recognize balances and ownership correctly, while Token-22-aware tools can parse beyond that to utilize extensions. Internally, the program uses a type-length-value (TLV) scheme to manage these extensions. Both mints and accounts can have extensions. Notably, associated token accounts remain unified – the same Associated Token Account program can create accounts for either standard or Token-22 mints, and the address derivation remains unchanged​

spl.solana.com
. This greatly simplifies adoption, since wallet address conventions for tokens do not need to change. 

Key Features and Extensions in Token-22
Token-22 introduces a suite of token extensions that developers can enable à la carte when creating a token mint or configuring an account​

spl.solana.com
​spl.solana.com
. These extensions cover advanced tokenomics, compliance controls, privacy features, and metadata improvements beyond what the original SPL Token program offers. The table below outlines some of the major extensions and their purposes: 

 
 Summary of key Token-22 extensions, their descriptions, and example use cases (from Solana/Phantom documentation).

Some of the most significant capabilities provided by Token-22 include:

Transfer Hooks (Programmable Transfer Logic): Allows the token creator to attach a custom on-chain program that executes on every token transfer​

spl.solana.com
. This extension enables enforcing business logic or compliance checks at the token protocol level (e.g. KYC gating, dynamic royalties, transfer restrictions). We’ll dive deeper into transfer hooks below. 
Confidential Transfers (Encrypted Balances): Adds support for privacy-preserving token transactions using zero-knowledge proofs to hide token amounts​

quicknode.com
. With this extension, token balances and transfer amounts can be encrypted on-chain so that only owners (and possibly auditors) can see actual values, while the network can still verify transactions’ validity. Details on this ZK-powered feature are covered later. 
Transfer Fees (Protocol-Level Fees or Taxes): Enables tokens that automatically charge a fee on transfers​

quicknode.com
. A portion of the transferred amount can be diverted (e.g. for burns, payouts to a specific account, or distributed to holders) natively by the token program. This can be used for things like implementing royalties or transaction taxes without requiring a separate contract. 
Interest-Bearing Tokens: Allows tokens to accrue interest over time​

quicknode.com
. The token program can periodically increase account balances by a configured rate. This is useful for representing yield-bearing assets or deposit certificates directly at the token layer. 
Permanent Delegate (Clawback Authority): Introduces an authority that has irrevocable rights over all accounts of the mint​

quicknode.com
. For example, a “permanent delegate” could be a compliance program or issuing entity that is always able to freeze, burn, or transfer tokens from any account. This can be used by regulated stablecoin issuers to claw back funds if required by law​phantom.com
​phantom.com
. 
Non-Transferable Tokens: Marks a mint such that once tokens are issued to an account, they cannot be transferred to another account​

quicknode.com
. These soulbound tokens can only be created or burned by the mint authority. This is useful for certificates, achievements, or any asset that shouldn’t be tradable. 
Default Account State (Frozen Accounts): Allows a mint to specify that newly created token accounts start in a default state (e.g. frozen)​

quicknode.com
. This could mean accounts are initially locked until some condition or manual step unlocks them, providing an opt-in compliance check on first use. 
Required Memo (Incoming Transfers): Requires that any incoming transfer to an account include a memo (a note)​

quicknode.com
. This can enforce that senders attach identifying information or references on each transfer, analogous to how a bank might require notes for certain transactions (potentially for compliance tracking). 
Metadata & Metadata Pointer: Integrates token metadata (name, symbol, URI, etc.) directly into the mint account, and/or a pointer to an external metadata account​

quicknode.com
. This extension aims to streamline how metadata (especially for NFTs or tokens with rich info) is associated with the token. With Token-22, one can store a token’s core metadata on-chain in the mint itself, eliminating the need for a separate metadata program account for basic fields. The metadata pointer extension can link the mint to an off-chain or on-chain metadata source for additional data. We’ll discuss metadata integration more below. 
Each extension is opt-in at token creation or account initialization time. Mint extensions (like fees, confidential, etc.) must typically be enabled when the mint is created, as they often change the mint/account size and cannot be trivially added later in most cases​

spl.solana.com
. Account extensions (like required memo or CPI guard) can be configured per account by the owner. Multiple extensions can be mixed and matched on the same token, with some sensible exceptions (for example, combining a transfer hook that expects free movement with a non-transferable token wouldn’t make sense)​medium.com
. The Token-22 CLI and SDK provide flags and parameters to enable these extensions easily, as we’ll see in examples. 

Next, we will explore a few of the flagship features – transfer hooks and confidential transfers – in depth, as these represent the new compliance and privacy layers of Token-22. We will also look at the improved metadata handling. Along the way, we’ll compare how these differ from (or extend) the original SPL token functionality.

Transfer Hooks: On-Chain Compliance and Custom Logic
One of the most powerful additions in Token-22 is the Transfer Hooks extension. A transfer hook lets the token’s creator specify an on-chain program (smart contract) that the token program will call during every transfer of that token​

spl.solana.com
​spl.solana.com
. This effectively allows you to inject custom logic into token transfers at the protocol level, something not possible with the standard SPL token (which has fixed transfer behavior). Transfer hooks provide a native way to enforce compliance rules, perform validations, or trigger additional actions whenever the token moves between accounts. 

How it Works: When a token mint is configured with a transfer hook program, the Token-22 program will perform a Cross-Program Invocation (CPI) to that hook program as part of processing each transfer instruction. Specifically, the token program calls the hook’s standardized Execute interface after it has applied the transfer’s changes to source and destination accounts in memory​

spl.solana.com
​spl.solana.com
. The hook program is invoked with the relevant accounts (source account, destination account, mint, source owner, etc.) and the transfer amount​spl.solana.com
. It can then run arbitrary verification or state updates. If the hook program returns an error (fails), the entire token transfer is rolled back (the token program will abort the transaction) – effectively the hook can veto or preventtransfers that do not meet its criteria. If the hook program returns success, the transfer proceeds and the transaction succeeds. 

Under the hood, Token-22 uses a Transfer Hook Interface specification that hook programs must implement​

spl.solana.com
​spl.solana.com
. This interface defines the Execute instruction (and some setup instructions) that the token program knows how to call. The token creator must deploy their custom hook program (implementing this interface) and then associate the mint with that program via an extension. In practice, the mint carries a record of the hook program’s ID in its extension data, and Token-22 uses a program-derived “validation account” to manage any extra required accounts for the hook​spl.solana.com
​spl.solana.com
. The validation account is an on-chain config that the hook program can initialize to tell the token program “for each transfer, also pass me accounts X, Y, Z” (for example, a KYC whitelist PDA, or a royalty recipient account). This mechanism means that even if the hook needs additional context (beyond the standard source/destination/mint), the token program will fetch those accounts on behalf of the hook, ensuring the hook always has what it needs​spl.solana.com
​spl.solana.com
. 

Compliance and Control Use Cases: Transfer hooks open the door to a variety of compliance and custom behaviors that were previously impossible to enforce directly in the token program. For instance: a stablecoin issuer can implement a hook that blacklists addresses (preventing transfers to/from sanctioned accounts) or requires that both sender and receiver are on an approved whitelist​

neodyme.io
. An NFT project could implement a hook to automatically deduct and distribute royalties on every secondary sale, by having the hook program redirect a fee or require a royalty payment alongside the transfer​neodyme.io
​spl.solana.com
. Other possibilities include enforcing transfer frequency limits, requiring certain NFTs to accompany a token transfer (for token-gated access control), or logging transfers to another program for analytics. Essentially, any custom rule or side-effect that can be coded in a Solana program can be attached to the token’s transfers. 

Security Considerations: With great power comes responsibility – a buggy or malicious transfer hook could disrupt token transfers. The Token-22 design has some safeguards. Only the token’s mint authority can set or change the transfer hook program for a mint (since it’s configured as an extension during mint initialization). The hook program itself should verify that it’s being called for the correct token mint (it receives the mint account as an argument) to avoid a scenario where some other token tries to reuse it in an unintended way​

neodyme.io
​neodyme.io
. Developers of hook programs are advised to check that the provided mint matches their expected token and to segregate any state by mint if supporting multiple tokens. Additionally, the token program sets a flag in each account while a transfer is in progress (a boolean transferring field in a TransferHook extension on accounts) so the hook can detect and reject any calls that didn’t originate from an actual token transfer context​neodyme.io
​neodyme.io
. This prevents an attacker from calling the hook program’s Execute instruction outside of a real transfer in an attempt to exploit the hook’s logic. 

From a performance standpoint, adding a hook does mean each transfer triggers an extra CPI. This is a minor overhead, but Solana’s runtime is designed for high parallelism, so as long as the hook logic is efficient (and local to the same shard of accounts in the transaction), the impact is manageable. It’s a trade-off between functionality and speed. In many cases, the flexibility gained – e.g., being able to do on-chain KYC checks – is well worth it for the use case.

Example – Enabling a Transfer Hook: To illustrate how a developer uses this, suppose we have deployed a hook program with ID 7N4Hg...YstVj that enforces some custom rule. When creating the token mint, we enable the transfer-hook extension and point it to our program:

bash
CopyEdit
$ spl-token --program-id TokenzQdBN...PxuEb \
    create-token --transfer-hook 7N4HggYEJAtCLJdnHGCtFqfxcB5rhQCsQTze3ftYstVj

This command uses the Solana CLI (with Token-22 program) to create a new token mint on the Token-22 program, associating the given hook program as the transfer hook​

spl.solana.com
. After this, any transfers of this token (when the Token-22 program processes them) will invoke our hook. On the hook program side, we would have implemented the Execute instruction to define what happens – for example, check an allowed list PDA for both source_token and destination_token accounts and return an error if either is disallowed. 

Developers can refer to the [SPL Transfer Hook Interface reference implementation]​

spl.solana.com
​spl.solana.com
for a template on writing hook programs. Using libraries like spl-transfer-hook-interface (which provides both on-chain and off-chain helpers) can simplify resolving the extra accounts that the hook might need​spl.solana.com
. For instance, an off-chain client (like a wallet) can use the library to automatically fetch the extra account metas required for a transfer, so that it can include them in the transaction. This kind of tooling will be key for widespread adoption – wallets and dApps will need to be aware when a Token-22 transfer requires additional accounts or instructions, and the interface libraries help integrate that seamlessly. 

In summary, transfer hooks in Token-22 provide a robust compliance layer. They extend Solana’s runtime by effectively chaining an extra programmable step into token transfers, all while staying compatible with the normal token API. This capability is a game-changer for projects that need to enforce rules on how their token circulates, directly at the protocol level rather than relying on off-chain agreements or wrapping tokens in escrow programs.

ZK-Powered Confidential Transfers: Enabling Token Privacy
Another marquee feature of Token-22 is the Confidential Transfers extension – a privacy layer for fungible tokens. This extension leverages cryptography (specifically zk-SNARKs and ElGamal encryption) to allow transfers of a token where the amounts are encrypted on-chain, yet the token program can still verify that transactions are valid (no double spending, balances conserved, etc.)​

neodyme.io
. In essence, it brings to Solana tokens a capability similar to what Zcash or other privacy coins provide: shielded transactions. 

What Confidential Transfers Provide: When enabled, this extension lets an account hold “confidential” token balances in addition to normal balances. A confidential balance is stored as a cryptographic commitment rather than a plaintext number, hiding the actual amount. Transfers between confidential-enabled accounts do not reveal the transferred amount to observers – only the involved parties (and possibly an auditor with special keys) can decrypt the amounts. The protocol uses zero-knowledge proofs to prove to the Token-22 program that a transfer of X tokens from A to B has happened without revealing X, ensuring that neither account’s balance went negative and that the total supply is consistent​

phantom.com
​phantom.com
. This provides privacy for transaction amounts and balances, which is valuable for business transactions, payroll, or any use case where on-chain transparency of holdings is undesirable. 

Architecture & Cryptography: At a high level, each Token-22 account with the confidential extension has associated encryption keys (ElGamal public keys) and holds two categories of balance: a regular (public) token balance and a confidential (encrypted) balance. The mint is configured with a certain “approve policy” for confidential transfers – either auto (anyone can opt in) or manual (the mint authority must approve each account for confidential capability)​

spl.solana.com
. With auto policy, any user can choose to configure their account for confidentiality, generating a secret encryption key and adding the extension data to their account (this requires the account owner’s action, since only they should know the secret key)​spl.solana.com
. With manual, an issuer can maintain an allow-list of who is allowed to use the confidential feature, perhaps for regulatory reasons. 

Once an account is configured, the user can deposit some of their public token balance into their confidential balance. Depositing will lock the corresponding public tokens and generate an encrypted commitment representing the same amount in the confidential balance​

spl.solana.com
​spl.solana.com
. After depositing, the account’s public balance reduces, and its confidential balance (hidden) increases by that amount. The user can then transfer tokens confidentially to another confidential-enabled account. A confidential transfer involves the sender creating a zero-knowledge proof that they have enough available encrypted balance and constructing a cipher of the transfer amount to the receiver’s public key. On Solana, these proofs are verified by the token program (with help of the on-chain ZK verification program) during the transfer instruction. Because these proofs and encrypted data can be large, the current implementation actually breaks a single transfer into multiple transactions under the hood​spl.solana.com
– for example, the CLI notes that a confidential transfer “takes a little bit longer” and involves multiple dependent transactions, on the order of a few seconds rather than a single fast transaction​spl.solana.com
. In the future, Solana plans to support larger transaction payloads so that the entire flow could happen in one atomic transaction​spl.solana.com
. 

On the receiving side, when an account receives a confidential transfer, those funds initially land in a “pending” state​

spl.solana.com
. The receiving account owner must then issue an instruction to “apply pending balance”​spl.solana.com
. This step provides a proof that they know the secret key corresponding to the new encrypted funds and finalizes the reception by moving the pending amount into their “available” confidential balance. This extra step prevents someone from sending garbage to a recipient – the recipient must acknowledge (apply) to actually add it to their spendable balance. Once applied, the recipient can use those funds for further confidential transfers or choose to withdraw them back to normal (transparent) SPL balance if needed​spl.solana.com
. Withdrawing will burn the encrypted commitment and credit the account’s normal balance by that amount (making it public again). 

Interaction with Solana Runtime: The confidential transfer feature is one of the most technically complex in Token-22 because it relies on cryptographic proof verification on-chain. Solana’s runtime (as of version 1.18) is being enhanced with a dedicated ZK token proof program that the Token-22 program can invoke to verify zero-knowledge proofs efficiently​

spl.solana.com
. This program (sometimes referred to as the ZK ElGamal Proof Program) provides on-chain verification for the specific proofs used by the confidential token protocol (range proofs, equality proofs, etc., ensuring that encrypted balances subtract and add correctly without overflow). The cluster needs to activate certain features (like zk-ops) to support this; as of early 2024, these features were present on testnet/devnet but not yet enabled on mainnet-beta until a required Solana runtime upgrade (“Agave v2.0”) is in place​spl.solana.com
​spl.solana.com
. Thus, confidential transfers were still in a guarded launch mode. This means developers can experiment on test networks, but production use awaits those upgrades (the roadmap predicted mainnet support in “Autumn 2024” pending those features​spl.solana.com
). 

From a usage perspective, however, the interface is exposed through the same CLI and libraries, making it as straightforward as calling the specialized instructions (e.g. deposit-confidential-tokens, transfer --confidential, etc.). The heavy lifting of proof generation is done on the client side (for example, the wallet or application will generate the ZK proof using the user’s secret and the provided encryption libraries when constructing the transaction).

Example – Using Confidential Transfers: Below is a sequence of CLI commands illustrating the lifecycle of confidential tokens (assuming the cluster supports it):

Create a Mint with Confidential Transfers Enabled: When creating the token, we specify the --enable-confidential-transfers flag and the approval mode. Here we use auto to allow anyone to use confidentiality.

bash
CopyEdit
$ spl-token --program-id TokenzQdBN...PxuEb \
    create-token --enable-confidential-transfers auto

This produces a new mint. (If we wanted the issuer to gate usage, we’d use manual instead of auto, meaning the mint authority must approve each account later​

spl.solana.com
.) Note: The confidential extension must be set at mint creation; it cannot be retrofitted later​spl.solana.com
. 
Configure an Account for Confidentiality: A user (token holder) who wants a private balance must configure their token account with an ElGamal encryption key. First, they create a token account as usual (e.g., an associated token account):

bash
CopyEdit
$ spl-token create-account <MINT_PUBKEY>

Then the owner enables confidential transfers on that account:

bash
CopyEdit
$ spl-token configure-confidential-transfer-account --address <ACCOUNT_PUBKEY>

This generates a new keypair (or uses an existing one the user provides) for encrypting balances and records the public key in the account’s extension data​

spl.solana.com
. Only the account owner can do this, since it’s crucial they keep the secret key; unlike normal ATA creation, you cannot pre-create a confidential account for someone else​spl.solana.com
. 
Deposit Tokens into Confidential Balance: The user can now move some of their visible tokens into the shielded balance:

bash
CopyEdit
$ spl-token deposit-confidential-tokens <MINT_PUBKEY> <AMOUNT> --address <ACCOUNT_PUBKEY>

After this, the specified amount is deducted from the account’s normal balance and added to its confidential balance (encrypted)​

spl.solana.com
​spl.solana.com
. From here on, those tokens can be transferred privately. 
Confidential Transfer: To send tokens confidentially to someone else, the sender must ensure the recipient also has a confidential-enabled account for this mint (the recipient should have done step 2). Then the sender issues:

bash
CopyEdit
$ spl-token transfer <MINT_PUBKEY> <AMOUNT> <RECIPIENT_ACCOUNT_PUBKEY> --confidential

Under the hood, this will create and send the necessary proof(s) and encrypted payloads. As noted by the CLI, this operation currently may involve multiple transactions behind the scenes and take a few seconds to complete​

spl.solana.com
. The recipient will now have a pending confidential balance. 
Apply Pending Balance (Receiver Side): The receiver sees that they have a pending incoming amount (their balance isn’t yet usable). They must apply it:

bash
CopyEdit
$ spl-token apply-pending-balance --address <RECIPIENT_ACCOUNT_PUBKEY>

This finalizes the transfer by proving they possess the decryption key for the new ciphertext, moving the funds from “pending” to “available” in their confidential balance​

spl.solana.com
​spl.solana.com
. Now the receiver can in turn spend these in another confidential transfer. 
Withdraw (if needed): If a user wants to convert their confidential holdings back to normal (transparent) SPL tokens in their account, they can:

bash
CopyEdit
$ spl-token withdraw-confidential-tokens <MINT_PUBKEY> <AMOUNT> --address <ACCOUNT_PUBKEY>

This burns the encrypted tokens and credits the specified amount back to the account’s regular balance​

spl.solana.com
. (All pending amounts should be applied before withdrawing to ensure they’re counted in available balance​spl.solana.com
.) 
Throughout these steps, the actual cryptographic operations (generating zk-proofs for transfer, encryption/decryption) happen off-chain in the CLI or SDK, and the Token-22 program verifies proofs and updates state accordingly on-chain. From an integrator’s perspective (wallets, exchanges, etc.), supporting confidential tokens means handling these extra instruction flows. Notably, a wallet must be able to generate zero-knowledge proofs for transfers – which is more involved than a normal signature – and manage the encryption keys for the user’s accounts. This is an active area of development; as of now, command-line tools and reference implementations exist, but user-friendly wallet integration is forthcoming​

spl.solana.com
​phantom.com
. 

Auditability and Compliance: A natural question is: if amounts are hidden, can an issuer still audit or comply with regulations? The design can accommodate an auditor role by sharing view keys. For example, the mint authority (or another designated key) could be given the ability to decrypt all transfers, if the use case requires (though the standard extension as implemented focuses on privacy without backdoor by default). In the Paxos USDP example (a regulated stablecoin that enabled confidential transfers), the issuer likely uses the permanent delegate and manual approval mode to ensure they have oversight while still providing privacy to end users​

phantom.com
​phantom.com
. Thus, Token-22’s confidential transfer feature can be seen as a privacy layer with optional compliance controls(through policy and delegate), bridging the gap between transparent public tokens and fully private transactions. 

Metadata Integration in Token-22
In the original SPL token standard, metadata (such as token name, symbol, URI for an icon or JSON data) is typically handled by a separate program – the Metaplex Token Metadata program – especially for NFTs and tokens requiring on-chain name/symbol. This means an extra account (and program) per token mint to store things like the token’s name, symbol, or any custom fields. With Token-22, Solana has introduced two extensions to streamline metadata:

Metadata Extension: This extension adds fields for name, symbol, URI, and optional additional data directly into the token mint account​

phantom.com
​spl.solana.com
. Essentially, the token’s basic identity information can live inside the mint, in a standardized format. 
Metadata Pointer Extension: This provides a slot to store a pointer (address) to an external metadata account or source​

quicknode.com
. This is useful if there are multiple metadata programs or an off-chain registry – the pointer acts as an authoritative link, preventing ambiguity when multiple metadata sources exist. 
Using these extensions, a token creator can potentially avoid having to create a Metaplex metadata account at all for simple cases, or if they do use one (for example, an NFT collection wanting all the rich features of Metaplex metadata), they can at least link it definitively via the pointer. An example of the benefit is described in the Wen New Standard (WNS) NFT standard, which leverages Token-22: by storing core info like each token’s name, symbol, and URI on the mint itself (Metadata extension), WNS eliminates the need for external accounts for those fields and thus removes extra fees or external program dependencies​

phantom.com
​phantom.com
. 

Initializing Metadata: If the metadata extension is enabled on a new mint, one would then call an instruction to set the actual metadata fields. The Solana CLI facilitates this. For instance:

bash
CopyEdit
$ spl-token --program-id TokenzQdBN...PxuEb create-token --enable-metadata

This command creates a new mint with the metadata (and metadata-pointer) extension automatically included​

spl.solana.com
. The CLI output indicates the mint address and then tells you how to initialize the metadata: 

bash
CopyEdit
To initialize metadata inside the mint, run:
spl-token initialize-metadata <MINT_ADDRESS> <TOKEN_NAME> <TOKEN_SYMBOL> <TOKEN_URI> --update-authority <PUBKEY>

For example:

bash
CopyEdit
$ spl-token initialize-metadata 5K8RVd...vpS MyTokenName TOKEN https://my.token/metadata.json --update-authority <YOUR_PUBKEY>

This will write the name "MyTokenName", symbol "TOKEN", and URI "https://my.token/metadata.json" into the mint’s metadata fields, with your key as the authority allowed to update these fields in the future​

spl.solana.com
​spl.solana.com
. After running this, the mint account itself holds the metadata (and the pointer extension likely points the mint to itself as the metadata account, as per the design where a mint can point to itself if using the internal metadata)​spl.solana.com
. 

For more complex scenarios (say you have additional struct fields not covered by name/symbol/uri), the additionalMetadata field can be used. The JS SDK example shows that you can pack custom key-value pairs into the metadata extension as well​

spl.solana.com
. Tools like Metaplex have begun supporting reading from Token-22 metadata, and it is expected that over time wallets will display token names and icons using either the legacy metadata account or the Token-22 metadata extension transparently. 

Compatibility: A Token-22 mint can still have a traditional Metaplex metadata PDA account if needed – the two are not mutually exclusive. In fact, the metadata-pointer could be used to point to that PDA, or if you prefer the canonical source to be the mint’s internal metadata, you just leave the pointer pointing to itself (which the tools do by default)​

spl.solana.com
. The idea is to avoid confusion from multiple metadata sources: the pointer extension can serve as the single source of truth about which metadata to use. For example, if in the future an upgraded metadata standard comes out, a Token-22 mint could add another pointer to that new metadata account without losing backward compatibility. 

From an ecosystem standpoint, because the metadata extension is new, it requires wallets/block explorers to query the token mint for these fields. Many existing tools only query the Metaplex metadata program. Part of rolling out Token-22 involves updating those tools. Fortunately, since the Solana RPC can index Token-22 accounts too​

spl.solana.com
, a wallet like Phantom has been able to implement support to fetch Token-22 metadata and display tokens accordingly​phantom.com
. As adoption grows, we expect dApps to handle both seamlessly. 

Compatibility with Existing dApps and Tooling
Adopting Token-22 in the Solana ecosystem introduces some compatibility considerations. By design, a Token-22 token behaves just like an SPL token for basic operations (transfer, mint, burn) if the dApp or wallet knows to target the Token-22 program. However, existing infrastructure must be updated to be aware of the new program ID and any new behaviors:

Program ID in Transactions: Perhaps the most immediate difference is that to manipulate Token-22 tokens, transactions must invoke the Token-22 program (TokenzQdB...) instead of the legacy token program. Many SDK functions (e.g. in @solana/spl-token or Anchor) default to the old token program ID. Developers need to pass the Token-22 program ID explicitly when constructing instructions for Token-22 mints​

quicknode.com
​quicknode.com
. For example, using the JS SDK, one must call getAssociatedTokenAddressSync(mint, owner, false, TOKEN_2022_PROGRAM_ID) to derive the correct associated account for a Token-22 mint​quicknode.com
​quicknode.com
(passing the new program ID). Forgetting to switch the program ID will result in errors or interacting with a nonexistent mint on the old program. This is a one-line change in many cases, but it requires that developers are mindful when integrating Token-22. 
Wallet and Explorer Support: Wallets need to update to scan for Token-22 accounts in addition to regular SPL accounts. Solana’s RPC nodes index both by default now, but the wallet’s UI logic must query both program IDs for token balances. By late 2023, many wallets (including Phantom) started adding this support, given Solana Foundation’s push that Token-22 would be “officially recommended” after the 1.17 release​

spl.solana.com
. Similarly, block explorers and portfolio trackers must recognize the new tokens. Initially, Token-22 tokens may not appear in some user interfaces until those tools catch up, leading to the “limited adoption” concern in the interim​explica.co
​explica.co
. 
Smart Contract Compatibility: On-chain programs (DeFi protocols, etc.) that interact with tokens may need to be upgraded to handle Token-22 tokens. The good news is that because Token-22 honors the same interface for the first 25 instructions, many existing CPI calls (like a program invoking a token transfer) can simply be pointed at the new program ID and will work identically​

spl.solana.com
. For example, a lending protocol can accept Token-22 collateral by allowing the Token-22 program in escrow instructions, as long as it doesn’t explicitly check for the exact program ID or assume no extensions. However, if a protocol is not aware of extensions, there could be edge cases – e.g., an AMM not expecting a transfer fee might find that 995 tokens arrived instead of 1000. Therefore, protocols need to consider the presence of extensions: a transfer fee extension means the protocol should accommodate less-than-expected received amounts; a non-transferable extension means the token might not behave as needed in free market trading; a confidential token probably isn’t suitable for an open AMM pool since the pool contract wouldn’t know the amounts. Thus, integration involves both technical updates (using the new program ID, reading extended data) and logical decisions (which extensions will the protocol support or reject). 
Partial Feature Adoption: Not all dApps need to immediately support all extensions. For instance, an exchange might support listing basic Token-22 fungible tokens that have no unusual extensions (or maybe just a transfer fee that they can handle), but they might choose not to list a confidential token until the ecosystem matures for that. Backwards compatibility is strong in the sense that any Token-22 token can always be treated like a normal token if you ignore its extensions – you can transfer it normally (subject to extension rules) and count balances. But whether it behaves normally is another question. For example, a wallet that doesn’t understand confidential transfers will show the public balance (which might be zero after deposit) and not the confidential balance, confusing the user. Therefore, full support means being aware of these distinctions. To mitigate this, the Solana tooling team has aimed for graceful fallback: e.g., if a wallet sees an account with confidential extension and it doesn’t support generating proofs, it could at least warn the user that the balance is confidential and show it as “encrypted” rather than zero.
Upgradeable Program and Audits: At the time of writing, the Token-22 program is still upgradeable (not permanently frozen) and undergoing audits for its newer features​

spl.solana.com
. This means developers should keep an eye on updates to ensure compatibility. The Solana team indicated that after sufficient time (and once all features like confidential transfers are fully live and audited), the program will be made final (immutable) like the original token program​spl.solana.com
. This is expected in 2025​spl.solana.com
. Until then, using Token-22 in critical applications should be done with the understanding that minor changes could occur (though the core interface is stable). 
Choosing SPL vs Token-22: For new projects, one might ask: should I use the old SPL token or Token-22? The answer depends on your needs. If you need any of the advanced features (fees, hooks, confidential, etc.), Token-22 is the obvious choice. If your token is very simple (fixed supply utility token or a basic NFT collection) and you prioritize broadest compatibility, you might lean towards the tried-and-true SPL token for now. Indeed, some have suggested that for a basic meme coin or similar, the added complexity of Token-22 offers little benefit​

explica.co
and could hinder adoption if some exchanges or tools don’t recognize the new token program yet. However, given the trajectory (Token-22 becoming the standard recommended token program by Solana Foundation), the ecosystem support is rapidly growing. Many projects – including major ones like Paxos with USDP – have already launched using Token-22 extensions, signaling confidence in adoption​phantom.com
​phantom.com
. 
Tooling and Best Practices
To ease integration, Solana provides updated tooling for Token-22:

Solana CLI & SPL-Token CLI: The solana CLI (v1.14.17 or later) and spl-token-cli (v2.2 or later) have built-in support for Token-22​

spl.solana.com
. As we saw, commands like create-token, transfer, etc., accept a --program-id to target Token-22 and flags to enable various extensions. The CLI also includes helpful guidance (like prompting to run initialize-metadata after creating a metadata-enabled mint). The fact that the CLI package is the same (just pointed at a different program) means scripts that use spl-token can be adapted for Token-22 easily. 
Client Libraries: The official Solana SPL libraries (@solana/spl-token JS library, Solana SDK for Rust, etc.) have been updated with Token-22 constants and instruction constructors. For example, the JS library exports TOKEN_2022_PROGRAM_ID and functions for creating extension initialization instructions​

quicknode.com
​quicknode.com
. There are high-level methods to directly create a mint with certain extensions in one go, calculate the increased account size (getMintLen considering extensions)​spl.solana.com
, and utilities for reading extension data. Additionally, specialized libraries exist for certain extensions (e.g., spl-token-metadata for packing metadata, spl-transfer-hook-interface for resolving hook accounts, and cryptographic crates for confidential transfers). Using these libraries is strongly recommended to avoid low-level mistakes. 
Testing and Simulation: When implementing a transfer hook or any complex token logic, it’s wise to test thoroughly on a local validator or testnet. The Token-22 program is available on all clusters (devnet, testnet) without confidential transfers enabled by default​

spl.solana.com
(you can use a test validator with feature flags to test confidential though). Writing Anchor tests or integration tests can catch issues like forgetting to include the validation account for a hook, or ensure that a DeFi protocol properly handles a transfer fee deduction. Offside Labs’ security blog highlights best practices for secure use of Token-22 in Anchor, emphasizing checking extension presence and not assuming a token account is exactly 165 bytes​blog.offside.io
​blog.offside.io
. Indeed, one must be careful when deserializing token accounts – using the new SPL Token 2022 parsers that know about extensions is key; older code might truncate or ignore the extra bytes. 
Best Practices: If you’re enabling certain extensions, follow guidelines:

For transfer hooks, always validate the context (mint and transferring flag) as discussed, and consider the upgradeability of your hook program (if your logic needs to change, the mint authority could update the mint’s hook to a new program, but that should be done very carefully to avoid disrupting ongoing transactions or breaking the interface).
For confidential tokens, ensure users understand the two balances and the need to apply pending transfers. Also, have a plan for recovery if a user loses their encryption key – currently, if the key is lost, the confidential balance is likely lost permanently (similar to losing a private key for an encrypted wallet).
For metadata, decide if you want the on-chain metadata to be the source of truth. If you use an external metadata program like Metaplex, use the pointer to avoid confusion. Also, keep metadata names concise; the on-chain space is limited.
For fees and interest, consider how these interact. The program allows combining them, but for example, if you have both interest and a transfer fee, make sure the economics still make sense (interest adds tokens over time, transfer fee removes some on transfer).
For immutable owner or default frozen states, remember to provide a method for users to “thaw” if needed (e.g., the mint authority might need to approve accounts to become active). The CPI guard, which prevents CPI calls within a CPI, is mostly a niche security tool – use it if you don’t want your token to be manipulable by other programs unless directly signed by users (it’s a guard against re-entrancy or unauthorized CPI).
The community is actively building tooling around Token-22. For example, Phantom’s developer documentation includes guidance on how to integrate with their wallet for tokens with extensions​

phantom.com
. We can expect more SDKs (like Python libraries, etc.) to add convenience for Token-22 as well. 

Conclusion
Solana’s Token-22 standard represents a significant evolution of the SPL token program, bringing protocol-level extensibility for tokens in a way that preserves composability and safety. For protocol architects and developers, Token-22 offers an expanded design space: you can now issue tokens that carry their own business logic (hooks), economic rules (fees/interest), privacy guarantees (confidential balances), and metadata – all enforced by the base token program that the ecosystem trusts​

explica.co
. This deep integration means less reliance on custom program workarounds (which often came with security risks and fragmentation). 

Integrating Token-22 into your project requires understanding these new features and the subtle shifts in how tokens behave. We compared how Token-22 extends the original “Token-20” standard: it keeps what worked (fast, simple transfers and mints as Solana accounts) and adds what was missing (more sophisticated controls and configurations)​

explica.co
. The transition is made easier by the backward compatibility of instruction formats and the support of Solana’s core tooling. As of early 2025, Token-22 has undergone multiple audits and is increasingly supported across wallets and DeFi platforms, though some features like confidential transfers are just on the cusp of full mainnet availability​spl.solana.com
​spl.solana.com
. 

For developers looking to adopt Token-22, now is the time to start experimenting. Use devnet to try out creating a token with the extensions that fit your use case, and test integration with your application. If you maintain a protocol, update it to recognize Token-22 accounts and the potential implications of extensions. In doing so, you’ll enable new possibilities: tokens that can satisfy compliance out-of-the-box, tokens that preserve user privacy, NFTs with built-in royalty enforcement, and beyond – all “first-class citizens” on Solana. Token-22’s design motto might well be “opt-in complexity, opt-out simplicity”: you only pay (in terms of development and runtime cost) for the features you choose to enable, while the rest of the ecosystem can interact with your token as they would any SPL token.

In summary, Solana Token-22 is a forward-looking standard that equips the Solana ecosystem with the flexibility needed for the next wave of on-chain innovation. By following the best practices and leveraging the SDKs, developers and protocol teams can confidently integrate Token-22 into their projects and unlock functionality that previously required custom solutions. With privacy features aligning with compliance needs, Token-22 strikes a balance that could attract more traditional finance use cases onto Solana, while also empowering crypto-native projects to push the envelope of what tokens can do. As always, keep an eye on the official Solana Program Library docs and community updates for the latest improvements to Token-22, and happy building with the new standard!

Sources: The information in this post is drawn from Solana’s official SPL Token-2022 documentation​

spl.solana.com
​spl.solana.com
, developer guides​quicknode.com
​quicknode.com
, and community resources including Phantom’s and others’ explanations of token extensions in practice​phantom.com
​phantom.com
. The code examples utilize the Solana CLI and SPL SDK as documented in the Solana Program Library guides​spl.solana.com
​spl.solana.com
. For further reference, see the Solana SPL Token-2022 docs and the cited materials throughout this article.