If you come from Web2, the idea of a token might seem like a simple integer variable stored in a database. But on Solana, tokens are deeply integrated into the programming model. This week, I went from compiling my first dependencies to creating fully featured tokens using Solana's Token Extensions Program (Token 2022).
In this post, I want to walk you through what I learned, how token extensions change the game, and why enforcing economic rules on-chain instead of off-chain is so powerful.
The Starting Point: Why The Token Extensions Program?
When I first started looking into Solana, I learned about the standard Token Program. It's the original program that handles SPL tokens. But then I discovered the Token Extensions Program (often referred to as Token-2022).
Why do we need a new program? Because the original program was simple by design. If you wanted to do something complex-like enforcing transfer fees, tying metadata directly to the token mint, or making a token non-transferable, you had to build an entire custom smart contract to act as an intermediary.
The Token Extensions Program brings these powerful features directly to the protocol level. You can just configure the mint to utilize specific extensions, and the protocol handles the rest. This drastically reduces the surface area for bugs and the barrier to entry for developers.
Adding Metadata Directly to the Mint
Previously, token metadata (like the name, symbol, and URI for an image) was typically handled by Metaplex programs off to the side. With the MetadataPointer and TokenMetadata extensions, you can embed this directly.
Here is what the flow looks like when initializing a mint with token extensions via the CLI:
solana-keygen new --outfile token-keypair.json
spl-token create-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb --transfer-fee-basis-points 200 --transfer-fee-maximum-fee 5000 --enable-metadata --decimals 9
By linking metadata directly to the mint, building indexers, wallets, or explorers becomes so much simpler. Everything you need is right there in the token's core data structure. No hunting across different accounts.
Enforcing Transfer Fees at the Protocol Level
One of the most fascinating extensions I experimented with is the TransferFeeConfig. Let's say you want to build a token that burns 1% of every transaction, or sends a 1% royalty to the creator's treasury.
In traditional Web2 logic, you'd write a server route that deducts this amount before updating the database. But blockchains are public; users can bypass your server and transact directly. With the transfer fee extension, the rule is baked into the token's DNA.
When you attach this extension, the blockchain will not allow a transfer to succeed unless the fee is properly calculated and withheld. This is what it means to enforce economic rules in code rather than policy documents. It requires zero custom smart contracts—just standard configuration.
Soulbound: Non-Transferable Tokens
The final extension that blew my mind was creating a non-transferable token. In the Web3 world, these are sometimes called "Soulbound" tokens. They are permanent credentials glued to your wallet.
Think about a university degree or an event ticket. You want the person to own it, but you definitely don't want them selling it on an exchange.
By applying the NonTransferable extension during mint creation, the token becomes forever locked to the account it is minted to. If someone tries to solana transfer <mint> <amount> <recipient>, the transaction will simply fail. The blockchain itself rejects it.
What Surprised Me Most
The biggest moment for me was realizing just how much heavy lifting the Solana protocol can do for developers out of the box. Coming from an environment where I normally have to write an entire backend service to manage custom tokenomics, the fact that I could enable transfer fees and non-transferability just by passing a few flags during initialization was stunning.
It feels less like writing complex financial software and more like configuring a highly secure, decentralized operating system.
What’s Next?
Building these tokens locally and via the CLI on devnet was an incredible foundation. Next week, I plan to dive into how these tokens interact with actual custom on-chain programs (smart contracts). Now that I understand the assets, I want to write the logic that trades, manages, and interacts with them.
If you are a Web2 developer sitting on the fence, jump in. The water is fine, and the tooling has never been better. Follow along on my #100DaysOfSolana journey!
Top comments (0)