If you know SPL tokens but not Token Extensions, here is the short version: Token-2022 is the upgraded Solana token program. At mint creation, you can opt into extensions: fees, interest, transfer rules, and other behaviors that live directly on the mint account. Think of it like middleware baked into the asset. Every wallet and program that touches the token sees the same rules, not a wrapper I wrote on the side.
I shipped three mints on devnet over this arc. Same CLI, three different behaviors.
Mint 1: Transfer Fee
Days: 50 and 51
Mint: 8gSexQr1JF4NeCKRR72nckSUdexmN5ZCuBTVuTfsJdPp
Explorer: View on Solana Explorer
Extension: Transfer fee, configured at 100 basis points, with a max fee of 1,000,000 tokens.
This was the first mint where the token itself started enforcing behavior. I configured a 1% transfer fee and then sent 1000 tokens to a fresh recipient wallet. The recipient received 990 spendable tokens, while 10 tokens sat in the account's withheld fee field until I withdrew them with the fee authority.
The create command:
spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
create-token \
--transfer-fee-basis-points 100 \
--transfer-fee-maximum-fee 1000000 \
--decimals 6
Then I created my token account and minted supply:
spl-token create-account 8gSexQr1JF4NeCKRR72nckSUdexmN5ZCuBTVuTfsJdPp
spl-token mint 8gSexQr1JF4NeCKRR72nckSUdexmN5ZCuBTVuTfsJdPp 1000
The fee lifecycle looked like this:
spl-token transfer \
--expected-fee 10 \
$MINT 1000 $RECIPIENT \
--allow-unfunded-recipient
spl-token display $RECIPIENT_TA
spl-token withdraw-withheld-tokens $MY_TA $RECIPIENT_TA
Where I would use it: a creator token with royalties on secondary movement, a protocol treasury skim, or a community currency where every transfer contributes a small amount back to the project. The important part is that the fee is not enforced by a web server. The Token-2022 program enforces it during transfer.
Mint 2: Transfer Fee Plus Interest
Day: 52
Mint: 6KHkyuc1v8BqZySkEp6wGdAiG26TJnH6h5JGSU91FD7s
Explorer: View on Solana Explorer
Extensions: Transfer fee and interest-bearing.
This mint stacked two behaviors onto the same asset: the same 1% transfer fee, plus an interest-bearing configuration at 5000 basis points. In CLI terms, that is a 50% interest rate.
The create command:
spl-token create-token \
--program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
--decimals 6 \
--transfer-fee-basis-points 100 \
--transfer-fee-maximum-fee 1000000 \
--interest-rate 5000
After creation, spl-token display showed both extensions:
Extensions
Interest-bearing:
Current rate: 5000bps
Average rate: 5000bps
Transfer fees:
Current fee: 100bps
One subtle thing matters here: the interest-bearing extension changes the displayed UI amount over time. It does not mint new supply into existence. After minting 1,000,000 tokens, I watched the account's displayed balance creep upward over about 30 seconds:
1000004.991023
1000005.482204
That distinction is easy to miss. It feels like yield, but it is a Token-2022 display behavior based on the configured rate, not a custom staking program minting rewards.
Where I would use it: savings-style balances, loyalty points that visibly grow, or any token where a wallet-facing balance should accrue over time without a custom program.
Mint 3: Non-Transferable
Day: 54
Mint: DRVQaZxsixMWiUrJxUmwXq6eY6vj1ZjEUz5epgoc25fk
Explorer: View on Solana Explorer
Extension: Non-transferable.
This one flipped the mental model. Instead of making transfers more complex, it disabled transfers entirely.
The create command:
spl-token create-token --program-2022 --enable-non-transferable
spl-token create-account $MINT
spl-token mint $MINT 1
Then I created a recipient account and tried to transfer the token:
spl-token create-account $MINT --owner $RECIPIENT --fee-payer ~/.config/solana/id.json
spl-token transfer $MINT 1 $RECIPIENT --allow-unfunded-recipient
The program rejected it:
Program log: Instruction: TransferChecked
Program log: Transfer is disabled for this mint
Program TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb failed: custom program error: 0x25
And spl-token display confirmed the mint-level rule:
Extensions
Non-transferable
Where I would use it: certificates, proof-of-attendance badges, reputation credentials, or any token that should stay attached to the original holder instead of becoming a tradable asset.
The Audit Habit
Before writing this, I ran spl-token display on each mint and checked the Extensions block. That felt like doing DESCRIBE table after a database migration. I was not trusting the commands I remembered typing. I was reading the public account state that wallets, explorers, and other programs read too.
One practical note: these mints live under the Token-2022 program. If spl-token display <MINT> says an account does not exist, try:
spl-token display <MINT> --program-2022
I hit that exact confusion while testing.
What Surprised Me
The surprising part is how much product behavior can live on the mint itself. Transfer fees felt like something I would normally write in backend code. Interest felt like something I would expect from a staking program. Non-transferability felt like an app-level rule. In Token-2022, all three are mint configuration.
In a real product, I would reach for transfer fees when the asset needs a treasury or royalty mechanism, interest-bearing tokens when the displayed balance should grow over time, and non-transferable tokens when the point is reputation or identity rather than liquidity.
That is the arc I wanted to understand this week: not just how to create a token, but how much behavior can be attached to the token before writing a custom program.
All mints and transactions above are on Solana devnet.
Top comments (0)