DEV Community: LittleNezhaMin

Three Token-2022 mints in one week: fees, yield, and soul-bound tokens

LittleNezhaMin — Thu, 18 Jun 2026 04:31:13 +0000

Last week I stopped thinking about tokens as "just balances" and started thinking about them as assets with middleware baked directly into the mint.

If you're coming from Web2, here's the mental model that helped me: Token-2022 is the upgraded SPL token program, and extensions are like middleware for a currency. In a typical backend, you might bolt on a fee layer, a yield layer, or a transfer policy in separate services. On Solana, those rules can live inside the mint itself. That means wallets, dApps, CLIs, and programs all read the same behavior from the same on-chain account instead of relying on your custom wrapper.

Over a few days on devnet, I shipped three different Token-2022 mints:

a fee-bearing mint that skims 1% on every transfer
a stacked mint that combines transfer fees with interest-bearing UI balances
a non-transferable mint that refuses to move at all

I also audited all of them afterward to confirm the extensions on chain matched the behavior I thought I had configured.

One honest note before we jump in: my local shell did not have solana and spl-token in PATH, so I executed the experiments through @solana/web3.js and @solana/spl-token. The commands below are the canonical spl-token equivalents for the exact flows I mirrored on devnet.

1. Fee-Bearing Mint

Mint address:

CFTBSCy68VqUzGeMwjmgzufeBgGi64i281f4iUxzavj7

Explorer:

https://explorer.solana.com/address/CFTBSCy68VqUzGeMwjmgzufeBgGi64i281f4iUxzavj7?cluster=devnet

Extensions used:

TransferFeeConfig

Create command:

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  create-token \
  --transfer-fee-basis-points 100 \
  --transfer-fee-maximum-fee 1000000 \
  --decimals 6

What it does:

This mint charges a 1% fee on every transfer. The fee rule is not enforced by my app code or some custom contract next to the token. It's enforced by the Token-2022 program itself because the fee config is part of the mint account.

When I tested this mint, a transfer of 1000 tokens withheld 10 tokens exactly as expected.

Why a builder would want this:

This is a clean fit for something like a creator economy token or a community currency where each transfer sends a small treasury skim back to the project. Instead of trusting every integration to remember your fee logic, the asset carries the rule with it.

2. Interest-Bearing + Fee Mint

Mint address:

51r9jZ2C3pj5D1GrrwgDFxPDN3xVwaUMUeZ875oYYwPd

Explorer:

https://explorer.solana.com/address/51r9jZ2C3pj5D1GrrwgDFxPDN3xVwaUMUeZ875oYYwPd?cluster=devnet

Extensions used:

TransferFeeConfig
InterestBearingConfig

Create command:

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --decimals 6 \
  --transfer-fee-basis-points 100 \
  --transfer-fee-maximum-fee 1000000 \
  --interest-rate 5000

What it does:

This mint combines two behaviors:

every transfer pays a 1% fee
every holder sees the UI amount grow over time at the configured interest rate

The subtle part, and the part I wish more tutorials emphasized, is that the interest-bearing extension does not mint new supply into token accounts. The raw amount stored on chain stays fixed. What changes is the UI amount that clients compute from the mint's rate configuration and the network clock.

That means this:

raw amount can stay 1000000000000
displayed UI amount can drift upward over time

In my test, the same account moved from 1000000.031688 to 1000000.522867 in about 31 seconds without any transaction landing in between. On the recipient side, a transfer still withheld 10 tokens in fees, and the recipient's UI amount also started drifting upward immediately.

That's why this mint felt like the clearest "Token-2022 is middleware for assets" demo of the week: two totally different behaviors, one mint, no custom program written by me.

3. Non-Transferable Mint

Mint address:

GnHWVxdfWgDqbpDVgZbEdWbZ8wrX4Ct5fP5uyMEY4MPW

Explorer:

https://explorer.solana.com/address/GnHWVxdfWgDqbpDVgZbEdWbZ8wrX4Ct5fP5uyMEY4MPW?cluster=devnet

Extensions used:

NonTransferable

Create command:

spl-token create-token --program-2022 --enable-non-transferable

What it does:

This is the opposite of money. Once the token lands in an account, it cannot be transferred out. That makes it a good fit for badges, credentials, proof-of-completion tokens, or any soul-bound style identity artifact.

I intentionally created a recipient token account first and then tried to transfer 1 token into it just to make sure the failure came from the program rule itself, not from some unrelated missing-account error.

This was the exact runtime rejection I got:

Program log: Instruction: TransferChecked
Program log: Transfer is disabled for this mint
Program TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb failed: custom program error: 0x25

That error is the feature. The mint is carrying a transfer policy that the protocol itself enforces.

What Day 53 Taught Me

After building these mints, I audited them the same way I would inspect a database schema after a migration.

The Day 50 / 51 mint read back with TransferFeeConfig
The Day 52 mint read back with both TransferFeeConfig and InterestBearingConfig
The Day 54 mint read back with NonTransferable

That audit step mattered more than I expected. It's one thing to remember which flag I typed into a command. It's another thing entirely to read the mint account back from chain and see the protocol decode the exact behavior I thought I had shipped.

Closing Reflection

What surprised me most was how composable these extensions are. I expected Token-2022 to feel like "more options on a token." Instead, it felt more like a design space for asset behavior. The transfer-fee mint felt useful for treasury or royalty-style flows. The interest-bearing mint made me think about internal reward systems and financial UX where displayed value changes over time without mutating raw balances. The non-transferable mint was the most conceptually fun because it flips the token primitive from money into identity. If I were building a real product tomorrow, I'd reach for these extensions long before reaching for a custom token program.

If you're a Web2 developer learning Solana, Token-2022 is one of the best places to start because it teaches a deep lesson quickly: on-chain assets do not just store value, they can store rules.

Understanding Solana’s Account Model as a Web2 Developer

LittleNezhaMin — Sun, 17 May 2026 14:44:14 +0000

When I first started learning Solana, the thing that confused me most wasn’t transactions or wallets.

It was accounts.

Every tutorial kept talking about accounts:

Wallet accounts
Program accounts
Token accounts
Data accounts

At first, it sounded like blockchain jargon overload.

But after spending a few days inspecting accounts using the Solana CLI and Explorer, something finally clicked:

On Solana, everything is an account.

Once you understand that idea, the rest of Solana starts making a lot more sense.

In this article, I’ll explain Solana’s account model from the perspective of a Web2 developer.

⸻

The Mental Shift: Solana Is a Giant Key-Value Store

In Web2, we usually think in terms of:

databases
tables
backend servers
APIs
application state

Solana works differently.

Instead of storing application state inside a backend server, Solana stores everything inside accounts on-chain.

Every Solana Account Has the Same Structure

No matter what type of account you inspect, they all contain the same core fields.

A Solana account contains:

lamports
data
owner
executable
rent_epoch

Here’s an example using the Solana CLI:
solana account <ACCOUNT_ADDRESS>
Example output:
`{

"lamports": 1505728269681,

"owner": "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA",

"executable": false,

"rentEpoch": 18446744073709551615,

"data": [...]

}`
Let’s break those fields down.

Lamports = SOL Balance

Lamports are the smallest unit of SOL.

Think of them like satoshis in Bitcoin.
1 SOL = 1,000,000,000 lamports
If an account has:
1500000000 lamports
That means it owns:
1.5 SOL
Every account can hold SOL, not just wallets.

That surprised me at first.

Data = Arbitrary State Storage

The data field is where programs store information.

This could contain:

token balances
NFT metadata
game inventory
DeFi positions
DAO governance state

The important thing is:

Solana stores raw bytes.

Programs are responsible for interpreting those bytes.

This feels similar to reading binary files or serialized objects in traditional systems.

⸻

Owner = Who Controls the Account

This is one of the most important concepts in Solana.

Every account has an owner.

But the owner is usually NOT a user.

It’s typically a program.

Example:
TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
That’s the SPL Token Program.

If an account is owned by the Token Program, only the Token Program can modify that account’s data.

This creates a very clean security model.

Ownership Rules

On Solana:

Only the owner program can modify account data
Only the owner program can debit lamports
Anyone can send lamports into a writable account

That’s surprisingly elegant.

⸻

Executable = Is This a Program?

This field is simply:
true or false
If:
executable = true
then the account contains executable program code.

If:
executable = false
then it’s just a data account.

This is where Solana differs a lot from Ethereum.
Programs Don’t Store Their Own State

This was probably the biggest mental shift for me.

In Ethereum, smart contracts usually contain both:

code
state

On Solana, programs are stateless.

The executable code lives in one account.

The data lives in separate accounts.
Programs read and write external accounts instead of storing state internally.

That design allows Solana to parallelize transactions more efficiently.

Rent Epoch (Deprecated)

Older Solana docs talk about rent_epoch.

Today, this field is effectively deprecated and usually set to:
18446744073709551615
Most developers can ignore it now.
Rent Exemption

One thing I found interesting is that storing data on Solana costs money.

Every account must maintain a minimum balance to remain on-chain.

This is called being:
rent-exempt
The larger the account data size, the more SOL it needs.

For example:
solana rent 0
returns the minimum balance needed for an empty account.

At the time I tested it, it was around:
0.00089 SOL
This mechanism prevents the blockchain from being flooded with useless data forever.
My Favorite Analogy: Solana as a Filesystem

The analogy that finally made everything click for me was this:

Imagine Solana as a giant operating system filesystem.

Each account is like a file.

Accounts contain:

metadata
permissions
contents

Programs are executable files.

Data accounts are documents those programs read and write.

The System Program acts like the operating system kernel managing account creation and ownership.

Once I started thinking about Solana this way, the architecture suddenly felt much more familiar.

⸻

Final Thoughts

At first, Solana’s account model felt strange coming from Web2.

But now I actually think it’s one of the cleanest parts of Solana’s design.

The key ideas that helped me most were:

Everything is an account
Programs are stateless
Ownership controls security
Accounts are just structured storage

Once those concepts click, reading Solana transactions and programs becomes much easier.

If you’re a Web2 developer learning Solana right now, my advice is simple:

Spend time inspecting real accounts.

Use:
solana account <address>
Look at Explorer.

Read the raw JSON.

Eventually the patterns start revealing themselves naturally.

And honestly, that’s when blockchain development starts becoming really fun 🚀

Solana Transactions Explained for Backend Developers

LittleNezhaMin — Sun, 10 May 2026 07:11:09 +0000

Over the past few days in #100DaysOfSolana, I went from knowing almost nothing about Solana transactions to building my own CLI transfer tool, tracking transaction confirmations in real time, and debugging failed on-chain transactions.

Coming from a backend/web2 background, Solana transactions initially felt confusing. Terms like signatures, blockhashes, commitment levels, and atomic state changes sounded very different from the APIs and databases I was used to.

But after building and breaking transactions myself, something finally clicked.

In this post, I want to explain Solana transactions from the perspective of a backend developer.

⸻

The Mental Model Shift

At first, I treated a Solana transaction like an HTTP request:
`POST /transfer

{

"from": "...",

"to": "...",

"amount": 0.01

But that mental model is incomplete.

A Solana transaction is closer to a signed, atomic database transaction that gets executed by a decentralized network.

Unlike a normal API request:

there is no centralized server
every transaction must be cryptographically signed
transactions expire quickly
failures still cost fees
consensus happens in stages

That last point surprised me the most.

⸻

Transaction Confirmation Is Not Binary

In web2 systems, requests are usually either:

pending
successful
failed

But on Solana, transactions move through multiple commitment levels:

Processed

A validator received and processed the transaction.

This is similar to:

“The server accepted your request.”

But it is not finalized yet.

⸻

Confirmed

A supermajority of validators voted on the block containing your transaction.

This is effectively:

“The network agrees your transaction succeeded.”

Interestingly:

no confirmed transaction in Solana history has ever been reversed.

⸻

Finalized

31+ additional blocks were built on top of your transaction.

At this point, the transaction is considered irreversible.

This feels similar to:

replicated database commits
durable writes
globally finalized state

⸻

Building My Own Transfer Tool

One of the most useful exercises was building a reusable CLI transfer tool using:

Node.js
@solana/kit
Solana CLI keypairs

Instead of manually typing transfer commands every time, the tool:

accepts recipient + amount arguments
checks balances
signs transactions locally
submits transactions to devnet
tracks confirmation progress
prints Explorer links node transfer.mjs <RECIPIENT> 0.01 Terminal output: `Solana Transfer Tool ==================== Connected to Solana devnet.

Status: processed ✅
Status: confirmed ✅
Status: finalized ✅

Transaction successful!`
his felt very similar to building internal tooling around payment APIs in web2.

Except this time:

there was no Stripe
no backend server
no payment gateway

The transaction went directly to the blockchain network.

⸻

Failed Transactions Taught Me More Than Successful Ones

One thing I underestimated:

failed transactions are incredibly educational.

For example, I intentionally tried sending more SOL than my balance:
node transfer.mjs RECIPIENT 999
Result:
Transaction failed: Insufficient balance...
I also learned:

failed transactions still consume fees
blockhashes expire
commitment levels matter
RPC polling is essential for good UX

This changed how I think about blockchain applications.

⸻

The Biggest Difference From Web2

The biggest mindset shift for me was this:

In web2:

servers own state

In Solana:

the network owns state

Your application becomes more like:

a transaction builder
a signing interface
a state interpreter

instead of a traditional CRUD backend.

That changes everything.

⸻

Final Thoughts

A week ago, Solana transactions looked intimidating.

Now they feel surprisingly elegant.

Once I stopped trying to force blockchain into traditional web2 mental models, the architecture started making sense:

atomic state changes
cryptographic authorization
distributed consensus
deterministic execution

I still have a lot to learn, but building and debugging real transactions helped far more than just reading documentation.

If you’re a backend developer exploring Solana for the first time:
my biggest recommendation is simple:

build small tools yourself.

That is when the concepts really start to click.

Solana #Blockchain #Web3 #100DaysOfSolana

Week 2 of #100DaysOfSolana: When “Public Database” Finally Clicked

LittleNezhaMin — Sat, 02 May 2026 14:09:07 +0000

After two weeks building on Solana, I feel like my mental model of “blockchain” has completely changed.

Before this, I used to think blockchain data was something abstract, complex, and hard to access. Something like a black box where transactions go in, and magic comes out.

Reality?
It’s surprisingly simple… and surprisingly different.
🧱 What I Expected vs Reality
Coming from a fullstack background (PHP, Go, APIs, databases), I expected:

Tables
Queries (SELECT, JOIN, WHERE)
Structured schemas

But on Solana, there are no tables.

Instead:

Accounts = your data
Programs = your logic
RPC = your API

At first, this felt strange.

But once I reframed it like this:

Solana = a giant public database you can read from

Things started to make sense.

⸻

⚡ The Moment It Clicked

The biggest “aha” moment came when I fetched:

Balance of an address
Recent transactions

Using just an RPC call.
No authentication.
No backend.
No database setup.
Just:

const balance = await rpc.getBalance(address).send();

That’s it.
At that moment, it clicked:
This is just a read-only API… but global and trustless.
🧩 What Surprised Me Most

Same Code, Different Network = Completely Different Data

When I compared devnet vs mainnet, I got:

Devnet → 5 SOL + transactions (from testing)
Mainnet → 0 SOL + no activity

Same address. Same code.

Completely different reality.

This felt exactly like:

Devnet = staging DB
Mainnet = production DB

But with real money involved.

Everything is Public

In Web2:

You need auth
You need permission
You need APIs

In Solana:

You can read anything
Anytime
From anywhere

That’s powerful… and a bit scary 😅

RPC Feels Like an API, But It’s Not Quite the Same

Working with Solana RPC feels familiar:

Request → Response
JSON data
Async calls

But the mindset is different:

You’re not querying your backend
You’re querying a shared global state

That changes how you think about data completely.
🚧 What I’m Still Confused About

A few things I’m still figuring out:

How to write data safely (transactions, signing, fees)
How programs (smart contracts) actually store structured data
Best practices for building real apps on top of accounts

Reading data feels easy.

Writing data feels like the next big challenge.
🚀 What I Want to Learn Next

Next, I want to focus on:

Sending transactions
Interacting with programs
Building a real dApp with a wallet (Phantom, etc.)
Moving from “read-only” → “read + write”

⸻

Final Thoughts

Week 2 made one thing clear:

Blockchain isn’t magic.
It’s just a different way of structuring and accessing data.

And once that clicks…

Everything becomes a lot more approachable.

⸻

If you’re also doing #100DaysOfSolana, I’d love to connect and see what you’re building 🚀

Week 2 of #100DaysOfSolana: When “Public Database” Finally Clicked After two weeks building on Solana, I feel like my mental model of “blockchain” has completely changed. Before this, I used to think blockchain data was something abstract, complex, and h

LittleNezhaMin — Sat, 02 May 2026 13:59:49 +0000