Token Extensions are behaviours embedded directly into a token, enforced at the program level at creation time. You can set transfer fees, make transfers confidential, or disable token transfers altogether — all baked in, no extra contracts needed.
A Bit of Context
I have been doing the 100 Days of Solana challenge, where every day a new challenge teaches you something new about the Solana blockchain from a developer's perspective.
I started knowing nothing. Today I can spin up accounts, explain how Solana accounts are encoded at the byte level, make transfers, and create my own tokens with custom extensions. Here's what the last few days looked like.
What I Built
Day 29 — Token-2022 From Scratch
This was the big one. Using nothing but the spl-token CLI, I:
- Initialised a token with the Token-2022 program
- Added a transfer fee (200bps, as you can see in the terminal output below)
- Attached on-chain metadata — name, symbol, and URI — so the token is human-readable
- Created an Associated Token Account (ATA), the address that holds a specific token instead of SOL
- Minted tokens into it
- Transferred tokens to another wallet
- Collected the transfer fees accumulated from those transactions Here's what the final mint looked like on the terminal:
Everything — fee config, metadata pointer, withdrawal authority — living directly on the mint account. No separate contract, no external registry.
Days 30 & 31 — Slower, but Necessary
Funny enough, the exercises on days 30 and 31 were less technically advanced than what I had already built on day 29. The day 32 challenge turned out to be essentially a more structured version of day 29.
That said, I don't regret it at all. Days 30 and 31 walked me slowly through each concept individually — transfer fees, metadata, ATAs — one at a time. Everything was extremely pertinent. Sometimes slowing down is how you actually understand what you already did.
Day 33 — Soulbound Tokens
On day 33 I built a token that cannot be transferred. Ever.
These are called soulbound tokens — and because they can never move between wallets, they must be minted directly into the ATA of the final intended owner. The token is bound to that address forever.
"What's the point of a token you can't send to anyone?"
More than you'd think. Their use cases include:
- 🎓 Credentials — proof you completed a course or passed a certification
- 🏅 Badges — on-chain achievements tied to a specific wallet
- 🪪 Membership proofs — non-sellable, non-transferable access rights The restriction is enforced at the Token-2022 program level. There is no workaround — any transfer instruction on a non-transferable mint will always fail.
What Surprised Me
While going through the multiple token creation challenges, I dug into the Solana Token Extensions Technical Paper and discovered something that genuinely caught my attention: confidential transfers.
By default, everything on the Solana blockchain is publicly visible — balances, transaction amounts, wallet addresses. Confidential transfers use zero-knowledge proofs to encrypt transaction amounts on-chain, making them verifiable without being readable.
This opens doors for business-critical use cases that simply weren't possible before on a public chain — payroll, private treasury movements, B2B settlements. The infrastructure is already there. It just needs to be used.
What's Next
I'll keep learning something new about Solana development every single day. I'll sporadically post write-ups like this one so you can follow along with what I'm discovering on the journey.
Follow me if you want to see more. The deeper we go, the more interesting it gets.
Top comments (0)