- Token Extensions (Token-2022) let you build features like transfer fees, metadata, and compliance rules directly into your token — no custom program needed.
- Extensions are set at mint creation and cannot be added later, so plan your feature list before you start.
- You can mix and match most extensions, but some combinations are incompatible — the program will reject them at init time.
- The CLI path is the fastest way to test; TypeScript with
@solana/spl-tokengives you the most control for production. - The Token-2022 program has passed five independent security audits, making it safe for real-world use.1
- Wallets and dApps must be updated to handle Token-2022 tokens — check compatibility before launch.
Solana Token Extensions — also called Token-2022 — are an upgraded token standard that lets you bolt on powerful features like automatic transfer fees, on-chain metadata, privacy controls, and compliance rules without writing a single line of custom smart contract code. If you are a miner thinking about getting into blockchain development, this is one of the best places to start: you get real on-chain results fast, and the mental model maps cleanly to things you already understand about how blockchains enforce rules.
What Are Solana Token Extensions?
Think of the original Solana token program like a basic vending machine. It takes coins, dispenses tokens, and tracks balances. It works fine for simple use cases, but it has no way to charge a fee on every sale, lock certain items for specific buyers, or print a product label on the item itself. Token Extensions turn that basic machine into a programmable one.
Token Extensions are optional features baked directly into the Token-2022 program — a newer, more powerful version of Solana’s standard SPL token system. Technically, Token-2022 is a separate on-chain program deployed at the address TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb. The original token program sits at a different address. Both run side by side on Solana mainnet right now.2
Each extension is a standardized on-chain data layout appended to the mint account or token account. When you initialize a mint, you choose which extensions you want. The program allocates extra space to hold that extension data, initializes the rules, and then enforces them automatically on every transaction from that point on. You do not need to write any enforcement logic yourself — it is already built into the program.
Extensions were designed in close collaboration with large financial institutions that wanted to issue regulated tokens — stablecoins, tokenized real-world assets (RWA), loyalty points, and similar instruments — on a high-throughput chain without giving up compliance features they legally require.3 As a miner jumping into development, the payoff for you is that these same tools are available to anyone. You can build a revenue-generating token with automatic fees, a game item that can never leave a user’s wallet, or a private asset with hidden balances — all using a few CLI flags or a short TypeScript script.
How Token-2022 Differs from the Original SPL Token Program
The original SPL token program has been the backbone of Solana tokens since 2020. It handles minting, transferring, burning, and freezing tokens reliably. Its account layout is fixed: 82 bytes for a mint account, 165 bytes for a token account. That fixed size is actually part of its strength — it is simple, fast, and very well understood by wallets and dApps across the ecosystem.
Token-2022 keeps all of that. Every instruction the old program supports — minting, burning, transfers, freezing — works exactly the same way in Token-2022, byte for byte. The difference is that Token-2022 reads past those first 82 or 165 bytes to find extension data in a special section called TLV (type-length-value) storage. That extra section is where your chosen extensions live. Because Token-2022 is a strict superset of the original program, any code that worked on SPL tokens still works on Token-2022 tokens — you just need to pass the correct program ID.4
There is one important catch: dApps and wallets must be explicitly updated to handle tokens with specific extensions. A basic SPL transfer will still go through, but a wallet that is not extension-aware will not know to collect or display a transfer fee, for example. Adoption has been growing fast — major wallets and aggregators like Jupiter now handle Token-2022 natively — but always check compatibility before a production launch.
If you are coming from the Chia world, this will feel familiar. Chia’s coin-set model also lets you attach conditions and rules to coins at creation time. The key difference is the execution model. To understand why Solana uses an account-based structure instead, this breakdown of UTXO vs. account model blockchains explains how each approach handles programmability differently.
| Feature | Original SPL Token | Token-2022 (Token Extensions) |
|---|---|---|
| Transfer Fees | Not supported | ✅ Built-in, configurable |
| On-chain Metadata | External program (e.g. Metaplex) | ✅ Native via Metadata extension |
| Privacy / Confidential Transfers | Not supported | ✅ Zero-knowledge proofs |
| KYC / Compliance Gating | Manual, off-chain | ✅ Transfer hooks |
| Non-Transferable Tokens | Not supported | ✅ Built-in flag |
| Interest-Bearing Tokens | Not supported | ✅ Configurable interest rate |
| Program Audits | Multiple (since 2020) | 5 audits completed (Halborn, Zellic, NCC, Trail of Bits, OtterSec)1 |
| Wallet / dApp Compatibility | Universal | Growing — must verify per dApp |
| Backward Compatible? | N/A | Yes — same instruction layout |
The Most Important Token Extensions Explained
There are over a dozen extensions available in Token-2022. Below are the ones most useful to developers who are building their first compliant token or exploring what is possible.5
Transfer Fees
The Transfer Fee extension lets you automatically withhold a percentage of every token transfer and route it to a designated treasury wallet. You set it as basis points — for example, 100 basis points equals a 1% fee. You can also set a maximum fee cap so large transfers do not get charged an unbounded amount. The fee is withheld inside the recipient’s token account and must be “harvested” by an authorized wallet before it moves to the treasury. This two-step design means the fee is always accounted for on-chain, which is important for regulated use cases.
This extension is a great match for projects that need a sustainable revenue stream — gaming tokens, community currencies, or protocol-fee models. The CLI flag is --transfer-fee <BASIS_POINTS> <MAX_FEE>.
Token Metadata
Before Token-2022, adding a name, symbol, and logo to a Solana token required deploying a separate Metaplex metadata account. The Metadata extension changes that. You can store the token name, symbol, and a URI pointing to a JSON file (hosted on IPFS or Arweave) directly inside the mint account itself. This means a single account holds both the token rules and the branding, which simplifies token lookup for wallets and indexers. The --enable-metadata flag activates this in the CLI, and you can update metadata later if you retain the update authority.
Non-Transferable Tokens
Non-Transferable tokens are one of the most underutilized extensions and one of the most powerful for loyalty and credentialing use cases. When you set this extension on a mint, the tokens can only be minted to a wallet and burned from it — they can never be sent peer-to-peer. This is ideal for soulbound credentials, completion badges, certifications, or any token whose value comes from being tied to a specific wallet address. Note that this extension is incompatible with Transfer Fees, since a token that cannot move can never generate a fee.6
Confidential Transfers
This is the most technically advanced extension. Confidential Transfers use zero-knowledge proofs to hide the amount being sent in a transaction. The balances in token accounts are encrypted, and only the account owner (and any designated auditor) can see the real numbers. Transfers still settle on-chain and can be verified for correctness, but outside observers only see encrypted values. This extension is designed for institutions and individuals who need financial privacy while staying on a public blockchain. It requires some additional proof generation on the client side.
Transfer Hooks
Transfer Hooks are the most flexible extension, and the most complex to set up. When you enable a Transfer Hook on a mint, every transfer triggers a call to a separate on-chain program that you write and deploy. That program can run any custom logic — checking a KYC allowlist, verifying that the recipient holds a specific NFT, consulting an oracle for a price check, or logging compliance events. Think of it as a middleware layer that runs inside every transfer. The hook program receives all the same account info as the transfer instruction, so it has full context to make its decision. If the hook rejects the call, the transfer fails.
Interest-Bearing Tokens
The Interest-Bearing extension stores an interest rate on the mint and uses it to compute a continuously accruing UI balance. The actual token balance in the account does not change on-chain — the math happens in the display layer. This is useful for tokenized bonds, yield-bearing stablecoins, or any instrument where you want the displayed balance to grow over time without running periodic rebase transactions. The rate is set in basis points per second and can be updated by the rate authority.
Permanent Delegate
The Permanent Delegate extension grants one specific wallet address unlimited authority over all token accounts for that mint. That delegate can transfer or burn tokens from any holder’s account without needing a signature from the holder. This sounds alarming at first, but it has legitimate use cases: recovering tokens from compromised wallets, enforcing regulatory freezes, or automating custody operations. It is a powerful tool that should be used with full disclosure to token holders.
Solana Token Extensions Tutorial: Step-by-Step CLI Guide
This path uses the Solana CLI and the spl-token command-line tool. It is the fastest way to create and test a Token-2022 mint on devnet. You will not write any code — just commands in your terminal.
Step 1 — Set Up Your Environment
Install the Solana CLI by running the official install script for your operating system (Linux/macOS shown below). After installation, set your network to devnet and generate a wallet keypair.
# Install Solana CLI
sh -c "$(curl -sSfL //release.solana.com/stable/install)"
# Set network to devnet
solana config set --url //api.devnet.solana.com
# Generate a new keypair (save the output path)
solana-keygen new --outfile ~/.config/solana/id.json
# Fund your wallet with devnet SOL
solana airdrop 2
You will need at least 0.5 SOL to cover account creation rent on devnet. Run solana balance to confirm your airdrop landed. If the airdrop fails, try the Solana faucet at faucet.solana.com.7
Step 2 — Create a Token-2022 Mint with Transfer Fees
The key difference from a standard SPL token command is the --program-id flag. You must point the CLI at the Token-2022 program address. Below we create a token with a 1% transfer fee (100 basis points) and a maximum fee of 1000 tokens.
spl-token create-token \
--program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
--transfer-fee 100 1000 \
--decimals 6
The CLI will print the new mint address. Save it — you will need it in the next steps. The --decimals 6 flag sets six decimal places, matching USDC and most stablecoins. You can change this to any value between 0 and 9.
Step 3 — Add Metadata to Your Token
You can enable metadata at mint creation time by including the --enable-metadata flag alongside your other flags. To set the metadata fields on an existing mint, use the initialize-metadata subcommand.
# Create a mint with metadata enabled
spl-token create-token \
--program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
--enable-metadata \
--decimals 6
# Initialize the metadata (replace MINT_ADDRESS with your mint)
spl-token initialize-metadata MINT_ADDRESS \
"My Token" \
"MTK" \
"//your-metadata-uri.json"
The URI should point to a JSON file with fields like name, symbol, description, and image. Host it on IPFS via Pinata or NFT.Storage, or on Arweave for permanent storage.
Step 4 — Create Token Accounts and Mint Supply
# Create an associated token account for your wallet
spl-token create-account MINT_ADDRESS \
--program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb
# Mint 1,000,000 tokens to your account
spl-token mint MINT_ADDRESS 1000000 \
--program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb
# Check balance
spl-token balance MINT_ADDRESS
Once your supply is minted, try sending tokens to a second devnet wallet. You will see the 1% fee withheld in the recipient account. You can harvest those fees to your treasury using spl-token withdraw-withheld-tokens.
TypeScript: Creating a Token-2022 Mint Programmatically
For production use, or when you need to combine extensions precisely, the @solana/spl-token library gives you full control. The example below creates a mint with the Metadata Pointer extension using TypeScript. This is the same logic the CLI wraps, just exposed directly so you can integrate it into a larger application.8
import {
Connection,
Keypair,
SystemProgram,
Transaction,
sendAndConfirmTransaction,
clusterApiUrl,
} from "@solana/web3.js";
import {
TOKEN_2022_PROGRAM_ID,
ExtensionType,
getMintLen,
createInitializeMintInstruction,
createInitializeMetadataPointerInstruction,
} from "@solana/spl-token";
async function createTokenWithMetadata() {
const connection = new Connection(clusterApiUrl("devnet"), "confirmed");
// Load your keypair (for production, load from a secure key store)
const payer = Keypair.generate();
// Airdrop SOL to cover fees on devnet
const airdropSig = await connection.requestAirdrop(
payer.publicKey,
2_000_000_000 // 2 SOL in lamports
);
await connection.confirmTransaction(airdropSig);
const mintKeypair = Keypair.generate();
const decimals = 6;
// Calculate the space needed for the mint + MetadataPointer extension
const extensions = [ExtensionType.MetadataPointer];
const mintLen = getMintLen(extensions);
const lamports = await connection.getMinimumBalanceForRentExemption(mintLen);
// Build the transaction
const transaction = new Transaction().add(
// Create the account with the right size and rent
SystemProgram.createAccount({
fromPubkey: payer.publicKey,
newAccountPubkey: mintKeypair.publicKey,
space: mintLen,
lamports,
programId: TOKEN_2022_PROGRAM_ID,
}),
// Initialize the MetadataPointer extension BEFORE initializing the mint
createInitializeMetadataPointerInstruction(
mintKeypair.publicKey,
payer.publicKey, // authority that can update the pointer
mintKeypair.publicKey, // pointer to the mint's own account
TOKEN_2022_PROGRAM_ID
),
// Initialize the mint itself
createInitializeMintInstruction(
mintKeypair.publicKey,
decimals,
payer.publicKey, // mint authority
payer.publicKey, // freeze authority
TOKEN_2022_PROGRAM_ID
)
);
const sig = await sendAndConfirmTransaction(
connection,
transaction,
[payer, mintKeypair]
); console.log(“Mint created:”, mintKeypair.publicKey.toBase58()); console.log(“Transaction:”, sig); } createTokenWithMetadata();
Notice that the MetadataPointer initialization happens before the mint initialization in the transaction. This is a hard requirement of Token-2022: extensions must be initialized before the mint itself. Reversing that order will cause the transaction to fail.
The Solana Foundation has described Token Extensions as enabling “the next generation of features for digital assets and stablecoins on the Solana blockchain” — a recognition that regulated token issuance needed native program-level support rather than bolted-on external programs.3
Extension Compatibility: What Can and Cannot Be Combined
| Extension A | Extension B | Compatible? | Why |
|---|---|---|---|
| Transfer Fees | Interest-Bearing | ✅ Yes | Fees charged on transfers; interest accrues on balance display |
| Transfer Fees | Metadata Pointer | ✅ Yes | Fee logic and metadata live in separate TLV fields |
| Non-Transferable | Transfer Fee Config | ❌ No | A token that cannot move can never generate a transfer fee |
| Transfer Hooks | Transfer Fees | ✅ Yes | Hook runs alongside fee logic; both enforced on each transfer |
| Confidential Transfers | Transfer Fees | ⚠️ Limited | Fee amounts must be verifiable; confidential mode adds complexity |
| Permanent Delegate | Metadata | ✅ Yes | Separate functionality; no conflict |
Planning Your Token Before You Build
Here is the part most tutorials skip: once a mint is initialized with a set of extensions, you cannot add new extensions afterward. This is a design decision, not a limitation — it ensures that token holders always know exactly what rules apply to their tokens. Changing the rules mid-flight would break trust. So the planning phase matters more with Token-2022 than with traditional SPL tokens.
Ask yourself these questions before you run a single command. First, does your token need to generate revenue? If yes, include Transfer Fees. Second, will holders need to verify ownership of this token on a website or wallet? Include Metadata. Third, is this token tied to a specific person or credential? Consider Non-Transferable. Fourth, do transfers need to check an external condition — like a KYC list or NFT ownership? You need Transfer Hooks and a separate hook program. Fifth, do you need balance privacy for institutional holders? Look at Confidential Transfers.
This is the same kind of systems thinking that makes a good miner. Before you build a rig, you figure out your heat dissipation, power draw, and space requirements. Before you deploy a token, you figure out your extension requirements. The investment in planning pays off in not having to redeploy a mint from scratch.
It is also worth noting how Solana’s approach here fits into the broader trend of modular blockchain design — where different layers handle different concerns. If you are curious how that architectural philosophy plays out at the infrastructure level, the Celestia modular blockchain deep-dive on Chiatribe is a great companion read.
The real power of Solana Token Extensions is not any single feature — it is the ability to mix and match compliance rules, revenue logic, and metadata into a single mint account that is enforced automatically at the protocol level.
A real-world example: Paxos, the regulated financial institution behind USDP, launched its stablecoin on Solana using Token Extensions to satisfy compliance requirements around transfer controls and auditability — without building and maintaining a custom token program.3 That is the practical case for Token-2022 in one sentence: enterprise-grade rules without enterprise-grade custom development.
Conclusion
The Solana token extensions tutorial path is genuinely one of the most accessible entry points into blockchain development. You are not starting from scratch with a new language or a blank smart contract. You are picking features from a well-audited menu, combining them on a mint, and watching the network enforce your rules automatically. For miners moving into development, that is a huge head start. Start on devnet, pick two or three extensions that match a real use case you care about, and follow the CLI steps above. Once that clicks, the TypeScript path opens up and you can start building more complex applications around your token. The tools are here, the documentation is solid, and the ecosystem is growing fast enough that anything you build now has a real audience to reach.
solana token extensions tutorial FAQs
What is a Solana token extensions tutorial teaching me to build?
A Solana token extensions tutorial teaches you to create a Token-2022 mint — a Solana token that has built-in features like transfer fees, metadata, or compliance controls enforced directly by the network. It is the fastest way to deploy a programmable token without writing a custom on-chain program.
Do I need to know Rust to follow a solana token extensions tutorial?
No — the CLI path requires only terminal commands, and the TypeScript path uses JavaScript that most developers can read quickly. Rust is only needed if you want to write a custom Transfer Hook program, which is an advanced feature you can add later.
Can I add extensions to an existing Solana token?
No. Extensions must be configured at mint creation and cannot be added to an existing mint after it has been initialized. Plan your full feature list before you deploy to mainnet.
What happens if a wallet does not support Token-2022?
Basic transfers will still work because Token-2022 is instruction-compatible with the original SPL token program. However, extension-specific behaviors — like collecting transfer fees or displaying metadata — will not function correctly in wallets or dApps that have not been updated to handle Token-2022 accounts.
Is the Token-2022 program safe to use on Solana mainnet?
Yes. The Token-2022 program has completed five independent security audits from firms including Halborn, Zellic, NCC, Trail of Bits, and OtterSec, and it is already being used by regulated institutions including Paxos for their USDP stablecoin on Solana.1
solana token extensions tutorial Citations
- Token-2022 Program – Solana Program Library (Security Audits)
- Token Extensions – Solana Developer Docs
- Token Extensions – Solana.com Solutions
- Token-2022 Technical Reference – Solana Program
- Getting Started with Token Extensions – Solana Developers
- The Solana Token-2022 Specification – RareSkills
- Solana Devnet Faucet
- SPL Token Extensions Overview – QuickNode Guides
