DEV Community: Gopichand

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

Starting 100 Days of Solana as an AI Web3 Builder.

Gopichand — Sat, 18 Apr 2026 05:39:28 +0000

Hi DEV community 👋
I’m Gopichand, a CSE graduate from India, and I’m building in public around AI × Web3.
I’ve recently joined the 100 Days of Solana challenge, and I want to use this journey to learn Solana step by step, share what I build, and connect with other developers who are exploring web3.

My goal is simple: learn by doing, document the process, and turn each small win into a real project.
I’ll be sharing updates, experiments, and lessons as I go.

Excited to be here — and I’d love to hear from anyone else learning Solana or building on chain.

Follow my progress:

gopichandchalla16 (Gopichand) · GitHub

AI × Web3 builder | LangChain · Solidity · On-chain agents | Building in public daily → @GopichandAI - gopichandchalla16

github.com

x.com