DEV Community: gouri t

Day 56 of #100DaysOfSolana

gouri t — Sun, 14 Jun 2026 14:10:35 +0000

Building a Token-2022 Trilogy on Solana: Transfer Fees, Interest-Bearing Tokens, and Non-Transferable Assets

Over the past week, I spent some time exploring Token-2022 on Solana as part of my #100DaysOfSolana journey.

Before this challenge, I thought tokens were fairly simple: create a mint, issue tokens, and transfer them between accounts. Token-2022 completely changed that perspective.

What surprised me most was that many advanced token behaviors can be configured directly through extensions without writing an entirely new token program.

To understand what's possible, I built three different Token-2022 examples:

A token that charges fees on transfers
A token that accrues interest over time
A token that cannot be transferred at all

Here's what I learned.

1. Transfer Fee Token

The first extension I explored was Transfer Fees.

The idea is simple: whenever someone transfers tokens, a percentage of the transfer is automatically collected as a fee.

Instead of building custom logic into an application, the token itself enforces the rule.

This immediately made me think about real-world use cases:

Protocol revenue sharing
Community treasuries
Creator royalties
Ecosystem funding mechanisms

Creating the token was straightforward, but seeing the fee behavior enforced at the token level was the interesting part. Once configured, every transfer follows the same rules automatically.

That was my first glimpse into how powerful Token-2022 can be.

2. Interest-Bearing Token

Next, I experimented with the Interest-Bearing extension.

This was probably the most interesting feature in the trilogy.

Traditional reward systems often require additional programs, scheduled updates, or custom accounting logic. With Token-2022, interest can be represented directly through the token configuration itself.

As I worked through the implementation, I started to see potential applications:

Savings products
Loyalty systems
Reward mechanisms
Educational experiments in tokenized finance

What stood out most wasn't just the feature itself—it was how much complexity could be handled by the token standard rather than application code.

The more I explored Token-2022, the more I realized that token design can influence application behavior in powerful ways.

3. Non-Transferable Token

For the final experiment, I built a non-transferable token.

At first this sounded strange.

Why create a token that cannot be transferred?

After spending some time thinking about it, the use cases became obvious:

Certificates
Achievement badges
Membership credentials
Identity-related assets
Course completion records

In these situations, transferring ownership would actually defeat the purpose of the asset.

Testing the transfer restrictions was a good reminder that not every token is meant to behave like money. Sometimes the value comes from proving ownership rather than enabling movement.

What I Learned About Token-2022

Before this project, I viewed Token-2022 as an upgraded token program with a few extra features.

After building these examples, I see it differently.

Token-2022 feels more like a framework for composing token behavior.

Instead of creating custom programs for every new requirement, developers can combine extensions to build assets with specific characteristics.

A token can:

Charge fees
Earn interest
Store metadata
Restrict transfers
Support additional extensions

All while remaining part of the same ecosystem.

That flexibility opens the door to many new asset designs.

Final Thoughts

This Token-2022 trilogy gave me a much deeper appreciation for how much functionality can live at the token layer.

The transfer fee token showed me how economic rules can be embedded directly into an asset.

The interest-bearing token demonstrated how value can evolve over time without complex application logic.

The non-transferable token challenged my assumption that every token should be freely transferable.

For anyone learning Solana, I highly recommend spending time with Token-2022 extensions. They're a great way to understand how token behavior can be customized without building everything from scratch.

As I continue through #100DaysOfSolana, I'm excited to explore more extensions and see how they can be combined to create even more interesting on-chain assets.

Thanks for reading.

Solana #Web3 #Blockchain #Token2022 #100DaysOfSolana

Write about the account model

gouri t — Sat, 16 May 2026 17:29:43 +0000

Solana’s account model can feel confusing at first. Terms like lamports, owners, and program accounts sound very blockchain-specific, and when you inspect a Solana account in the CLI or Explorer, the JSON output can look intimidating.

But once you stop thinking about Solana like Ethereum and start thinking about it like a filesystem or database system, things begin to click.

In this article, I’ll break down Solana’s account model in plain English for developers who have never worked with blockchain before.

Everything on Solana Is an Account

One of the biggest differences between Solana and Ethereum is how state is stored.

In Ethereum, there are two main account types:

Externally Owned Accounts (EOAs) → user wallets
Contract Accounts → smart contracts

Solana simplifies this idea.

On Solana, everything is an account:

Wallets
Smart contracts (called programs)
Token balances
NFTs
Application state

All of them are stored using the same account structure.

You can think of Solana like a giant key-value database:

Key Value
32-byte public address Account data

Each account lives at a unique public address and contains metadata plus optional data.

A Web2 Analogy: Solana as a Filesystem

The easiest way to understand Solana accounts is to compare them to files in an operating system.

Imagine:

Each account = a file
The data field = file contents
The owner = which program controls the file
Programs = executable files
Data accounts = documents/databases
The System Program = operating system kernel

Programs don’t directly “own” all their data internally. Instead, they read and write to separate accounts, similar to how a backend server interacts with a database.

This design makes Solana extremely flexible and parallelizable.

The Five Fields Every Account Has

Every Solana account follows the same structure.

Here are the five important fields:

Lamports

Lamports are the smallest unit of SOL.

1 SOL = 1,000,000,000 lamports

This field stores the account’s SOL balance.

Example:

"lamports": 2039280

That means the account holds 0.00203928 SOL.

Data

This is a byte array that stores arbitrary information.

Programs use this field to save state such as:

token balances
NFT metadata
game progress
user profiles

Example:

"data": ["", "base64"]

If the array is empty, the account stores no custom data.

Owner

The owner field defines which program controls the account.

Example:

"owner": "11111111111111111111111111111111"

That address belongs to the System Program.

The important rule is:

Only the owner program can modify the account’s data.

This is one of Solana’s core security mechanisms.

Executable

This is a boolean value:

true → the account contains executable program code
false → normal data account

Example:

"executable": false

Most accounts are non-executable.

Program accounts are special because they store deployable smart contract code.

Rent Epoch

This field is now deprecated and usually set to the maximum value.

Historically, it tracked when rent payments were due.

You’ll still see it in account output, but modern Solana apps rarely interact with it directly.

Ownership Rules: Solana’s Security Model

Solana’s ownership model is surprisingly simple.

Rule 1:

Only the owner program can:

modify account data
subtract lamports from the account
Rule 2:

Anyone can send lamports to any writable account.

This is similar to how anyone can transfer money to your bank account, but only you can spend from it.

Because ownership is enforced by the runtime itself, programs cannot randomly modify accounts they do not control.

The Concept That Surprises Most Developers

Here’s the part that usually shocks Web2 developers:

Programs Don’t Store Their Own State

In Ethereum, smart contracts usually contain both:

code
storage/state

Solana separates them.

A Solana program is mostly stateless.

Instead:

Program account → stores executable code
Data accounts → store application state

Think of it like this:

Web2 Backend Solana
Express server Program
PostgreSQL database Data accounts

The program reads and writes data from separate accounts passed into each transaction.

This architecture allows Solana to process many transactions in parallel because the runtime already knows which accounts a transaction will touch.

Rent Exemption

Accounts on Solana are not free.

Every account must maintain a minimum SOL balance based on how much data it stores.

This is called rent exemption.

Why?

Because validators need storage resources to keep accounts on-chain.

For a basic empty account, the minimum balance is roughly:

0.00089 SOL

Larger accounts require more lamports.

You can calculate rent exemption using:

solana rent

Or through the RPC method:

getMinimumBalanceForRentExemption

If an account doesn’t maintain enough balance, it may eventually be cleaned up by the network.

Example Account Output

Here’s what a typical account might look like:

{
"lamports": 2039280,
"owner": "11111111111111111111111111111111",
"executable": false,
"rentEpoch": 18446744073709551615,
"data": ["", "base64"]
}

Now you can actually read this:

It holds some SOL
It’s controlled by the System Program
It is not executable
It stores no custom data
It is rent exempt

That’s the account model in action.

Why Solana Uses This Design

At first, separating programs from state can feel awkward.

But it gives Solana major advantages:

better parallel transaction execution
predictable state access
flexible storage patterns
improved scalability

Instead of programs hiding internal storage, all state is explicit and passed into transactions directly.

That design is one of the reasons Solana can achieve very high throughput.

Final Thoughts

The Solana account model is the foundation of everything on the network.

Once you understand:

accounts
ownership
data storage
rent exemption
stateless programs

…you can understand how tokens, NFTs, DeFi protocols, and nearly every Solana application works internally.

For Web2 developers, the biggest mental shift is this:

On Solana, programs behave more like APIs interacting with databases than traditional objects storing their own internal state.

And honestly, once that clicks, the entire ecosystem becomes much easier to understand.

For more details, check out the official documentation from Solana Foundation and the developer resources on Solana Docs and DEV Community.