If you come from Web2, you probably think of a token as a number in a database that moves around when people transact. On Solana, the original SPL Token program is exactly that. Token-2022 is the upgrade — and it lets you bolt behaviors directly onto the mint itself, the way you would add middleware to a payment pipeline, except the middleware lives inside the asset and cannot be bypassed.
This week I shipped three different mints on Solana devnet, each
demonstrating a different Token-2022 extension. Here's what I built, the exact commands I ran, and when you'd actually reach for each one.
Mint 1: Transfer Fee (Days 50–51)
Mint address: ACvRnk4m9fDji76fq74n7Nzwo6tUcPyajmgi3jX9BY1Q
View on Solana Explorer
Extension: TransferFeeConfig
spl-token create-token \
--program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
--decimals 6 \
--transfer-fee-basis-points 100 \
--transfer-fee-maximum-fee 1000000
This creates a mint where every transfer automatically withholds 1%
(100 basis points) into the recipient's account. The recipient can't spend the withheld amount — only the withdraw authority (whoever created the mint) can sweep it out.
When you'd use this: Protocol treasury fees, creator royalties on
a community token, or a skim on every transaction in a marketplace.
The fee logic is enforced by the Token-2022 program itself. No wallet, no dApp, no smart contract can route around it.
After creating the mint, I transferred 1,000 tokens to a second wallet:
spl-token transfer \
--expected-fee 10 \
$MINT 1000 $RECIPIENT \
--allow-unfunded-recipient
The --expected-fee 10 flag is a safety check — the transfer aborts if the calculated fee doesn't match. Out of 1,000 tokens sent, the recipient received 990. Ten tokens sat withheld in their account until I swept them:
spl-token withdraw-withheld-tokens $MY_TOKEN_ACCOUNT $RECIPIENT_TOKEN_ACCOUNT
My final balance: 1,000,010 tokens. That extra 10 is the fee I collected.
Mint 2: Transfer Fee + Interest (Day 52)
Mint address: A2qxipYpyY4gs1BAwv45U88Uj9RuuseEwCiB3s76ZB2J
View on Solana Explorer
Extensions: TransferFeeConfig + InterestBearingConfig
spl-token create-token \
--program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
--decimals 6 \
--transfer-fee-basis-points 100 \
--transfer-fee-maximum-fee 1000000 \
--interest-rate 5000
One command. Two extensions. Both baked into the same mint account.
What the interest extension actually does — and doesn't do:
This is the part I wish someone had told me upfront. The
InterestBearingConfig extension does not mint new tokens over
time. Your raw on-chain balance never changes. What changes is the displayed (UI) amount — a formula applied on the fly using the stored rate and the network's clock:
UI Amount = raw_balance × e^(rate × elapsed_years)
It's a view, not a balance update. No transaction runs. No new tokens appear. The number you see in a wallet grows because the display formula grows — not because your account data changed.
To make the effect visible quickly I used 50% APR (5,000 basis
points). Two snapshots 30 seconds apart:
Snapshot 1: 1,000,000.069191 tokens
Snapshot 2: 1,000,000.544703 tokens
Growth: +0.475512 tokens in 30s
No transaction ran between those two reads.
When you'd use this: Yield-bearing stablecoins, savings-style
tokens, or any token where you want the displayed value to grow as a function of time without actually minting supply on a schedule.
Mint 3: Non-Transferable / Soulbound (Day 54)
Mint address: 39eGRkFWbb52icCEdoaqSRtjH257KGHhhssZ2J3b2RdA
View on Solana Explorer
Extension: NonTransferable
spl-token create-token \
--program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
--enable-non-transferable
This mint produces tokens that cannot be sent anywhere. Once a token lands in a wallet, it stays there. The holder is the holder forever.
I minted one token to myself, created a recipient wallet, then tried to transfer:
spl-token transfer $MINT 1 $RECIPIENT --allow-unfunded-recipient
The response:
Error 0x25: NonTransferable — token program rejected transfer
Transaction simulation failed: Error processing instruction
That error didn't come from my code. It didn't come from a smart
contract I wrote. It came from the Token-2022 program refusing the instruction. My balance was unchanged. The token was still with me.
When you'd use this: Course completion badges, KYC verification tokens, DAO membership credentials, employee IDs. Anything where the value comes from who holds it, not from being tradeable.
In Web2, you'd enforce this at the application layer — a database
constraint, an API check. Someone who talks to the database directly can bypass that. On Solana the rule is inside the program that owns the asset. There is no around.
What the Audit Taught Me
On Day 53 I ran the Solana equivalent of DESCRIBE against all three mints — reading every extension the protocol sees on each account:
spl-token display $MINT_ADDRESS
The output confirmed everything I had configured was actually there.
But the more interesting thing was the account sizes:
| Mint | Extensions | Size |
|---|---|---|
| Day 50 | TransferFeeConfig | 278 bytes |
| Day 52 | TransferFeeConfig + InterestBearingConfig | 334 bytes |
56 bytes more for the second extension. Those bytes cost SOL in
rent-exempt deposits. Extensions are not free. You choose them
deliberately at mint creation time — and you can't add them later.
That constraint forces upfront design in a way I actually appreciate.
What Surprised Me
The thing I expected least: extensions are completely independent.
The transfer fee operates on the raw token amount. The interest
display formula also operates on the raw amount. They don't interfere with each other at all. I kept expecting some interaction, some edge case where they'd conflict. There isn't one. Two different TLV entries in the same byte buffer, each doing its own thing, neither knowing the other exists.
The thing I'd reach for in a real product: NonTransferable +
metadata on a single mint. A credential system where the badge is
self-describing (name, issuer, URI) and permanently bound to the
wallet that earned it. No backend. No revocation list. Just a token with rules baked in.
Resources
- Token-2022 extensions overview
- Transfer Fee extension docs
- Interest-Bearing extension docs
- Non-Transferable extension docs
This post is part of *#100DaysOfSolana*. Building on devnet every day — follow along or jump in any time.
Top comments (0)