This week, I explored Solana's Token-2022 program by building custom SPL tokens with metadata, protocol-level transfer fees, and non-transferable (Soulbound) extensions using the Solana CLI.
Out of everything I built this week, one moment stood out.
The Experiment
After creating a non-transferable (Soulbound) token, I generated a second wallet and attempted to transfer the token.
Instead of succeeding, the blockchain rejected the transaction with the following message:
Program log: Transfer is disabled for this mint
That single line completely changed how I think about blockchain applications.
The Biggest Lesson
Coming from a Web2 background, I'm used to enforcing rules through:
- Backend APIs
- Database constraints
- Frontend validation
On Solana, Token-2022 lets the asset itself define its behavior.
A non-transferable token doesn't rely on an application deciding whether a transfer is allowed. The Token-2022 program enforces the rule directly at the protocol level, meaning every wallet, application, and SDK automatically follows it.
That distinction between application-layer logic and protocol-layer logic was the biggest takeaway from this week's learning.
What's Next?
Next, I'll be implementing these same token interactions using:
@solana/web3.js@solana/spl-token
before moving into on-chain development with Anchor Framework.
I also documented my complete journey—from creating my first token mint to experimenting with metadata, transfer fees, and Soulbound tokens—in my previous article:
Thanks for following along!