What Token Extensions Finally Made Me Understand

Subtitle: Token-2022 showed me that tokens can have rules, not just balances.

This week I moved past basic SPL tokens and started using Token Extensions.

At first, I thought a token was mostly just:

• a mint
• token accounts
• balances
• transfers

But Token-2022 adds something more interesting: behavior.

A token can charge transfer fees.
A token can display interest over time.
A token can start every account frozen.
A token can be non-transferable.
A token can have a permanent delegate for revocation.

That made tokens feel less like simple coins and more like product systems.

Interest-bearing tokens

The first extension that clicked was interest-bearing tokens.

The weird part is that the raw balance does not actually grow. If I mint 1000 tokens, the account still holds 1000 tokens. The interest-bearing extension changes the UI amount by applying an interest formula over time.

So it feels like a savings account, but without a backend cron job constantly minting more tokens.

That was the first “ohhh” moment.

Multi-extension tokens

Then I tried combining extensions.

One mint could have:

• transfer fees
• interest
• metadata

That means the token can charge a fee when it moves, display an interest-adjusted balance, and carry its name, symbol, and URI.

The important lesson: extensions must be planned before the mint is created. You cannot just bolt them on later like a random npm package. Annoying, but fair.

Here is the kind of command I used:

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  create-token \
  --decimals 2 \
  --transfer-fee-basis-points 100 \
  --transfer-fee-maximum-fee 500 \
  --interest-rate 5 \
  --enable-metadata

That creates a Token-2022 mint with multiple extensions enabled.

Default frozen accounts

The default frozen account extension felt like a compliance system.

Every new token account starts frozen. The authority has to thaw an account before it can receive, send, or burn tokens.

In Web2 terms, it is like saying:

“You can have an account, but you cannot use it until you are approved.”

That makes sense for regulated assets, gated communities, or tokens where both sender and receiver need permission.

Inspecting mints

One of the best lessons was not building, but reading.

Using:

spl-token display [MINT_ADDRESS] \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

I could inspect which extensions were active on a mint.

That made me realize extension configuration is like reading a project’s config file. Before trusting a token, you should check its rules.

Does it have fees?
Who controls the fee authority?
Is there a freeze authority?
Is there a permanent delegate?

The token’s behavior is part of the trust model.

Revocable credentials

My favorite idea was combining:

• non-transferable tokens
• permanent delegate
• metadata

That creates something like a certificate.

The token cannot be transferred, so the holder cannot sell it or send it to someone else. But the issuer can still revoke it by burning it through the permanent delegate.

That makes sense for:

• course certificates
• badges
• memberships
• licenses
• reputation tokens

This was the moment Token Extensions felt less like “crypto stuff” and more like actual product design.

Token Extensions are not random features.

They are rules.

Transfer fees decide what happens when value moves.
Interest-bearing extensions decide how balances are displayed.
Default frozen accounts decide who is allowed in.
Non-transferable tokens decide whether something can be sold.
Permanent delegates decide who can revoke or control tokens.

The big lesson: with Token-2022, the token program can enforce behavior that an app would normally need to manage itself.

That is powerful.

Also slightly terrifying.

Because once these rules exist, users need to know what they are holding.

Tags: #solana #web3 #learning #100daysofsolana