From Simple Tokens to Programmable Assets
When most developers think about tokens, they think about balances and transfers.
A user owns tokens, sends them to another account, and that's it.
But many real-world assets need additional rules:
- A gift card that charges a fee when transferred
- A membership badge that cannot be sold
- A regulated asset that can be frozen
- A credential that an issuer can revoke
- A loyalty program with rich metadata attached
In traditional systems, these rules are usually implemented in backend services and databases.
With Solana's Token-2022 program, many of these behaviors can be embedded directly into the token itself through Token Extensions.
Over the past week as part of the #100DaysOfSolana challenge, I explored several Token Extensions and experimented with combining them to create different token behaviors.
This article summarizes what I learned and how these extensions can be used in practice.
What Are Token Extensions?
Token Extensions are optional features that can be attached to a mint or token account when using the Token-2022 program.
Instead of deploying a custom smart contract for every use case, developers can activate predefined extensions that add functionality directly to the token.
Some examples include:
Extension Purpose
- Transfer Fee Charges a fee on token transfers
- Metadata Pointer Links metadata directly to the mint
- Default Account State New accounts start frozen
- Non-Transferable Prevents tokens from being transferred
- Permanent Delegate Grants permanent authority over token accounts
The interesting part is that these extensions can be combined to create entirely different asset models.
Combination Nº1: Transfer Fees + Metadata
This was the first combination I experimented with.
The idea is simple:
Every transfer pays a fee
The token includes rich metadata
This could be useful for:
- Loyalty points
- Community currencies
- Revenue-sharing systems
- In-app economies
The metadata makes the asset easier to identify in wallets and explorers, while transfer fees introduce economic rules directly at the protocol level.
Combination Nº2: Default Frozen Accounts + Permanent Delegate
This combination felt much closer to traditional compliance systems.
Every newly created token account starts in a frozen state.
A designated authority can then decide:
- Who receives access
- When accounts become active
- When access should be revoked
This pattern could be useful for:
- Enterprise assets
- Compliance-gated tokens
- Educational certificates
- Membership programs
What surprised me most was how little custom logic is needed.
Many behaviors that would normally require an additional smart contract already exist as built-in extensions.
Combination Nº3: Non-Transferable + Permanent Delegate
This was probably the most interesting experiment.
A non-transferable token behaves similarly to a soulbound credential.
Once issued, the holder cannot transfer it to another account.
Adding a Permanent Delegate introduces administrative control that can be useful for:
- Certifications
- Event attendance badges
- Academic credentials
- Identity systems
The token becomes a credential rather than a tradable asset.
This shift in thinking was one of the biggest lessons from exploring Token Extensions.
Not every token needs to represent money.
Sometimes a token represents reputation, access, or proof.
Reading a Mint and Inspecting Extensions
One of the most valuable exercises was inspecting existing Token-2022 mints and reading their configuration accounts.
Instead of only creating tokens, I started asking:
- Which extensions are enabled?
- What authorities exist?
- How are fees configured?
- Is metadata stored on-chain?
- Are transfers restricted?
This helped me understand how other developers design token systems and how different extension combinations affect behavior.
Example: Creating a Transfer Fee Token
One of the commands I used during my experiments was creating a mint with transfer fees enabled.
spl-token create-token \
--transfer-fee-basis-points 250 \
--transfer-fee-maximum-fee 1000
What this configuration does:
- Creates a Token-2022 mint
- Applies a 2.5% transfer fee
- Caps the maximum fee at 1000 tokens
From that point forward, transfers automatically follow the rules defined by the extension.
No additional smart contract logic is required.
What Confused Me
Initially, I assumed Token Extensions were simply extra metadata fields. They're much more powerful than that.
The biggest mental shift was understanding that extensions modify token behavior itself. The token is no longer just a balance. It becomes a programmable asset with built-in rules.
Another challenge was understanding which extensions make sense together.
Some combinations complement each other naturally, while others introduce restrictions that may not fit the intended use case.
Designing token behavior becomes an architecture exercise.
What Clicked
The idea that clicked for me was this:
Token Extensions move business rules closer to the asset itself.
Instead of relying entirely on backend infrastructure, many common requirements can be enforced directly by the token program.
That opens interesting possibilities for:
- Digital credentials
- Loyalty systems
- Compliance-focused assets
- Membership tokens
- On-chain identity
Final Thoughts
Before exploring Token-2022, I mostly thought about tokens as transferable balances.
After working with Token Extensions, I started thinking about tokens as configurable digital objects.
A token can represent money.
- A credential.
- A membership.
- A permission.
Or something entirely different.
The extension model gives developers a toolkit for defining those behaviors without building everything from scratch.
If you're learning Solana and haven't explored Token Extensions yet, I highly recommend experimenting with them.
They completely change what a token can be.
For deeper technical details, check out the official Token-2022 Extensions documentation and implementation guides from the Solana ecosystem.
Top comments (0)