One of the things that surprised me most while learning Solana is how much functionality can exist directly inside a token.
In traditional Web2 applications, features like interest accrual, transaction fees, user verification, account restrictions, and credentials are usually implemented through backend services, databases, and application logic. Developers spend significant time wiring these systems together and ensuring they work correctly.
Over the last five days of my #100DaysOfSolana journey, I explored how Solana's Token-2022 program approaches the same problems differently. Instead of building these features around a token, many of them can be built directly into the token itself through extensions.
Day 36 — Creating an Interest-Bearing Token
The first extension I explored was the Interest-Bearing Token extension.
At first, I expected the token balance itself to increase over time. What I learned was much more interesting.
The actual on-chain balance never changes. Instead, Solana stores an interest rate and uses time-based calculations to display an adjusted balance to users and applications.
This creates an experience similar to a savings account where your balance appears to grow continuously while the underlying ledger remains unchanged.
Some key takeaways:
Interest rates are configured in basis points.
Wallets calculate adjusted balances using elapsed time.
No additional tokens are minted automatically.
The extension acts as a display layer rather than modifying token supply.
It was my first look at how financial primitives can be implemented directly at the protocol level.
*Day 37 — Combining Multiple Extensions
*
After experimenting with individual extensions, I wanted to see what would happen if multiple extensions were combined into a single token.
I created a token that included:
Transfer fees
Interest-bearing balances
On-chain metadata
This was where the Token-2022 design really started to click for me.
Each extension operates independently while sharing the same mint account. The token could charge fees during transfers, display interest-adjusted balances, and carry its own metadata without any of the features interfering with one another.
The biggest lesson from this day was understanding that extension choices must be made when the mint is created. Solana allocates account space upfront, so planning matters.
*Day 38 — Building a Compliance-Gated Token
*
Financial systems often require permissions before users can transact.
Brokerage accounts require verification.
Payment apps may freeze suspicious accounts.
Many regulated assets require approval before transfers can occur.
To replicate this pattern, I experimented with the Default Account State extension.
Every new token account created for the mint started in a frozen state.
Nothing could be transferred, received, or burned until the freeze authority explicitly approved the account.
What made this powerful was that enforcement happened at the protocol level rather than inside application code.
Even if a frontend contained a bug, users still couldn't bypass the restriction because the blockchain itself enforced the rules.
This was my first exposure to how regulated asset systems can be implemented directly on Solana.
Day 39 — Reading Before Building
After creating several different token configurations, I spent a day inspecting and comparing them.
Instead of deploying something new, I focused on understanding what I had already built.
I examined:
Interest-bearing mints
Multi-extension mints
Default-frozen mints
Using the CLI, I reviewed extension configurations, authorities, metadata, fees, and account sizes.
One observation stood out immediately:
More extensions mean larger account sizes.
Larger accounts require larger rent-exempt deposits, which means every design decision has a cost attached to it.
This reinforced an important engineering lesson:
Before building new systems, understand the systems that already exist.
*Day 40 — Creating Revocable Digital Credentials
*
The most interesting experiment of the week involved combining two extensions I had never used before:
Non-Transferable
Permanent Delegate
Together, these allowed me to create a token that behaved like a digital credential.
The token could:
Be issued to a specific wallet
Never be transferred to another wallet
Be revoked by the issuing authority
This closely resembles real-world certificates, licenses, employee badges, or verified status systems.
A credential belongs to the recipient, but the issuing organization still retains the ability to revoke it when necessary.
Seeing this implemented entirely through token extensions was fascinating.
The token itself enforced ownership and transfer restrictions without requiring additional application logic.
What I Learned This Week
This week completely changed how I think about tokens.
I started by viewing tokens as simple units of value.
Now I see them as programmable assets capable of enforcing business rules directly at the protocol level.
Across these five days I learned how to build:
Interest-bearing financial assets
Fee-generating tokens
Compliance-gated systems
Multi-extension token architectures
Soulbound credentials with revocation mechanisms
The most valuable lesson wasn't a specific command or extension.
It was understanding that Token-2022 turns tokens into building blocks for entire applications.
Instead of asking, "What can my application do with a token?"
I'm starting to ask,
"What functionality can I move directly into the token itself?"
And that shift in perspective might be the biggest lesson I've learned so far in my Solana journey.
Top comments (0)