DEV Community: Gopichand

Three Token-2022 Mints in One Week: Fees, Yield, and Soul-Bound

Gopichand — Fri, 12 Jun 2026 09:10:31 +0000

If you have built middleware in Web2, you already understand Token-2022 extensions.
The old SPL token program is like a plain Express router. Token-2022 is the same
router with a plugin system baked in. You opt a single mint into behaviors — fees,
interest, transfer locks — at creation time, and the protocol enforces them forever.
No forking, no custom Rust, no deploying your own program. Just flags.

I spent Days 50–54 of my #100DaysOfSolana challenge shipping three mints that each
demonstrate one of those behaviors. Here is what I built, the exact commands I ran,
and when you would actually reach for each extension.

Mint 1 — Transfer Fee (Days 50 & 51)

Mint: HxDYFvcXnLuy4VdxXCooUXrch8DZW34oUteQ6N2EFxEr
Explorer: View on Devnet
Extension: TransferFeeConfig

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

--transfer-fee-basis-points 100 means 1% of every transfer is withheld before
the recipient gets credited. The withheld amount sits in the recipient's token
account until a privileged instruction sweeps it to the treasury.

When would you use this?
Creator royalties on a community token. A protocol fee on a stablecoin. A DAO
treasury skim that funds development every time the token changes hands. The key
insight: the fee is enforced by the Token-2022 program itself, not by your API.
Nobody can route around it by calling the program directly.

On Day 51 I ran the full lifecycle — transfer, inspect the withheld amount, then
sweep it back:

spl-token transfer $MINT 1000 $RECIPIENT --expected-fee 10
spl-token withdraw-withheld-tokens $MY_TA $RECIPIENT_TA

The --expected-fee 10 flag is a safety assertion. If the mint's fee math
doesn't produce exactly 10 tokens withheld, the instruction aborts. It is the
on-chain equivalent of an idempotency check.

Mint 2 — Transfer Fee + Interest Stacked (Day 52)

Mint: A6TAeNgxBVwYna8NqQVmBpQzjVYKoZA3e68yMvoVVUva
Explorer: View on Devnet
Extensions: TransferFeeConfig + InterestBearingConfig

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

One command, two TLV entries, two completely different mechanics.

What the interest extension does — and does NOT do:

This is the subtlety most tutorials skip. The InterestBearingConfig extension
does not mint new tokens. The raw amount stored on-chain never changes between
transactions. What changes is the UI amount — the number your wallet displays.

The formula is: UI amount = raw_amount × e^(rate × time_elapsed)

The network clock and the rate stored on the mint are all the CLI needs to compute
a growing display number every time you query. I proved this by reading the balance
twice with a 30-second sleep between them, with zero transactions in between:

spl-token accounts $MINT --verbose | awk 'NR==3'
sleep 30
spl-token accounts $MINT --verbose | awk 'NR==3'
# Output:
# 999032.271358
# 999032.762062   ← +0.49 tokens, no transaction fired

Think of it like a savings account display ticker. The number on screen grows.
The ledger entry does not change until a real transaction touches it.

Two extensions, zero conflict: TransferFeeConfig operates on raw amounts at
transfer time. InterestBearingConfig operates on the display layer at query time.
They are orthogonal, which is why they compose cleanly on a single mint.

Mint 3 — Non-Transferable / Soul-Bound (Day 54)

Mint: BQzJeZVZgkSvAYPj9f1M1apv56P7kggAgPNc9uSq7T5m
Explorer: View on Devnet
Extension: Non-transferable

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

I minted one badge token to myself, then deliberately tried to send it to a throwaway wallet. Here is the exact runtime rejection:
Program log: Instruction: TransferChecked
Program log: Transfer is disabled for this mint
Program TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb failed: custom program error: 0x25

Error 0x25 is decimal 37, the NonTransferable entry in the Token-2022 error
enum. The rejection came from the validator, not from the CLI or the RPC layer.
There is no way to call the program "around" the extension. The rule lives on the
asset.

spl-token display $MINT
# Extensions
#   Non-transferable

When would you use this?
Completion certificates. Event attendance proofs. KYC credentials tied to a
specific wallet. Anything where the point is that the credential belongs to the
holder and cannot be resold or delegated.

In Web2 you would enforce this with a database constraint or an API check. The
risk is that anyone who can reach the database directly can break the rule. On
Solana the rule is in the program. The program is in the validator. There is no
around.

What surprised me

I expected the stacking to be complicated. It wasn't. Two flags at creation time,
two TLV entries in the same byte buffer, and the CLI just prints both in the
Extensions block of spl-token display. The Token-2022 design is genuinely
composable in a way that feels like it was designed by someone who got burned by
non-composable systems before.

The interest extension surprised me most. I came in expecting it to mint tokens.
It doesn't. It's a view function disguised as a balance. Once I understood that,
I stopped thinking of it as a financial primitive and started thinking of it as
a display configuration. That reframe changed how I'd use it in a real product —
probably for a points or loyalty system where the raw backing supply is fixed but
the displayed "value" grows over time.

If I were building a real product today, I'd reach for TransferFeeConfig for any
token that needs sustainable protocol revenue, and NonTransferable for any
credential or badge that should be identity-bound. The interest extension I'd hold
for a specific display-layer use case where the raw supply needs to stay auditable
but the user-facing number should grow.

All code and terminal output is in my public build log:
👉 https://github.com/gopichandchalla16/100-days-of-solana

Day 55 of #100DaysOfSolana

Solana NFTs Without Metaplex: What I Learned Building with Token Extensions published: true

Gopichand — Tue, 09 Jun 2026 05:22:24 +0000

Before this week I thought you needed Metaplex to build a real Solana NFT. It turns out you can mint a full NFT, stamp metadata directly onto it, group it inside a collection, audit every byte, and mutate it live — using only the Token Extensions program and the SPL token CLI. No third-party framework required.

This post covers what I built during Days 44–47 of #100DaysOfSolana, what surprised me coming from a Web2 background, and what I would build next.

The Mental Model: What a Solana NFT Actually Is

Before writing a single command, I had to unlearn something. In Web2, an NFT feels like a record in a database that points to a JPEG. On Solana, it is simpler and more precise than that.

A Solana NFT is just a mint account with three properties set just right:

Property	Value
Supply	1 (exactly one token exists)
Decimals	0 (cannot be split)
Mint authority	(not set) — disabled forever

That is it. The "NFT-ness" is not a special program. It is a configuration of the same SPL Token primitives that power every fungible token on the network.

What makes a modern Solana NFT different from a bare 1-of-1 token is the Token Extensions program (Token-2022). Instead of storing metadata in a separate account managed by Metaplex, Token Extensions lets you stamp the name, symbol, URI, and custom fields directly onto the mint account itself. Everything lives in one place. Any wallet, any marketplace, any RPC node can read it without trusting a third-party indexer.

What I Built: Four Days, Four Commands

Day 44 — First NFT with on-chain metadata

I minted a 1-of-1 token using the Token-2022 program, initialized a Metadata Pointer extension on it, and attached a name, symbol, and URI pointing to a JSON file on GitHub Gist.

# Create the mint with metadata extension enabled
spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --enable-metadata \
  --decimals 0 \
  ./nftTnVuyNU1kwTgv7edG6BPmHCtp2NMrawbw94kwZTF.json

# Stamp name, symbol, and URI directly onto the mint
spl-token initialize-metadata \
  nftTnVuyNU1kwTgv7edG6BPmHCtp2NMrawbw94kwZTF \
  "First Light" \
  "LIGHT" \
  "https://gist.githubusercontent.com/gopichandchalla16/..."

Mint address: nftTnVuyNU1kwTgv7edG6BPmHCtp2NMrawbw94kwZTF
View on Solana Explorer (devnet)

Day 45 — NFT collection using Group and Member extensions

I created a separate collection mint using the Group extension, then minted two member NFTs and registered each one under the collection using the Member extension.

# Register a member NFT into the collection
spl-token group-member-initialize \
  <MEMBER_MINT> \
  <COLLECTION_MINT> \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

The collection mint ended up with Size: 2, Max Size: 3. Each member NFT carries a Group field that points byte-for-byte to the collection mint — the on-chain equivalent of a foreign key.

Day 46 — Auditing every byte on devnet

Instead of trusting that everything worked, I read both mints back from devnet the same way a senior engineer reviews their own work before shipping.

spl-token display nftTnVuyNU1kwTgv7edG6BPmHCtp2NMrawbw94kwZTF
spl-token display AC3peC3tdZUnLY44zGYC7YAuEaPknkMcRqsmAyvXJtMx

The key check was this line inside Token Group Member on each member NFT:
Group: AC3peC3tdZUnLY44zGYC7YAuEaPknkMcRqsmAyvXJtMx ✅

That address matches the collection mint exactly. Phantom and every marketplace reads this field to verify collection membership — without trusting any off-chain index. That is what "verifiable provenance" actually means. Not marketing. Just two byte arrays comparing equal.

Day 47 — Mutating metadata live

This was the day I stopped treating the NFT like a fragile artifact and started treating it like a live row of data.

# Rename it
spl-token update-metadata nftTnVuy... name "Field Notes"

# Add a custom field — the schema is completely open
spl-token update-metadata nftTnVuy... rarity legendary

# Remove it
spl-token update-metadata nftTnVuy... rarity --remove

# Swap the URI to point at a new metadata JSON
spl-token update-metadata nftTnVuy... uri https://gist.githubusercontent.com/janvinsha/...

Every command was one transaction. Every change appeared in Explorer within seconds.

The Surprising Part

Three things hit differently than I expected coming from Web2.

1. The on-chain layer and the off-chain layer move at different speeds.

When I renamed the NFT to "Field Notes", Explorer showed the new name in seconds. But the image — which lives at the URI I pointed at, hosted on GitHub Gist — stayed cached in wallets for much longer. The on-chain pointer updates instantly. The thing it points at does not. This is why serious NFT projects use Arweave or IPFS for permanent image hosting instead of a mutable HTTP server.

2. There is no separate NFT program.

I kept waiting to discover the "real" NFT layer. There is none. The same Token-2022 program that handles transfer fees, interest-bearing tokens, and compliance controls is also the program that handles NFT metadata and collections. Extensions compose on the same primitives.

3. The metadata schema is a blank canvas.

The additional_metadata array accepts any key-value pair you want. I stamped rarity: legendary onto a live mint in one CLI call and watched it appear on Explorer. No migrations. No schema definitions. No contract upgrades. Just one transaction.

What I Would Build Next

Permanent image hosting — move the image URI from GitHub Gist to Arweave so the pointer and the asset are both permanent
Dynamic NFT — use the mutable metadata to track something that changes over time, like XP or level in a game (Solana's official Dynamic Metadata NFT guide covers this pattern)
Metaplex comparison — Metaplex Core is the dominant alternative NFT standard on Solana, with a different account structure and royalty model. I want to build the same collection in both standards and write a direct comparison.

Resources I Actually Used

Token Extensions overview — the canonical reference
Metadata Pointer and Token Metadata — how metadata lives on the mint
Token Groups and Members — how collection membership works
Dynamic Metadata NFTs guide — the official Solana guide for what comes next
Solana Explorer (devnet) — for verifying every change live

All the code and terminal output from every day is in my public repo:
👉 github.com/gopichandchalla16/100-days-of-solana

This post is part of #100DaysOfSolana. Follow along or jump in any day at mlh.link/solana-100.

44 Days of Solana: From an Empty README to a Live NFT on-chain — My Finish-Up-A-Thon Story

Gopichand — Thu, 04 Jun 2026 05:55:51 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Honestly, I almost didn't write this post.

Not because I didn't have anything to show — but because I kept telling myself
"it's not done yet." Sound familiar?

Back in early 2026, I started a repo called
100 Days of Solana.
The idea was simple: learn Solana development from absolute zero, build
something on-chain every single day, and document it publicly.

Day 1, I generated a keypair. That was it. One file in the repo —
a README with a title and no code. I had no blockchain background,
only a Web2 history in Python and JavaScript. I didn't even know
what "rent" meant in the context of Solana accounts.

But I kept showing up. 44 days later, here's what that same repo became:

✅ Wallets, airdrops, SOL transfers, SPL token creation
✅ Token-2022 extensions — transfer fees, interest-bearing tokens, default frozen, non-transferable (soulbound), permanent delegate
✅ A fully named, on-chain NFT — "First Light" — with metadata, image, and permanently locked supply. Minted using only the Solana CLI. No Metaplex. No framework.
✅ 9 published DEV.to articles translating every concept into Web2-friendly language
✅ Every single transaction signature linked to Solana Explorer so you can verify my work on-chain

This project means more to me than any side project I've ever started.
It's proof that 30 minutes a day, compounded over 44 days,
produces something real and verifiable.

And GitHub Copilot is a big reason I didn't quit on Day 8, Day 23, or Day 39.

🔗 Repo: https://github.com/gopichandchalla16/100-days-of-solana

Demo

🌐 "First Light" — My First NFT, Live on Solana Devnet

I built this NFT end-to-end using nothing but spl-token CLI commands.
No framework. No JS. Just me, the terminal, and a lot of patience.

Field	Value
Name	First Light
Symbol	LIGHT
Mint Address	`nftTnVuyNU1kwTgv7edG6BPmHCtp2NMrawbw94kwZTF`
Program	Token-2022
Supply	1 (locked forever)
Decimals	0
Extensions	`metadataPointer` + `tokenMetadata`
Mint Authority	Disabled 🔒

🔗 View "First Light" on Solana Explorer

The vanity keypair starting with nft took about 20 minutes to generate
locally using solana-keygen grind. Every character you see in that address
was intentional.

📋 Every Step — Verified On-Chain

Here are all 5 transactions, in order. You can click any of them and
see exactly what happened on the Solana blockchain:

Step	What I Did	Verified Transaction
1	Created mint account, initialized metadata pointer, initialized mint	3iXwa…jzXtz
2	Initialized token metadata — name, symbol, URI	45PYG…Kv2D4
3	Created the associated token account	gWLGo…Ymmgj
4	Minted exactly 1 token	3B8MS…wrQoP
5	Revoked mint authority — forever	3Yhop…kckqo

No one can ever mint another LIGHT token. That is by design.

📰 9 Published DEV.to Articles (300+ total reactions)

These are not just summaries of what I did. Each one is a full
explanation written specifically for Web2 developers entering the
Solana ecosystem:

📊 Where the Project Stands

Metric	Status
🟣 Daily Build Progress	44 / 100 Days Complete
🖤 DEV.to Articles	9 Published
🟢 On-Chain Transactions	Live on Solana Devnet
📄 License	MIT
🔒 NFT Mint Authority	Disabled Forever

The Comeback Story

Let me be honest about where this project started and where it almost ended.

Day 1 — What the repo actually looked like

gopichandchalla16/100-days-of-solana
└── README.md ← literally just a title

That was it. I had written "100 Days of Solana — learning in public"
and committed it at midnight. No code. No plan. Just a title and the
pressure of having put it on GitHub.

The first week was rough. The Solana docs are not beginner-friendly
if you're coming from Web2. The Token-2022 documentation is especially
sparse. I spent 3 hours on Day 4 just trying to understand why my
airdrop wasn't showing up (I was checking the wrong cluster).

There were three moments where I almost stopped entirely:

Day 8 — I couldn't figure out why my token transfer kept failing
with a cryptic 0x1 error. I had been at it for two hours and it was
past midnight. I nearly closed the laptop and told myself I'd "come back to it."

Day 23 — I hit a wall with Token-2022 extension architecture.
I understood how individual extensions worked but not how to compose
them safely. Nothing I read explained it in plain terms.

Day 39 — The NFT build broke on step 2 of 5. My metadata wasn't
being initialized because I ran initialize-mint before
initialize-metadata-pointer. The error wasn't obvious.
I almost started over from scratch.

I didn't quit any of those nights. GitHub Copilot helped me through
each one — and I'll explain exactly how in the Copilot section.

Day 44 — What the repo became

gopichandchalla16/100-days-of-solana
├── day-01/ through day-44/ ← 44 documented daily builds
├── 9 DEV.to articles published
├── Every tx signature verified on Solana Explorer
├── Token-2022 extensions built and tested:
│ ├── Transfer fees (compliance use case)
│ ├── Interest-bearing tokens (DeFi use case)
│ ├── Default frozen + thaw (regulated assets)
│ ├── Non-transferable / soulbound (credentials)
│ └── Permanent delegate (revocable access)
├── NFT "First Light" — vanity keypair, Token-2022,
│ on-chain metadata, locked supply
└── README with live progress bar, week logs,
all explorer links

The difference between Day 1 and Day 44 is not just the code.
It's the understanding behind it.

The 3 moments that defined this project

Day 13 — The account model finally made sense.

I had been running solana balance and spl-token create-account for
days without really understanding why Solana accounts need rent.
Then I sat down and wrote a DEV.to article explaining it with a
Web2 analogy: accounts are like database rows, rent is like a monthly
hosting fee — stop paying and the row gets deleted.

Writing that article forced me to understand it deeply enough to
explain it simply. After Day 13, I stopped copying commands and started
understanding what each one actually does.

Days 36–40 — Five Token-2022 extension combinations in one week.

This was the hardest week. I built:

A transfer fee token (simulating a transaction tax)
An interest-bearing token (simulating a yield-bearing asset)
A default-frozen token with thaw authority (compliance gating)
A non-transferable soulbound token (on-chain credential)
A permanent delegate token (revocable programmatic access)

Each one is a real devnet transaction. Each one has a verifiable
signature on Solana Explorer. Each one taught me something different
about how Token-2022 is designed to handle real-world financial
and compliance scenarios.

Days 43–44 — My first NFT. No Metaplex. Just the CLI.

I wanted to understand NFTs at the protocol level — not through
a framework, not through a library, but through raw spl-token commands.

I generated a vanity keypair starting with nft using solana-keygen grind.
I added two Token-2022 extensions: metadataPointer and tokenMetadata.
I minted exactly 1 token. I disabled the mint authority forever.

"First Light" now lives on-chain permanently with its name, symbol,
and metadata URI intact. Nobody can create another one. That's what makes it an NFT.

The biggest technical lesson of 44 days

Token-2022 extensions cannot be added after mint creation. Ever.

There's no workaround. No patch. No update instruction.
You must decide your full extension set before you run
initialize-mint. It's like designing a database schema —
you can't add a non-nullable column without a migration.

I learned this the hard way on Day 38 when I tried to add
interest-bearing to an existing mint. The transaction failed
and I had to start the token from scratch. That 30-minute mistake
became the most important architectural lesson I've had in 44 days.

My Experience with GitHub Copilot

I want to be specific here, not just say "Copilot helped a lot."
Here are the exact moments where it made the difference.

When I was stuck on `0x11` at midnight (Day 37)

My compliance-gated token transfer failed with error 0x11 —
AccountFrozen. I knew the token was frozen by design but I thought
I had thawed it. The transaction kept failing anyway.

I was staring at the error in my terminal. Copilot's inline suggestion
explained what I was missing: both the sender's ATA and the
recipient's ATA need to be thawed — not just the sender's.
One suggestion. One minute. Problem solved.

Without Copilot, I would have been digging through the SPL Token
source code for the next hour — or worse, I would have given up
and moved on without truly understanding the error.

When soulbound tokens confused me (Day 40)

Non-transferable tokens are conceptually simple — once minted to a
wallet, they can never move. But when I tried to demonstrate this
by attempting a transfer, the transaction failed with 0x25.

I didn't expect the error. Copilot explained: non-transferable tokens
can be burned but not transferred. It then suggested I write a burn
script to demonstrate the constraint properly — which turned into
the best hands-on example in my Week 6 article.

The bug became the feature. That happens a lot when Copilot is involved.

Writing CLI commands faster and correctly

The Token-2022 program ID is 44 characters long:
TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

Before Copilot, I copied this from docs and sometimes mis-pasted it.
With Copilot, it autocompleted the entire ID, the --program-id flag,
all the relevant options, and even the correct sequence of commands.

The sequence matters enormously in Token-2022. For the NFT build,
initialize-metadata-pointer must come before initialize-mint.
The Solana docs don't emphasize this clearly for beginners.
Copilot's autocomplete surfaced the correct order naturally,
in context, while I was typing. That saved me from the exact error
that had broken my build on Day 39.

Turning raw terminal output into readable articles

Every DEV.to article I wrote started the same way:
a terminal window full of transaction signatures, error codes,
and hex-encoded account data.

Copilot helped me turn that raw output into:

Clear Web2 analogies that explain Solana concepts without jargon
A consistent structure: what I planned → what broke → what I learned
Opening paragraphs that hook readers who have never touched blockchain

Nine articles. 300+ reactions across all of them.
That audience engagement would not exist without Copilot helping me
bridge the gap between "developer notes" and "readable article."

Explaining the "why" — not just the "how"

This is the thing I appreciate most about Copilot, and it's hard to
quantify. When a command worked, I often didn't fully understand why
it worked. Copilot's inline comments filled those gaps constantly:

"This flag enables close authority so you can reclaim rent later."
"The metadata pointer must be initialized first because the mint instruction reads the extension list."
"Revoking mint authority is a one-way operation — there's no re-enable instruction in Token-2022."

These micro-explanations compounded over 44 days into real,
deep understanding of the protocol. I'm not just writing Solana
commands anymore. I understand what they do and why they exist.

The honest summary

GitHub Copilot didn't write this project for me.
Every transaction on Solana Explorer is a decision I made,
a command I typed, a concept I understood.

But Copilot removed the friction that would have made me quit.
It turned 2-hour debugging sessions into 10-minute ones.
It turned terminal output into articles people actually read.
It turned "I don't understand this" into "oh, that's why."

44 days in. 56 to go. I'm not stopping.

🔗 GitHub Repo: https://github.com/gopichandchalla16/100-days-of-solana

📰 DEV Profile: https://dev.to/gopichand_dev

🐦 X / Twitter: https://x.com/GopichandAI

If you're a Web2 developer curious about Solana — follow the repo.
Every day folder has the exact commands I ran, the errors I hit,
and what I learned. It's all there.

#100DaysOfSolana #Solana #Web3 #BuildInPublic

I Built 5 Token Extension Combinations on Solana This Week — Here's What Each One Does

Gopichand — Tue, 02 Jun 2026 06:04:10 +0000

If you have ever used a brokerage account, you already understand token extensions.

Your brokerage locks your account until you verify your identity. A stock you own cannot be
transferred to someone else without compliance checks on both sides. A professional license
is tied to you — the issuing body can revoke it, but you cannot sell it. An interest-bearing
savings account accrues value over time without you doing anything.

All of these are real-world rules applied to value. Token-2022 extensions let you encode
those same rules directly into a Solana token mint — at the protocol level, not the
application layer. No backend. No database. No API that can go down.

Over the past several days I built five different token configurations as part of my
100 Days of Solana challenge.
Here is what I learned.

What Are Token Extensions?

Token-2022 is Solana's upgraded token program
(TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb).
It is backwards-compatible with the original SPL Token program, but it lets you attach
extensions to a mint at creation time.

Extensions are stored as TLV (type-length-value) blobs in the mint account's data.
Each extension adds bytes, and those bytes cost rent. More extensions = bigger account =
more SOL locked at creation. That is the core tradeoff to understand before you design
a token.

Extension 1 — Interest-Bearing Tokens

The Web2 analogy: A savings account that accrues interest over time.

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --interest-rate 500

This sets an initial rate of 500 basis points (5%). The rate can be updated later by
the rate authority:

spl-token set-interest-rate <MINT_ADDRESS> 15000

What surprised me: The extension does NOT mint new tokens. It is purely a
calculation layer. Wallets and apps read the rate and elapsed time to display an
adjusted "UI balance." The raw on-chain balance stays the same. When you run
spl-token display, you see both:
Current rate: 15000bps
Average rate: 500bps ← historical average is preserved

Use cases: Yield-bearing stablecoins, loyalty points that grow over time,
reward tokens for long-term holders.

Extension 2 — Transfer Fees

The Web2 analogy: A payment processor that takes a cut of every transaction.

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --transfer-fee 100 50000
# 100 basis points (1%) fee, max 50000 tokens per transfer

Fees are collected at the token account level (withheld in the recipient's account),
not sent automatically. The withdrawal authority must harvest them:

spl-token withdraw-withheld-tokens <DESTINATION> --include-mints <MINT>

What surprised me: The fee is enforced by the Token-2022 program itself on every
TransferChecked instruction. No smart contract needed. No way to bypass it from
the frontend.

Use cases: Protocol revenue, DAO treasury funding, creator royalties on every transfer.

Extension 3 — Default Account State (Frozen)

The Web2 analogy: A brokerage that freezes every new account until KYC passes.

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --enable-freeze \
  --default-account-state frozen

Every token account created for this mint starts in a frozen state. Nobody can
receive, send, or burn tokens until the freeze authority explicitly thaws them:

spl-token thaw <TOKEN_ACCOUNT_ADDRESS>

The key insight I learned the hard way: It is not enough for the sender to be
thawed. The recipient must also be thawed. Both sides need to pass the compliance check.

When I tried to transfer from a thawed account to a still-frozen one: Program log: Error: Account is frozen (custom program error: 0x11)

Use cases: Regulated security tokens, KYC-gated stablecoins, permissioned loyalty
programs.

Extension 4 — Non-Transferable (Soulbound)

The Web2 analogy: A professional certification that belongs to you — you cannot sell it.

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --enable-non-transferable \
  --decimals 0

--decimals 0 because credentials are whole units. You either have the credential or
you don't.

Any transfer attempt fails immediately: Program log: Transfer is disabled for this mint (custom program error: 0x25)

0x25 = decimal 37 = NonTransferableError in the Token-2022 source.

Use cases: DAO membership badges, hackathon completion certificates,
verified contributor status, employee access tokens.

Extension 5 — Permanent Delegate (Revocable)

The Web2 analogy: Your employer can revoke your access badge at any time, without
asking you.

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --enable-permanent-delegate \
  --enable-non-transferable \
  --enable-metadata \
  --decimals 0

Combining --enable-non-transferable with --enable-permanent-delegate creates a
revocable soulbound token: the holder cannot move it, but the issuer can burn it
from any account without the holder's signature.

# Revoke the credential — no holder signature needed
spl-token burn <RECIPIENT_TOKEN_ACCOUNT> 1 \
  --owner ~/.config/solana/id.json \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

What surprised me: The Solana runtime logs a warning whenever a token account is
created for a mint with a permanent delegate:
Warning: Mint has a permanent delegate,
so tokens in this account may be seized at any time

Full transparency baked in at the protocol level. The holder is informed at account
creation — not buried in a ToS.

The Cost of Extensions

Each extension adds bytes to the mint account. More bytes = more rent-exempt SOL:

Configuration	Data Size	Rent
Default frozen only	171 bytes	~0.0021 SOL
Interest-bearing only	222 bytes	~0.0024 SOL
Transfer fees + Interest + Metadata	599 bytes	~0.0051 SOL

Metadata is the biggest cost driver because it stores variable-length strings
(name, symbol, URI) directly inside the mint account. Every character costs rent.

What Cannot Be Changed After Creation

This is the part that matters most before mainnet deployment:

Extensions cannot be added after mint creation. The account is allocated with exactly the space for the declared extensions. You must plan upfront.
The permanent delegate cannot be removed once set (only transferred to a different address if the current delegate signs).
Non-transferable is permanent. Once set, no authority can enable transfers.

Think of it like a database schema. Define it before you insert the first row.

Inspecting Any Token Extension Config

spl-token display <MINT_ADDRESS> \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

This single command decodes every extension in the mint account and prints it in
human-readable form. I now run this before touching any Token-2022 mint I didn't
create myself.

Where to Go Next

Token Extensions official docs — the canonical reference, well-maintained
Token-2022 Extensions Guide — deeper per-extension implementation notes
My full 100 Days of Solana repo — every command I ran, every error I hit, documented day by day

The best way to learn these is to run the CLI commands yourself on devnet. Each failure
message tells you exactly what rule was violated and which error code fired. That feedback
loop is faster than any tutorial.

This post is part of my #100DaysOfSolana challenge — building and documenting in public
every day. Follow along on X @GopichandAI or
GitHub.

Transfer Fees, Metadata, and Soulbound Tokens: A Tour of Solana Token Extensions

Gopichand — Sun, 24 May 2026 17:05:43 +0000

I spent the last five days building tokens on Solana — and it completely
changed how I think about what a "token" actually is.

Coming from Web2 and EVM development, I assumed a token was a number in a
database with some transfer logic wrapped around it. On Solana, it's much
closer to a configurable protocol object. Here's everything I learned across
Days 29–33 of my #100DaysOfSolana challenge.

The Starting Point: Two Token Programs

Solana has two token programs:

SPL Token (original) — simple, battle-tested, does the basics
Token Extensions Program (Token-2022) — everything the original does, plus built-in extensions for fees, metadata, soulbound tokens, and more

I used Token-2022 for almost everything this week because it lets you attach
behavior directly to the mint — no separate smart contract needed.

Day 29 — Creating My First SPL Token

The first thing that surprised me: a token on Solana is two separate accounts.

Mint account — holds the token's configuration (supply, decimals, mint authority)
Token account — holds a specific wallet's balance of that token

spl-token create-token --decimals 9
spl-token create-account <MINT_ADDRESS>
spl-token mint <MINT_ADDRESS> 1000

In Web2, this would be one database table with a balance column. On Solana,
the separation means the mint config is completely independent of who holds
what — any wallet can hold any token as long as they have a token account for it.

Day 30 — Token-2022 with On-Chain Metadata

The original SPL token has no name or symbol stored on-chain. You need an
external metadata program (Metaplex) to give it an identity. Token-2022
changes this with the metadata extension — name, symbol, and URI live
directly inside the mint account.

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --enable-metadata \
  --decimals 9

spl-token initialize-metadata <MINT_ADDRESS> \
  "GopichandToken" "GOPI" \
  "https://your-metadata-uri.json"

Run spl-token display <MINT_ADDRESS> and you'll see the name and symbol
sitting right there in the mint account output. No external call. No
separate metadata program. The token is the metadata.

Day 31 — Transfer Fees at the Protocol Level

This is where it got interesting. I attached a 1% transfer fee to a
token mint — meaning every transfer automatically withholds 1% in the
recipient's token account, uncollectable by the recipient, waiting for the
mint authority to withdraw.

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --transfer-fee-basis-points 100 \
  --transfer-fee-maximum-fee 5000 \
  --decimals 9

After transferring 100 tokens, the recipient got 99. The 1 withheld token
sat locked in their account until I ran:

spl-token withdraw-withheld-tokens \
  <MY_TOKEN_ACCOUNT> \
  <RECIPIENT_TOKEN_ACCOUNT>

In Web2, building a platform fee on transfers requires intercepting every
transaction in your backend. On Solana, it's a flag on the mint. The
program enforces it — not your server.

Day 32 — The Full Lifecycle in One Sitting

Day 32 was a consolidation day. No new concepts — just proving I could
build the complete token lifecycle from scratch without checking notes:

Create Token-2022 mint with metadata + 2% transfer fee
Initialize metadata (name: ReinforceCoin, symbol: RFC)
Create token account and mint 1000 RFC
Transfer 100 to a second wallet → recipient gets 98, 2 withheld
Withdraw withheld fees → balance becomes 902 Mint: 6YnDTE8cETtvKyesVM9frSeWCfpQUx757qcCQyHaBe9T Final balance: 902 RFC ✅

The "aha" moment: I realized the pattern is always the same regardless of
which extensions you use. Create → configure → mint → transfer →
collect. The specifics change. The lifecycle doesn't.

Day 33 — Soulbound Tokens

The most conceptually interesting day. I created a non-transferable
token — a token that is permanently locked to the wallet it's minted into.

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --enable-non-transferable

I minted 10 tokens, then tried to transfer 5 to a second wallet. The
program rejected it instantly:
Program log: Transfer is disabled for this mint
custom program error: 0x25

That error code 0x25 (decimal 37) is NonTransferable — a first-class
error in the Token Extensions Program. This isn't application logic that
a clever script could bypass. The program itself rejects the instruction.

What's interesting is that burning still works. The owner can destroy
tokens they hold. They just can't send them. After burning 3, my balance
dropped from 10 to 7 — exactly as expected.

Real-world uses for non-transferable tokens:

Course completion certificates
KYC / identity verification
Hackathon participation badges
Employee credentials
On-chain reputation scores

In Web2, preventing credential trading means writing application rules that
can be worked around. On Solana, the restriction is part of the asset itself.

What Surprised Me

The separation of mint and token accounts took longer to internalize than
I expected. I kept confusing "the mint address" with "my token account."
They're different accounts with different purposes. The mint is the factory.
The token account is the warehouse.

The error messages are actually readable. Transfer is disabled for this mint is exactly what it sounds like. Coming from debugging opaque
EVM reverts, this felt refreshingly honest.

Extensions compose. You can combine metadata + transfer fees in a
single mint creation command. Day 32 showed me that Token-2022 isn't a
collection of separate features — it's a composable system.

What's Next

I'm on Day 33 of 100. Next up: deeper into Token-2022 extensions
(interest-bearing tokens, confidential transfers), then moving into
Anchor and on-chain programs.

I'm building toward AI agents that can own wallets and execute Solana
transactions autonomously — and understanding the token layer deeply is
a prerequisite for that.

If you're following along, my full build log is at:
👉 github.com/gopichandchalla16/100-days-of-solana

Day 34 of #100DaysOfSolana — writing in public, building in public.

Week 5 on Solana: Everything I Learned About Tokens (Days 29–31)

Gopichand — Thu, 21 May 2026 05:07:38 +0000

Five weeks into my #100DaysOfSolana challenge and I just crossed into
the most exciting territory yet — Solana's token layer. This week I went
from zero token knowledge to creating, branding, minting, distributing,
and even charging fees on tokens — all on-chain. Here's everything I learned.

What "Tokens" Actually Means on Solana

Before this week, I thought tokens were complicated. Smart contracts,
deployment scripts, audits — the whole Web3 horror story.

Turns out, Solana has a completely different model. The SPL Token Program
is a single shared, audited program already deployed on-chain. Every token
on Solana — from USDC to memecoins to your own project token — is created
using the same program. You never write token logic. You just call it.

This is the Web2 equivalent of using Stripe instead of building your own
payment processor. The infrastructure is already there.

Day 29: My First Token — Raw and Nameless

On Day 29, I ran one command:

spl-token create-token

A token appeared on-chain. Supply: 0. Decimals: 9. Mint authority: me.

Then I minted 100 tokens into a token account:

spl-token create-account MINT_ADDRESS
spl-token mint MINT_ADDRESS 100
spl-token display MINT_ADDRESS

Output: SPL Token Mint
Address: 2M6t3SbJMz95mZ8nzF8MLq364v2ZQQ235BkxhE93g7hq
Supply: 100000000000
Decimals: 9
Mint authority: AWKYsCGBcfGLSz6QpmXzRn7EJ9fRhiJsjYSLDV3c9L9y
Freeze authority: (not set)

Key insight: Supply shows 100000000000 for 100 tokens because
decimals = 9, so 100 × 10^9. All on-chain math is integer arithmetic —
no floating point, no rounding errors.

One problem: Explorer showed it as "Unknown Token." No name, no symbol.
That sent me to Day 30.

Day 30: Giving My Token an Identity with Token-2022

The fix: switch to Token Extensions Program (Token-2022). This newer
standard embeds metadata — name, symbol, URI — directly inside the mint
account. No separate Metaplex account needed.

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --enable-metadata \
  --decimals 6

spl-token initialize-metadata MINT_ADDRESS \
  "100DaysCoin" "HUNDO" \
  "https://raw.githubusercontent.com/solana-developers/opos-asset/main/assets/DeveloperPortal/metadata.json"

My token now had an identity: 100DaysCoin (HUNDO).

Then I minted 1000 HUNDO and transferred 250 to a second wallet:

spl-token transfer MINT_ADDRESS 250 SECOND_WALLET \
  --fund-recipient --allow-unfunded-recipient

Final: 750 HUNDO (me) / 250 HUNDO (second wallet). The
--fund-recipient flag automatically created the recipient's Associated
Token Account (ATA) and covered rent. One flag replaces what would be
multiple API calls in Web2.

Day 31: Built-in Transfer Fees — No Middleware Required

This was the most mind-bending day. In Web2, charging a per-transaction
fee means building middleware, hooking into payment flows, writing fee
collection jobs. On Solana, it's one flag at mint creation:

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --transfer-fee-basis-points 100 \
  --transfer-fee-maximum-fee 5000

100 basis points = 1% fee. The program enforces it on every transfer —
no middleware, no bypass possible.

spl-token transfer MINT_ADDRESS 100 SECOND_WALLET --expected-fee 1

The --expected-fee flag is a safety check: the transfer fails if the
calculated fee doesn't match what you specify. After the transfer:
My wallet: 900 tokens
Second wallet: 99 tokens ← received 100, 1 withheld as fee

The withheld fee sits locked in the recipient's token account. Only the
withdraw withheld authority (set to my wallet at creation) can collect it:

spl-token withdraw-withheld-tokens MY_TOKEN_ACCOUNT SECOND_WALLET_TOKEN_ACCOUNT

Final result: 901 tokens in my wallet (900 + 1 fee swept back) ✅

The Mental Model That Changed Everything

Web2 Concept	Solana Equivalent
Rewards program definition	Mint account
User balance row in DB	Token Account (ATA)
Display name / branding	On-chain metadata (Token-2022)
Transfer API endpoint	`spl-token transfer`
Payment processor fee	Transfer fee basis points
Fee collection middleware	`withdraw-withheld-tokens`
Admin-only mint permission	Mint authority (cryptographic)

SPL Token vs Token-2022: Quick Reference

Feature	SPL Token	Token-2022
Basic minting & transfers	✅	✅
On-chain metadata	❌	✅
Transfer fees	❌	✅
Interest-bearing tokens	❌	✅
Confidential transfers	❌	✅

For any new token in 2026: Token-2022 is the default.

What's Next

Week 6 goes deeper — more Token Extensions, and eventually building
tokens with real utility. The foundation is solid.

31 days in. 69 to go.

Articles in this series:

→ Day 29: SPL Token Basics

→ Day 30: Token-2022 Branded Token

🔗 GitHub: 100-days-of-solana

Building daily → @GopichandAI | #100DaysOfSolana

How I Created My First Solana Token from Scratch (SPL Token Basics Explained)

Gopichand — Thu, 21 May 2026 04:48:07 +0000

On Day 29 of my #100DaysOfSolana challenge, I created my first-ever token
on Solana's devnet. Not by deploying a smart contract. Not by writing a
single line of code. Just a CLI and 5 commands.

Here's what I learned — and why Solana's token model is fundamentally
different from anything in Web2.

The Web2 Mental Model (and Why It Breaks Here)

In Web2, when you build a rewards or credits system, you:

Create a tokens table in your database
Write API endpoints to create, read, update balances
Handle edge cases like double-spending yourself
Maintain a server to keep it all running

On Solana, none of that exists. The SPL Token Program is a shared,
audited, on-chain program that any developer can use — no custom backend,
no smart contract needed. You just call it.

The Two Key Accounts You Need to Understand

Before touching the CLI, understand this mental model:

Mint Account = the global definition of your token

Stores total supply
Stores decimal precision
Stores who has authority to mint more
One per token type

Token Account = a wallet's individual balance for ONE specific token

Think of your wallet as a filing cabinet
Each token account is a separate folder inside it
One folder per token type you hold

This separation is unusual coming from Web2 — but it's how Solana keeps
its data organized and its runtime blazing fast.

Step-by-Step: Creating My First SPL Token

Prerequisites

solana config set --url devnet
solana address    # confirm your wallet
solana balance    # confirm you have SOL for fees

I had 6.13 SOL on devnet — more than enough. No airdrop needed.

Step 1: Create the token mint

spl-token create-token

Output: Creating token 2M6t3SbJMz95mZ8nzF8MLq364v2ZQQ235BkxhE93g7hq
under program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

Address: 2M6t3SbJMz95mZ8nzF8MLq364v2ZQQ235BkxhE93g7hq
Decimals: 9

This created a Mint account on-chain. Supply is zero. Decimals default
to 9. My wallet is the mint authority — the only one who can create more.

Step 2: Create a token account

spl-token create-account 2M6t3SbJMz95mZ8nzF8MLq364v2ZQQ235BkxhE93g7hq

Output: Creating account B4SSsjUA1fcJmjMhmYis3EpLTSBD9GGo1DBEZAwjae7c

You cannot receive tokens directly into your wallet. You need a
dedicated token account for each token type. This is the "folder in the
filing cabinet."

Step 3: Mint some supply

spl-token mint 2M6t3SbJMz95mZ8nzF8MLq364v2ZQQ235BkxhE93g7hq 100

Output: Minting 100 tokens
Token: 2M6t3SbJMz95mZ8nzF8MLq364v2ZQQ235BkxhE93g7hq
Recipient: B4SSsjUA1fcJmjMhmYis3EpLTSBD9GGo1DBEZAwjae7c

Step 4: Inspect everything

spl-token supply 2M6t3SbJMz95mZ8nzF8MLq364v2ZQQ235BkxhE93g7hq
# → 100

spl-token accounts
# Token                                         Balance
# 2M6t3SbJMz95mZ8nzF8MLq364v2ZQQ235BkxhE93g7hq  100

spl-token display 2M6t3SbJMz95mZ8nzF8MLq364v2ZQQ235BkxhE93g7hq
# SPL Token Mint
#   Address:          2M6t3SbJMz95mZ8nzF8MLq364v2ZQQ235BkxhE93g7hq
#   Program:          TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
#   Supply:           100000000000
#   Decimals:         9
#   Mint authority:   AWKYsCGBcfGLSz6QpmXzRn7EJ9fRhiJsjYSLDV3c9L9y
#   Freeze authority: (not set)

The Decimals Trick

Notice the supply shows 100000000000 even though I minted 100.

That's because decimals = 9, so:
100 tokens × 10^9 = 100,000,000,000 raw units

This is identical to how SOL works with lamports: 1 SOL = 1,000,000,000 lamports

All on-chain arithmetic is integer math — no floating point, no rounding
errors. The CLI handles the conversion for you.

What "Mint Authority" Actually Means

The mint authority field is your wallet address — meaning only you
can call spl-token mint to create more supply.

This is the on-chain equivalent of "only the admin can issue new credits"
in a Web2 system. Except here, it's enforced by cryptography, not by
an if (user.role === 'admin') check in your backend.

You can also permanently disable minting (set supply to fixed) by
running spl-token authorize YOUR_MINT mint --disable. Once done,
it's irreversible.

Freeze Authority: What It Is and Why I Left It Unset

Freeze authority: (not set) means no one can freeze token accounts
holding this token. If freeze authority were set, the authority could
prevent specific wallets from sending or receiving the token — useful
for compliance in real-world asset tokens, but not needed here.

The Big Picture

You just created a digital asset. Not a database row, not an API response
— a real token living on a public blockchain that anyone in the world
can verify right now:

🔗 View on Solana Explorer

Tomorrow (Day 30), I upgraded this with Token-2022 — giving the token
a real name, symbol, and on-chain metadata. The difference is dramatic.

🔗 Full code: GitHub

Building daily → @GopichandAI | #100DaysOfSolana Day 29/100

I Built a Branded Token on Solana in 5 Minutes (No Smart Contract Needed)

Gopichand — Thu, 21 May 2026 04:40:48 +0000

I spent years thinking "creating a token" meant writing complex smart contract
code, deploying it, hoping nothing breaks. Today on Day 30 of my

100DaysOfSolana challenge, I created a fully branded token — with a name,

symbol, and on-chain metadata — in under 5 minutes. No Solidity. No Rust.
Just a CLI.

Here's exactly what I did and what it means.

The Problem with Yesterday's Token

On Day 29, I created my first SPL token on Solana devnet. It worked — but
when I looked it up on Solana Explorer, it showed up as "Unknown Token." Just
a random address with no name, no symbol, no identity.

That's like launching a rewards program for your app but forgetting to give
it a name. Users would see a random ID and have no idea what it represents.

Today I fixed that using Token-2022 — Solana's next-generation token program.

Token-2022 vs the Original SPL Token Program

The original SPL Token Program is solid but basic. To add metadata (name,
symbol, image), you'd traditionally need a separate Metaplex account — an
extra transaction, extra cost, extra complexity.

Token Extensions Program (Token-2022) changes this. It lets you embed
metadata directly inside the mint account itself. One account. Everything
in one place. Fewer transactions, lower cost.

Think of it like this:

Web2 Concept	Solana Equivalent
Reward program definition	Mint account
Display name / branding	On-chain metadata (name, symbol, URI)
User balance record	Associated Token Account (ATA)
Transfer API	`spl-token transfer` instruction

What I Built: 100DaysCoin (HUNDO)

Token name: 100DaysCoin
Symbol: HUNDO
Decimals: 6
Program: Token Extensions (Token-2022)
Mint: 3zX5oyL9skYKWo2ZoUHgBwLpG9BzLe1ViuXLgH8joqFt

Step-by-Step: How I Did It

Step 1: Create the mint with metadata enabled

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --enable-metadata \
  --decimals 6

The --program-id flag tells the CLI to use Token-2022 instead of the
original SPL Token Program. The --enable-metadata flag activates the
metadata extension on the mint.

Output: Creating token 3zX5oyL9skYKWo2ZoUHgBwLpG9BzLe1ViuXLgH8joqFt
Address: 3zX5oyL9skYKWo2ZoUHgBwLpG9BzLe1ViuXLgH8joqFt
Decimals: 6

Step 2: Initialize on-chain metadata

spl-token initialize-metadata \
  3zX5oyL9skYKWo2ZoUHgBwLpG9BzLe1ViuXLgH8joqFt \
  "100DaysCoin" "HUNDO" \
  "https://raw.githubusercontent.com/solana-developers/opos-asset/main/assets/DeveloperPortal/metadata.json"

This writes the token's name, symbol, and a URI directly onto the mint
account. The URI points to a JSON file with extended details — description,
image, attributes. This is now verifiable by anyone on-chain.

Step 3: Create a token account and mint supply

spl-token create-account 3zX5oyL9skYKWo2ZoUHgBwLpG9BzLe1ViuXLgH8joqFt
spl-token mint 3zX5oyL9skYKWo2ZoUHgBwLpG9BzLe1ViuXLgH8joqFt 1000

Balance check: 1000

Step 4: Transfer tokens to a second wallet

solana-keygen new --outfile ~/second-wallet.json --no-bip39-passphrase

spl-token transfer 3zX5oyL9skYKWo2ZoUHgBwLpG9BzLe1ViuXLgH8joqFt 250 \
  $(solana-keygen pubkey ~/second-wallet.json) \
  --fund-recipient --allow-unfunded-recipient

The --fund-recipient flag is key — it automatically creates the recipient's
Associated Token Account (ATA) and covers the rent cost from my wallet. In
Web2 terms, it's like your API automatically creating a user's balance row
before their first transaction.

Final balances

My wallet: 750 HUNDO ✅
Second wallet: 250 HUNDO ✅

The "Aha" Moment

In Web2, building a token/rewards system means:

Database schema for the currency definition
CRUD API endpoints for balance management
Custom transfer logic with double-spend protection
A server running 24/7 to keep it all alive

On Solana with Token-2022:

create-token = currency definition
create-account = user balance row
transfer = transfer API
Zero server. Zero maintenance. Publicly verifiable.

And critically — the metadata lives on-chain. Not in your database. Not
on your server. On a public ledger that anyone can read, forever.

What's Next

Day 31 onward: deeper into token extensions — transfer fees,
interest-bearing tokens, and eventually building tokens with real utility.
The foundation is set.

🔗 Full code + notes: GitHub

🔗 Mint on Explorer: Solana Explorer

Building daily → @GopichandAI | #100DaysOfSolana Day 30/100

Solana's Account Model Explained for Web2 Developers (No Blockchain Experience Needed)

Gopichand — Mon, 18 May 2026 06:57:15 +0000

If you're a Web2 developer looking at Solana for the first time, the account
model will either click immediately or confuse you completely. I was in the
second camp — until I spent 26 days building on Solana daily as part of the
100 Days of Solana challenge.

Here's the explanation I wish I'd had on Day 1.

The Filesystem Analogy

Think of Solana like a filesystem.

Each account is a file. Every file has metadata (owner, permissions, size)
and contents (data). Programs are executable files. Data accounts are the
documents those programs read and write. The System Program is the
operating system kernel that manages file creation and ownership transfers.

That's the whole model. Let's go deeper.

Everything Is an Account

In Ethereum, there are two types of things: externally owned accounts (wallets)
and contract accounts (smart contracts). They behave differently.

Solana has one type: accounts. Everything — your wallet, a smart contract,
a token mint, a clock showing the current time — is an account. They all live
in one flat key-value store where the key is a 32-byte address and the value
is the account itself.

This uniformity is powerful once it clicks.

The Five Fields Every Account Has

Every single Solana account — whether it's your wallet or the System Program
itself — has exactly five fields. Here's what they look like when you inspect
your own wallet with the Solana CLI:

solana account $(solana address)

Public Key: AWKYsCGBcfGLSz6QpmXzRn7EJ9fRhiJsjYSLDV3c9L9y
Balance: 6.137925 SOL
Owner: 11111111111111111111111111111111
Executable: false
Rent Epoch: 18446744073709551615

And in JSON:

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

Let's break each field down:

1. lamports — your SOL balance in the smallest unit. 1 SOL = 1,000,000,000
lamports. My wallet has 6,137,925,000 lamports = 6.137925 SOL. Think of
lamports like wei in Ethereum, or paise in INR — the atomic unit.

2. data — a raw byte array. For a basic wallet, this is empty (0 bytes).
For a token mint, it's 82 bytes of structured data. For a program, it's the
compiled bytecode. This field holds the entire state of the account.

3. owner — the program that controls this account. My wallet is owned by
11111111111111111111111111111111 — the System Program. Only the owner program
can modify the account's data or debit its lamports. Anyone can add lamports,
but only the owner can remove them. This one rule is most of Solana's
security model.

4. executable — a boolean. false for wallets and data accounts. true
for programs. When you call a program, Solana checks this flag first.

5. rent_epoch — deprecated. Ignore it. It's always set to the maximum u64
value (18446744073709551615) for all rent-exempt accounts, which is everything
on mainnet today.

Programs Don't Store Their Own State

This is the part that surprises every Web2 developer.

In Web2, a server typically owns its own database. In Solana, programs are
stateless. A program's executable code lives in one account. Any data it
needs to read or write lives in separate data accounts that are passed in
with each transaction.

Here's the direct comparison:

Web2	Solana
Web server	Program account (executable=true)
Database	Data account (executable=false)
Database row	Individual account's `data` field
HTTP request	Transaction instruction
Request body	Instruction data + account list

Why does this matter? Because it means Solana can process transactions in
parallel. If two transactions touch different accounts, they can run at the
same time. That's a big reason Solana achieves 3,000–4,000 TPS on mainnet.

The Ownership Rules Are Simple But Powerful

Three rules govern everything:

Only the owner program can modify an account's data
Only the owner program can debit lamports from an account
Anyone can credit (send) lamports to any account

That's it. No complex permission system. No role-based access control. Just:
you own it, you control it.

When you send SOL to someone, the System Program (owner of both wallets)
executes the transfer. When a token program moves a token, it's the owner of
the token account doing the write. The ownership chain is always clear.

Rent Exemption

Every account must hold a minimum lamport balance proportional to its data
size to stay on-chain permanently. This is called being rent-exempt.

For a basic wallet (0 bytes of data):

solana rent 0
# Rent-exempt minimum: 0.00089088 SOL

For a token mint account (82 bytes):

solana rent 82
# Rent-exempt minimum: 0.0015 SOL

Think of it as a deposit you make to reserve space on the network. You get it
back if you ever close the account. The network needs this mechanism to prevent
people from spamming millions of empty accounts.

Seeing It All in Practice

After 26 days of building on Solana, the account model stopped being abstract
and became obvious. When I inspected the System Program itself:

solana account 11111111111111111111111111111111

Owner: NativeLoader1111111111111111111111111111111
Executable: true
Data: system_program ← literally the program name in bytes

And the Clock sysvar:

solana account SysvarC1ock11111111111111111111111111111111

Owner: Sysvar1111111111111111111111111111111111111
Executable: false
Length: 40 bytes ← slot, epoch, unix timestamp packed as binary

The pattern is always the same: executable=true means it's code,
executable=false means it's data. The owner tells you who controls it. The
data tells you what it stores.

The Mental Model That Clicked For Me

After weeks of building, here's the one-sentence summary:

Solana is a global key-value store. Keys are 32-byte addresses. Values are
accounts with 5 fields. Programs are accounts that transform other accounts
when you call them.

Everything else — tokens, NFTs, DeFi protocols, oracles — is built on top of
this foundation. Once you see it, you can't unsee it.

I'm building in public with the 100 Days of Solana
challenge by MLH. Follow along on GitHub
and X/Twitter.

Day 27 of 100. #100DaysOfSolana

Solana Transactions Explained for Backend Developers (With Real Failures)

Gopichand — Sat, 09 May 2026 11:00:56 +0000

I've been building on Solana for the past few weeks as part of the

100DaysOfSolana challenge by MLH. Days 15–19 were all about transactions —

sending them, reading them, tracking them through confirmation stages, and
deliberately breaking them. Here's what I learned, explained for backend
developers who think in HTTP requests and database calls.

A Solana Transaction Is Not an API Call

When you hit a REST endpoint, you send a request and get a response.
If it fails, you retry. No cost, no permanent record, no cryptographic proof
it ever happened.

A Solana transaction is different in every one of those ways:

It requires a cryptographic signature from the fee payer's private key
It is permanently recorded on-chain whether it succeeds or fails
It expires after ~60–90 seconds based on a recent blockhash
It costs a fee even if it fails

That last point surprised me the most. Let me show you with real output.

The Anatomy of a Transaction

Every Solana transaction has these parts:
Signature 0: 2xQrSQU...
Account 0: srw- AWKYsCGB... (fee payer)
Account 1: -rw- 8nwngJPM...
Account 2: -r-x 11111111... (System Program)
Instruction 0
Program: 11111111... (System Program)
Transfer { lamports: 9999000000000 }
Recent Blockhash: FVSnvFfG...

Signature — cryptographic proof the fee payer authorized this tx
Accounts — every account the tx will read or write must be declared upfront
Instructions — the actual operations (transfer SOL, call a program, etc.)
Recent Blockhash — acts like a timestamp + nonce; tx expires if too old

The account permission flags (srw-, -rw-, -r-x) tell you exactly what
each account can do: signer, readable, writable, e*x*ecutable.

Solana's 3 Confirmation Levels

Unlike a database commit that's either done or not, Solana confirmation
happens in stages:

Level	What it means	Web2 analogy
Processed	Validator included tx in a block	POST reached the server
Confirmed	66%+ validators voted on the block	200 OK from load-balanced API
Finalized	31+ blocks built on top	DB commit flushed + replicated

I built a live tracker that shows each stage in real time:
Tracking confirmation stages...
[Processed → Confirmed] ✅ reached in 0.3s
[Confirmed → Finalized] ✅ reached in 0.2s

Transaction successful! 🎉
Signature: 3hYmkD3m...

On devnet, Processed→Confirmed takes ~400ms. Confirmed→Finalized takes
~6–12 seconds. In production those numbers matter for UX decisions.

What Happens When Transactions Fail

This is where things get interesting. I deliberately triggered a failed
transaction by skipping preflight simulation (skipPreflight: true) and
attempting to send 9,999 SOL when my wallet only had ~6.14 SOL.

Here's the real on-chain output from solana confirm -v:
Status: Error processing Instruction 0: custom program error: 0x1
Fee: ◎0.000005
Account 0 balance: ◎6.13593 -> ◎6.135925
Account 1 balance: ◎0
Compute Units Consumed: 150
Log Messages:
Program 11111111111111111111111111111111 invoke
Transfer: insufficient lamports 6135925000, need 9999000000000
Program 11111111111111111111111111111111 failed: custom program error: 0x1

Three things stand out:

1. The fee was charged anyway.
Account 0 balance dropped by 0.000005 SOL — just the fee, not the transfer.
The network did work (verified signature, attempted execution), so it got paid.

2. The error is structured.
custom program error: 0x1 from the System Program always means insufficient
lamports. As you write your own programs, these error codes become your
primary debugging tool — like HTTP status codes but for on-chain logic.

3. The Log Messages are your stack trace.
Transfer: insufficient lamports 6135925000, need 9999000000000 tells you
exactly what was available vs what was needed. This is how you debug failed
instructions in production.

Two Types of Failure: Local vs On-Chain

Not all failures reach the chain:

Failure type	Where it stops	Fee charged?
CLI preflight (insufficient funds check)	Never leaves your machine	❌ No
On-chain failure (skipPreflight)	Executed by validators	✅ Yes

This is why production apps use simulateTransaction before submitting.
Simulation catches errors locally for free. Every on-chain failure is real
money, even if it's tiny amounts.

The Mental Model Shift

The biggest shift from Web2 to Solana transactions:

Web2: You send a request. The server decides what happens. You get a
response. If something breaks server-side, you don't pay for it.

Solana: You sign and broadcast a state change. Validators execute it
atomically. The result — success or failure — is permanent and public.
You pay regardless.

The blockhash expiry (~60–90s) also changes how you think about retries.
You can't just retry the same signed transaction forever — the blockhash
goes stale. You need to rebuild and re-sign with a fresh blockhash.

What I Built This Week

Day 15 — Inspected transaction anatomy: signatures, accounts, instructions, compute units
Day 16 — Sent first SOL transfer on devnet (<1s settlement)
Day 17 — Built a reusable Node.js CLI transfer tool with balance checks and Explorer links
Day 18 — Added live confirmation tracking (Processed→Confirmed→Finalized)
Day 19 — Deliberately broke transactions, read on-chain errors with solana confirm -v

All code is on my GitHub:
github.com/gopichandchalla16/100-days-of-solana

If you're coming from a Web2 background and starting with Solana, the
transaction model will feel strange at first. The fee-on-failure behavior,
the blockhash expiry, and the upfront account declaration all exist for
good reasons — they're what makes Solana fast, parallel, and predictable.
Once it clicks, it's actually elegant.

Day 20 of #100DaysOfSolana — building in public every day 🚀
Follow my progress: @GopichandAI

Week 2 on Solana: When the "Public Database" Finally Clicked

Gopichand — Mon, 04 May 2026 07:55:21 +0000

I'm doing the 100 Days of Solana challenge by MLH, and Week 2 just changed how I think about blockchain data entirely.

Week 1 was about identity — generating keypairs, understanding wallets, getting devnet SOL. That part felt familiar, like setting up a dev environment.

Week 2 was different. Week 2 was about reading the chain — and that's where the mental model shift actually happened.

What I expected vs what I got

I expected reading blockchain data to feel like calling a mysterious, slow, complex API. Something with heavy setup, authentication tokens, and confusing docs.

What I got was this:

const { value: lamports } = await rpc.getBalance(address).send();
const sol = Number(lamports) / 1_000_000_000;

No API key. No login. No permissions. Anyone can call this for any address, anytime.

In Web2, if I want someone's account balance, I need DB credentials, role permissions, and middleware. On Solana, I just ask. Publicly. That's not a flaw — that's the design.

The moment it clicked

Day 11 was a conceptual challenge: compare Solana accounts to Web2 databases. I ran:

solana account $(solana address)

Output:
Public Key: AWKYsCGBcfGLSz6QpmXzRn7EJ9fRhiJsjYSLDV3c9L9y
Balance: 2.5 SOL
Owner: 11111111111111111111111111111111
Executable: false

Then I ran:

solana account TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

Output:
Owner: BPFLoaderUpgradeab1e11111111111111111111111
Executable: true
Length: 36 bytes

Same command. Same account model. One is a wallet holding SOL. The other is the Token Program — compiled code that manages every SPL token on Solana. Both are just "accounts."

That's when "everything is an account" stopped being a slogan and started being a mental model.

The devnet vs mainnet surprise

Day 12 was the most satisfying. One script. Two RPC connections:

const devnetRpc  = createSolanaRpc(devnet("https://api.devnet.solana.com"));
const mainnetRpc = createSolanaRpc(mainnet("https://api.mainnet-beta.solana.com"));

Same address. Same getBalance call. Completely different output:
DEVNET → 0.001159846 SOL | Slot: 459,981,397
MAINNET → 0.069875097 SOL | Slot: 417,486,413

Different balances. Different slots. Completely different transaction histories. I already knew they were separate — but seeing it side by side in the terminal made it real in a way docs never did.

What's still confusing

PDAs — Program Derived Addresses. I understand they're derived from a program + seed with no private key, so only the program can sign for them. But I haven't used one yet. I can describe them but I can't feel them. That's my Week 3 target.

What I'd tell Week-1-me

Stop thinking in tables and rows. Start thinking in accounts and owners. Every piece of state on Solana is an account. Every account has an owner program. Only that program can modify it. That's not a restriction — that's what makes the system trustless.

Also: devnet is your playground. Break things there first.

If you're also doing #100DaysOfSolana, drop your DEV.to link below — I want to read what clicked for you.

→ My code: https://github.com/gopichandchalla16/100-days-of-solana

Your Public Key IS Your Identity: What Web2 Devs Need to Know About Solana

Gopichand — Tue, 28 Apr 2026 16:55:00 +0000

If you've been a Web2 developer for any amount of time, you know what identity
looks like: a username in a database, an email address, a session cookie,
maybe an OAuth token from Google. Your "identity" is really just a record that
some company controls. They can delete it. They can lock you out. They can sell
the data. You don't own it — you just borrow it.

Solana works completely differently. And once you understand how, you can't
unsee it.

It Starts with a Keypair

When I started the 100 Days of Solana challenge, the first thing I did was run:

solana-keygen new --no-bip39-passphrase -o wallet.json

This generated two things:

A public key — a 32-byte Ed25519 address like AWKYsCGBcfGLSz6QpmXzRn7EJ9fRhiJsjYSLDV3c9L9y
A private key — stored in wallet.json, never shared

That's it. That keypair IS my identity on Solana. No signup form. No email
verification. No "username already taken."

The SSH Key Analogy

If you've ever set up a server on AWS or DigitalOcean, you already understand
this model. You generate an SSH keypair, paste the public key into the server's
authorized_keys file, and prove your identity by holding the private key.

Solana works identically — except instead of one server, it's the entire
global network. Every node on Solana knows your public key. You prove ownership
by signing transactions with your private key.

The difference from Web2 is critical: no company stores your credentials.
There is no database row. There is no admin who can reset your password or
lock your account.

What a Solana Address Actually Is

A Solana address is a Base58-encoded 32-byte Ed25519 public key. Base58 was
chosen deliberately — it removes visually confusing characters like 0, O,
I, and l to prevent copy-paste mistakes.

In Web2, your username lives in someone's Postgres table:

SELECT * FROM users WHERE username = 'gopichand';

On Solana, your identity is derived from math. It exists everywhere and nowhere
simultaneously — it only becomes real when you sign something with the private key.

Cryptographic Ownership vs Company-Granted Access

Here's the most important mental shift:

In Web2, you "own" your account because a company says you do. Twitter can
ban you. Your bank can freeze your account. Google can lock your Gmail. You
have access because they allow it.

On Solana, ownership is cryptographic. If you hold the private key, you control
the account — period. No appeal process, no customer support ticket, no
waiting for a human to review your case.

This is both powerful and terrifying. Lose your private key? Your funds are gone
forever. No recovery email. That's why seed phrases and hardware wallets exist.

Identity Enables Everything Else

Once I had a keypair, I could:

Receive devnet SOL — just by sharing my public key
Connect a browser wallet — Phantom connected on Day 4 without me ever sharing my private key
Sign transactions — prove I authorized a transfer without revealing my secret
Own tokens and NFTs — because ownership is just a signed record on-chain

This one keypair is the foundation for token ownership, dApp interactions,
governance votes, and on-chain reputation — across every application on the
network, without asking anyone's permission.

Which Wallet Type Should You Use?

During Day 5 of the challenge, I compared three wallet types:

Wallet	Key Storage	Best For
CLI (`id.json`)	Plaintext file	Devnet scripting
Browser (Phantom)	Encrypted + password	dApp interactions
Mobile (Phantom)	Hardware-backed + biometrics	Personal daily use
Hardware (Ledger)	Never leaves device	Long-term storage

The underlying keypair concept is identical across all of them. What differs
is where the private key lives and how it's protected.

The Big Takeaway

In Web2, identity is a database record owned by someone else.
In Web3, identity is a mathematical keypair owned by you.

Your public key is your username, your account number, and your proof of
existence on the network — all at once. The private key is the only password
that matters, and only you should ever hold it.

I'm documenting every step of this journey publicly as part of the
100 Days of Solana
challenge by MLH.

All my code is on GitHub: github.com/gopichandchalla16/100-days-of-solana

Follow along if you're on the same journey! 🚀

100daysofsolana #solana #web3 #blockchain #beginners

DEV Community: Gopichand

Three Token-2022 Mints in One Week: Fees, Yield, and Soul-Bound

Mint 1 — Transfer Fee (Days 50 & 51)

Mint 2 — Transfer Fee + Interest Stacked (Day 52)

Mint 3 — Non-Transferable / Soul-Bound (Day 54)

What surprised me

Solana NFTs Without Metaplex: What I Learned Building with Token Extensions published: true

The Mental Model: What a Solana NFT Actually Is

What I Built: Four Days, Four Commands

Day 44 — First NFT with on-chain metadata

Day 45 — NFT collection using Group and Member extensions

Day 46 — Auditing every byte on devnet

Day 47 — Mutating metadata live

The Surprising Part

What I Would Build Next

Resources I Actually Used

44 Days of Solana: From an Empty README to a Live NFT on-chain — My Finish-Up-A-Thon Story

What I Built

Demo

🌐 "First Light" — My First NFT, Live on Solana Devnet

📋 Every Step — Verified On-Chain

📰 9 Published DEV.to Articles (300+ total reactions)

📊 Where the Project Stands

The Comeback Story

Day 1 — What the repo actually looked like

Day 44 — What the repo became

The 3 moments that defined this project

The biggest technical lesson of 44 days

My Experience with GitHub Copilot

When I was stuck on 0x11 at midnight (Day 37)

When soulbound tokens confused me (Day 40)

Writing CLI commands faster and correctly

Turning raw terminal output into readable articles

Explaining the "why" — not just the "how"

The honest summary

I Built 5 Token Extension Combinations on Solana This Week — Here's What Each One Does

What Are Token Extensions?

Extension 1 — Interest-Bearing Tokens

Extension 2 — Transfer Fees

Extension 3 — Default Account State (Frozen)

Extension 4 — Non-Transferable (Soulbound)

Extension 5 — Permanent Delegate (Revocable)

The Cost of Extensions

What Cannot Be Changed After Creation

Inspecting Any Token Extension Config

Where to Go Next

Transfer Fees, Metadata, and Soulbound Tokens: A Tour of Solana Token Extensions

The Starting Point: Two Token Programs

Day 29 — Creating My First SPL Token

Day 30 — Token-2022 with On-Chain Metadata

Day 31 — Transfer Fees at the Protocol Level

Day 32 — The Full Lifecycle in One Sitting

Day 33 — Soulbound Tokens

What Surprised Me

What's Next

Week 5 on Solana: Everything I Learned About Tokens (Days 29–31)

What "Tokens" Actually Means on Solana

Day 29: My First Token — Raw and Nameless

Day 30: Giving My Token an Identity with Token-2022

Day 31: Built-in Transfer Fees — No Middleware Required

The Mental Model That Changed Everything

SPL Token vs Token-2022: Quick Reference

What's Next

How I Created My First Solana Token from Scratch (SPL Token Basics Explained)

The Web2 Mental Model (and Why It Breaks Here)

The Two Key Accounts You Need to Understand

Step-by-Step: Creating My First SPL Token

Prerequisites

Step 1: Create the token mint

Step 2: Create a token account

Step 3: Mint some supply

Step 4: Inspect everything

The Decimals Trick

What "Mint Authority" Actually Means

Freeze Authority: What It Is and Why I Left It Unset

The Big Picture

I Built a Branded Token on Solana in 5 Minutes (No Smart Contract Needed)

100DaysOfSolana challenge, I created a fully branded token — with a name,

The Problem with Yesterday's Token

Token-2022 vs the Original SPL Token Program

When I was stuck on `0x11` at midnight (Day 37)