DEV Community: Prasiddh Naik

What Token Extensions Finally Made Me Understand

Prasiddh Naik — Thu, 04 Jun 2026 11:09:02 +0000

Subtitle: Token-2022 showed me that tokens can have rules, not just balances.

This week I moved past basic SPL tokens and started using Token Extensions.

At first, I thought a token was mostly just:

a mint
token accounts
balances
transfers

But Token-2022 adds something more interesting: behavior.

A token can charge transfer fees.
A token can display interest over time.
A token can start every account frozen.
A token can be non-transferable.
A token can have a permanent delegate for revocation.

That made tokens feel less like simple coins and more like product systems.

Interest-bearing tokens

The first extension that clicked was interest-bearing tokens.

The weird part is that the raw balance does not actually grow. If I mint 1000 tokens, the account still holds 1000 tokens. The interest-bearing extension changes the UI amount by applying an interest formula over time.

So it feels like a savings account, but without a backend cron job constantly minting more tokens.

That was the first “ohhh” moment.

Multi-extension tokens

Then I tried combining extensions.

One mint could have:

transfer fees
interest
metadata

That means the token can charge a fee when it moves, display an interest-adjusted balance, and carry its name, symbol, and URI.

The important lesson: extensions must be planned before the mint is created. You cannot just bolt them on later like a random npm package. Annoying, but fair.

Here is the kind of command I used:

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  create-token \
  --decimals 2 \
  --transfer-fee-basis-points 100 \
  --transfer-fee-maximum-fee 500 \
  --interest-rate 5 \
  --enable-metadata

That creates a Token-2022 mint with multiple extensions enabled.

Default frozen accounts

The default frozen account extension felt like a compliance system.

Every new token account starts frozen. The authority has to thaw an account before it can receive, send, or burn tokens.

In Web2 terms, it is like saying:

“You can have an account, but you cannot use it until you are approved.”

That makes sense for regulated assets, gated communities, or tokens where both sender and receiver need permission.

Inspecting mints

One of the best lessons was not building, but reading.

Using:

spl-token display [MINT_ADDRESS] \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

I could inspect which extensions were active on a mint.

That made me realize extension configuration is like reading a project’s config file. Before trusting a token, you should check its rules.

Does it have fees?
Who controls the fee authority?
Is there a freeze authority?
Is there a permanent delegate?

The token’s behavior is part of the trust model.

Revocable credentials

My favorite idea was combining:

non-transferable tokens
permanent delegate
metadata

That creates something like a certificate.

The token cannot be transferred, so the holder cannot sell it or send it to someone else. But the issuer can still revoke it by burning it through the permanent delegate.

That makes sense for:

course certificates
badges
memberships
licenses
reputation tokens

This was the moment Token Extensions felt less like “crypto stuff” and more like actual product design.

Token Extensions are not random features.

They are rules.

Transfer fees decide what happens when value moves.
Interest-bearing extensions decide how balances are displayed.
Default frozen accounts decide who is allowed in.
Non-transferable tokens decide whether something can be sold.
Permanent delegates decide who can revoke or control tokens.

The big lesson: with Token-2022, the token program can enforce behavior that an app would normally need to manage itself.

That is powerful.

Also slightly terrifying.

Because once these rules exist, users need to know what they are holding.

Tags: #solana #web3 #learning #100daysofsolana

Solana Token Extensions: Fees and Metadata

Prasiddh Naik — Tue, 26 May 2026 14:48:24 +0000

Over five days on devnet I went from a basic mint to on-chain metadata, transfer fees enforced by the Token-2022 program, a full lifecycle run without notes, and a non-transferable credential token. The throughline: token behavior is configured at the mint, not patched in later.

This post is what I wish I had read before I started.

Starting point

I already had Solana accounts, wallets, and SOL transfers down. Tokens were the next layer.

The Token Extensions Program (Token-2022) attaches capabilities to the mint account at creation time. Transfer fees, metadata pointers, non-transferability — you opt in with CLI flags when you run create-token. You cannot add those extensions after the fact.

Plan the token's rules before you mint.

Token Program vs Token Extensions

Solana has two token programs:

Program	Address (short)	What I used it for
Original SPL Token	`TokenkegQfeZyiNw...`	Classic fungible tokens
Token Extensions (Token-2022)	`TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb`	Metadata, transfer fees, non-transferable mints

If you want extensions, opt in at mint creation:

--program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

Lesson I learned the hard way: after creating a Token-2022 mint, pass --program-2022 (or --program-id TokenzQd...) on every follow-up spl-token command. I hit AccountInvalidOwner on initialize-metadata until I added that flag. The CLI defaults to the original Token Program unless you tell it otherwise.

Day 29–30: Mint and metadata

The first step is boring on purpose — create a mint, create an associated token account, mint supply:

solana config set --url devnet
solana balance

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

That gives you a fungible token. Wallets and explorers can show a balance, but without metadata it is just an address with decimals.

Token-2022 lets you attach identity on-chain:

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

spl-token initialize-metadata <MINT> "MyToken" "MTK" \
  "https://example.com/metadata.json" \
  --program-2022

Name, symbol, and URI live in the mint's extension data. Explorers and wallets read them directly from chain state.

Order matters: initialize metadata before you mint large supply if your workflow depends on a fully configured mint from the start.

Day 31: Transfer fees at the protocol level

This is where Token Extensions stopped feeling like "SPL Token plus extras" and started feeling like a different design surface.

I created ReinforceCoin (RFC) with a 2% transfer fee (200 basis points):

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

Mint: 8rVUkh7tbh1uR9GMbAZYZeFQ3EZ8Tkqu5nh3kToSAZ7a

After metadata, I minted 1000 tokens to my wallet, created a token account for a second devnet wallet (second-wallet.json), and transferred 100 tokens:

spl-token transfer --fund-recipient <MINT> 100 <RECIPIENT_PUBKEY> \
  --expected-fee 2 \
  --allow-unfunded-recipient \
  --program-2022

The recipient balance was 98, not 100. Two tokens were withheld as fees — enforced by the Token-2022 program during TransferChecked, not by anything I wrote in a script.

Every transfer through this mint pays the same fee. Wallets, DEXs, and CLI tools all hit the same on-chain rule.

To collect withheld fees, the mint authority withdraws from the recipient's token account:

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

Fees accrue on transfer and get collected in a separate step. That two-phase flow was not obvious from the docs alone.

Day 32: Reinforcing the full lifecycle

Day 32 was deliberately repetitive: run the entire flow in one sitting without notes. Create mint → metadata → mint supply → fund recipient → transfer with fee → withdraw withheld → verify with spl-token display.

Muscle memory, not trivia.

The commands that stuck:

spl-token display <MINT> --program-2022 — extensions, fee config, authority
--expected-fee on transfer — CLI sanity-checks your math against on-chain rules
Token account addresses vs mint addresses — see below

Day 33: Non-transferable tokens (soulbound credentials)

For credentials, diplomas, or achievement badges, you want the chain to reject transfers — not a UI warning.

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

Mint: Gvztbeuf4Szs9KDvXxHkzRGPEsnf895FozQPoTnUPipu

I minted 10 tokens to my ATA (5abnDEFHy5Btm2kyazagTaiaQaXUv4bStZusw69jndS3) and tried to send 5 to an experiment wallet. The transaction failed in simulation:

Program log: Transfer is disabled for this mint
custom program error: 0x25

That failure was success. The Token-2022 program enforces non-transferability — no workaround at the client level.

Burning still worked. I reduced my balance from 10 to 7 by burning from the token account, not the mint:

# Wrong — mint address is not a token account
spl-token burn Gvztbeuf4Szs9KDvXxHkzRGPEsnf895FozQPoTnUPipu 3 ...

# Right — pass the ATA that holds your balance
spl-token burn 5abnDEFHy5Btm2kyazagTaiaQaXUv4bStZusw69jndS3 3 \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

Address	Role
`Gvztbeuf...`	Mint — token definition
`5abnDEFH...`	My associated token account — holds balance
`5K6a2t28...`	Experiment wallet's token account

Confusing mint with a token account is an easy mistake to make. The CLI error messages nudge you toward the right object, but knowing the account model saves time.

What surprised me

Rules are chosen at birth. Extensions are set when the mint is created. Plan the economics before you mint.
Fees are withheld, not instantly routed. Transfer fees sit in recipient token accounts until someone with authority runs withdraw-withheld-tokens.
Non-transferable does not mean frozen. I can still mint and burn. I just cannot move balances between owners — which is exactly what you want for credentials.
The --program-2022 flag is load-bearing. Same CLI, different program owner. Forgetting the flag produces errors that look like corruption but are just wrong program IDs.
Write down addresses as you go. Mint, your ATA, recipient ATA — each step prints new ones. I lost time re-deriving them from transaction logs.

Useful references while you work: Tokens on Solana, Token Extensions, and the SPL Token CLI.

Solana Mental Model for Web2 Developers

Prasiddh Naik — Sun, 17 May 2026 12:02:14 +0000

If you come from Web2 development, the easiest way to understand Solana is to stop thinking about contracts first and start thinking about accounts.

On Solana, almost everything is an account. A wallet is an account. A token balance is an account. A program which is Solana's version of a smart contract is also an account. Instead of storing application state in a database table or inside a contract object, Solana stores state in accounts that live on-chain.

A Solana account is like a file in a filesystem. It has an address, some metadata, and some contents. The address is a 32-byte public key. The metadata tells you who owns it, whether it is executable, and how much SOL it holds. The contents are just raw bytes.

Every Solana account has five core fields:

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

lamports are the account's SOL balance. One SOL equals one billion lamports.

data is a byte array. This is where programs store custom state. A normal wallet account usually has zero bytes of data. A token account or NFT metadata account has structured data inside this field.

owner is the program that controls the account. This is one of the most important ideas in Solana. Only the owner program can modify an account's data or debit its lamports.

executable tells you whether the account is a program. If it is true, the account contains executable program code. If it is false, it is a regular data account.

rentEpoch is a legacy field. Today, accounts are generally rent-exempt, and this field is usually set to the maximum value.

The ownership rule is Solana's security model in one sentence: only the owning program can change an account's data. For example, your wallet is owned by the System Program, so the System Program handles SOL transfers. Token accounts are owned by the Token Program, so only the Token Program can move tokens or update token balances.

The part that surprises many Web2 developers is that Solana programs do not store their own state. Programs are stateless. A program account stores executable code, while separate data accounts store the actual application state.

A useful analogy is a web server and a database. The program is like the backend server: it contains the logic. The accounts are like database records: they contain the data. When a transaction runs it tells the program which accounts it wants to read or write.

This is different from Ethereum, where a smart contract usually owns both the code and the state together. On Solana code and state are separated. That separation is one reason Solana can process many transactions in parallel. If two transactions touch different accounts, they can often run at the same time.

There is also the idea of rent exemption. Because account data takes space on-chain accounts must hold a minimum SOL balance based on their size. This keeps the account alive. For a basic account with no extra data, the rent-exempt amount is small roughly around 0.00089 SOL. You can calculate exact values with the Solana CLI or the getMinimumBalanceForRentExemption RPC method.

So the mental model is simple:
Solana is a giant public key-value store. The key is an account address. The value is an account object with balance, owner, executable status, and raw data. Programs are accounts that contain code. Data accounts are accounts that contain state. The owner field decides who is allowed to modify what.

Once this clicks, the rest of Solana starts to make more sense. Tokens, NFTs, DeFi protocols, staking, governance, and games all use the same basic building block: accounts.

Solana Transactions Cost Money Even When They Fail

Prasiddh Naik — Sat, 09 May 2026 11:50:55 +0000

Here's what I learned in 3 weeks: failed transactions on Solana cost real SOL.

The Surprise

As a backend dev, I'm used to failed requests being free. A 500 error? Retry it. It's no big deal.

Solana is different. When you send a transaction, three things can happen:

CLI catches it → Free (local balance check)
Simulation catches it → Free (RPC preflight check)
On-chain fails → Costs 0.000005 SOL

Watching It Happen

I created a broke wallet (0 SOL) and tried to transfer:

solana transfer --from /tmp/broke-wallet.json $RECIPIENT 1
# Error: insufficient funds (caught locally, free)

Then I used a funded wallet but tried to send more than my balance:

// With skipPreflight = true (dangerous)
await rpc.sendTransaction(tx, { skipPreflight: true });

Result:

Signature: 5NWqdwSCmc3vz2PAwMmBQppL6uogPB7qkRWzUnCFtA9...
Status: Error processing Instruction 0: custom program error: 0x1
Fee: ◎0.000005
Balance: 8.39795 -> 8.397945 SOL

The transaction failed. The fee was still charged.

Why This Matters

In Web2, validation happens before the operation:

if (account.balance >= amount) {
  await db.transfer(account, recipient, amount);
}

In Solana, validation happens inside the transaction. The blockchain doesn't check first—it tries to execute and fails if conditions aren't met. The attempt itself is a processed transaction.

The Fix

Always simulate before sending:

// Default: skipPreflight = false (simulates first)
await rpc.sendTransaction(tx, { skipPreflight: false });

And check balances client-side:

const balance = await rpc.getBalance(sender).send();
if (balance.value < amount + fee) {
  throw new Error("Insufficient funds");
}

Bottom Line

On Solana, there's no "try it and see." Every attempt that reaches the network costs money. Design your error handling accordingly.

Day 19 of 100 Days of Solana. Full code: [https://github.com/prasiddhnaik/solana-100-days]

Tags: #solana #web3 #blockchain #backend

BharatZero

Prasiddh Naik — Fri, 08 May 2026 12:34:30 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

BharatZero is an India-focused legislative explorer that aggregates parliamentary data spanning 1947 to the present into a unified, searchable platform. The app solves a critical transparency problem: India's legislative information is scattered across dozens of government portals (Sansad, PRS Legislative Research, Parliament Digital Library, Data.gov.in), hidden in PDFs, and nearly impossible to navigate comprehensively.

BharatZero brings it all together:

4,708 bill records from three different official sources
7,253 timeline events tracking parliamentary activity
2,560 sitting days with chronological browsing
Prime Minister term filtering—see what legislation passed during any PM's tenure
Complete source attribution for data provenance

The platform features eight sections: Overview, Houses (with Lok Sabha power charts), Timeline, Bills, Committees, Debates, Acts, and Sources. Every record shows exactly where it came from—critical for democratic transparency.

Demo

bharatzero.vercel.app

Code

prasiddhnaik / Bharat0

BharatZero

BharatZero is an India-focused legislative explorer for bills, Acts, Parliament timelines, House power, Prime Minister terms, and official source coverage. It is built as a Vite/React frontend with a small Node API server, Prisma, and PostgreSQL/Neon.

The current app is no longer just a static prototype. It uses generated legislative datasets plus a Prisma-backed repository path for runtime data.

Current Coverage

Generated local datasets currently include:

4,708 Bill records
7,268 Bill action records
7,253 timeline events
2,560 sitting days
217 Act records
15 Prime Minister profile records
16 Lok Sabha power snapshots

Main source families:

Sansad legislation data, as of 2026-04-25
PRS historical bill data, 1992-2019
Parliament Digital Library bill/proceeding data, 1947-2003
Curated Prime Minister profile data from PM India
Curated Lok Sabha power snapshots from ECI/IPU-style election summaries

The PDL sync now covers older Prime Ministers, including Nehru, Shastri, Nanda, and Indira Gandhi-era windows where source records exist.

…

View on GitHub

How I Used Gemma 4

I chose Gemma 4 31B Dense (gemma-4-31b-it) via the Gemini/OpenAI-compatible API for bill analysis generation. Legislative bills are dense, technical documents—often 50+ pages of legal language. Citizens, journalists, and researchers need accessible summaries, but manual summarization doesn't scale across 4,700+ bills.

BharatZero uses Gemma 4 to generate plain-language summaries, economic impact analysis, key provisions extraction, and social implications analysis. The model handles the bilingual nature of Indian legislation seamlessly—bill titles and summaries work in both English and Hindi contexts without separate model tuning.

Analysis is expensive, so BharatZero implements a persistent cache layer. Once a bill is analyzed, results are stored in PostgreSQL. Subsequent requests serve cached results instantly.

Why Gemma 4 31B Dense was the right fit:

Long context: Bills are lengthy documents; Gemma 4 handles full text input
Structured output: Returns consistent JSON for parsing into the UI
Factual accuracy: Critical for legislative analysis—hallucinations are dangerous
Cost efficiency: More economical than alternatives for high-volume batch analysis

solana notes - week 2

Prasiddh Naik — Wed, 06 May 2026 14:26:30 +0000

100DaysOfSolana

i've used normal databases for years, so i kept trying to force solana into that shape. tables, rows, queries. some of that helps, a lot of it breaks.

what surprised me

reading a balance is stupidly simple:

const { value: balanceInLamports } = await rpc
  .getBalance(targetAddress)
  .send();

the code is easy. the mental model is what's hard.

the click moment

ran solana account $(solana address) and saw my wallet data. then realized: anyone can do this. no api keys, no auth. just the public key and you're reading someone's balance.

that's uncomfortable in a good way. in web2 data is hidden unless i expose it. here it's visible unless i design around it.

the sdk

@solana/kit feels normal. not crusty like i expected. async/await, clean imports. the devnet() and mainnet() wrappers aren't just for show—they actually tag the network for type safety. someone thought about DX.

where the database comparison breaks

normal thinking	solana reality
sql joins	lol no. fetch signatures, then fetch details
private by default	public by default
i control who reads	everyone reads
alter table, migrations	nope. design upfront, serialize to bytes

i keep wanting SELECT * FROM transactions WHERE user_id = 123. instead:

const signatures = await rpc
  .getSignaturesForAddress(address, { limit: 5 })
  .send();
// then fetch each one i guess

more manual. that's the tradeoff.

devnet vs mainnet hit different

--- Devnet ---
Balance : 0.001159846 SOL

--- Mainnet ---
Balance : 0.069875097 SOL

same address, same code, different world. staging vs production except anyone can view production.

still fuzzy on

PDAs - when do i actually use them vs regular accounts?
rent - deposit not fee, but the exact economics? need to build something that creates/closes accounts
cross-program calls - just words to me right now
writing transactions - reading is safe. writing feels serious. nervous about it.

send a simple transaction
one PDA example end to end
build something that actually writes, not just reads

where i'm at

day 12. not an expert. but less intimidated.

the code looks familiar while the assumptions underneath are totally different. public data by default. accounts instead of tables. pay for storage not queries. still rewiring my brain.

if you're also confused by accounts, PDAs, or why everything is public: same. i think that's just part of it.

What Does "Identity" Actually Mean on a Blockchain?

Prasiddh Naik — Sat, 25 Apr 2026 11:17:13 +0000

If you've been writing code for a while, you've probably used SSH keys. You generate a key pair, drop the public key on a server, and from that point on, you prove who you are by holding the private key. No username, no password reset. You either have the key, or you don't

Solana identity works on the same principle: you have the key, or you don't — except that, instead of a single server, it's the entire network.

The problem with Web2 identity

In Web2, you have no power; you're just renting space. You don't control your GitHub or Google accounts; the company does. They give you access, but they can also take it away.

Even when it feels like yours, it isn't. Your email address exists because Google or Microsoft allows it to.

How Solana does it differently

On Solana, your identity starts with a single cryptographic keypair — a public key and a private key. The public key is your address, something like 14grJpemFaf88c8tiVb77W7TYg2W3ir6pfkKz3YjhhZ5. That's what the world sees. The private key never leaves your wallet, and it's the only thing that can authorize actions on your behalf.

No company issues this key pair. No server stores it. You generate it yourself, you hold it, and it works across every application on the Solana network without asking anyone's permission. There's no sign-up form, no email verification, no "log in with Google." Your keypair is your identity, and it's yours in a way that a Web2 account never is.

Ownership that actually means something

Here's the part that takes a moment to sink in: on Solana, only the holder of the private key can sign transactions for an account. Not a company. Not an admin. Not a support team. There's no password reset flow, no "verify your identity" email, no override. If you hold the private key, you control the account. If you lose it, it can't be recovered.

That sounds scary, and it is if you're careless. But it also means no one can lock you out of your own account. No platform ban, no policy change, no company going bankrupt takes your identity with it. The tradeoff is real responsibility — but so is real ownership.
What this identity actually unlocks

On-chain identity isn't just a replacement for a username. Because it's cryptographic, it becomes the foundation for everything else on the network. Token ownership is tied to your keypair. When you vote in a DAO governance proposal, your keypair is the vote. When you interact with a program, your keypair authorizes it. When you build a reputation across DeFi protocols or NFT platforms, it all traces back to the same address.

In Web2, your reputation on GitHub doesn't carry over to LinkedIn, which doesn't carry over to your bank. Each platform starts from zero. On Solana, your keypair is consistent across the entire ecosystem. Any application can read your on-chain history without you having to re-verify anything.