DEV Community: atharv shukla

What Building Three Token-2022 Mints Changed About How I Think About Tokens

atharv shukla — Wed, 15 Jul 2026 12:02:14 +0000

This week I built three different Token-2022 mints on Solana Devnet:

A fee-bearing token
An interest-bearing token
A non-transferable (soulbound) token

The biggest realization wasn't learning new CLI commands.

It was understanding that Token-2022 lets you compose behaviors directly into a token instead of writing custom smart contracts.

A transfer fee isn't middleware anymore.

Interest isn't a background cron job.

A soulbound badge isn't enforced by your backend.

They're all properties of the mint itself.

I wrote a complete technical walkthrough covering all three experiments here:

👉 https://dev.to/atharv_shukla_f7a20a5893f/three-token-2022-mints-in-one-week-fees-yield-and-soulbound-...

If you're coming from Web2 and wondering what Token-2022 actually changes, I hope it helps.

100DaysOfSolana

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

atharv shukla — Wed, 15 Jul 2026 11:57:22 +0000

Token-2022 Is Middleware for Your Currency

If you come from Web2, think of Token-2022 as the upgraded SPL token program on Solana — the same way you might think of Express middleware layered on top of a Node server. Instead of forking the token program to add custom behaviors, you flip extension flags at mint creation time. The runtime enforces them from that point forward. No custom smart contracts. No Rust. Just CLI commands and configuration that lives on chain forever.

Every extension is stored inside the mint account using Solana's Type-Length-Value (TLV) layout. When you enable an extension during mint creation, the account allocates extra bytes for that extension's data, which is why more features require more rent. The architecture looks like this:

              Token-2022 Mint Account
             ┌─────────────────────┐
             │   Base Mint Data    │  ← supply, decimals, authorities
             ├─────────────────────┤
             │   Transfer Fee      │  ← TLV: basis points, max fee, authorities
             ├─────────────────────┤
             │   Interest-Bearing  │  ← TLV: rate, timestamp, authority
             ├─────────────────────┤
             │   Metadata          │  ← TLV: name, symbol, uri
             ├─────────────────────┤
             │   Non-Transferable  │  ← TLV: flag (no extra data)
             └─────────────────────┘
              Extensions stack as
              additional TLV entries

Over the past week, I shipped three mints on devnet using three different extensions. Here's exactly what I built and why each one matters.

Mint 1: The Fee-Bearing Token (Transfer Fee Extension)

Mint Address: WjbwpciSWwF8XWjHKtrACU9ypK1LwpFjSgGMb4gV9Dp
Extension: TransferFeeConfig

The Command

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

This creates a token that automatically skims 1% (100 basis points) off every transfer, capped at 1,000,000 tokens. The fee is withheld in the recipient's token account, and the withdrawal authority (me) can sweep it back at any time.

On-Chain Proof

Extensions
  Transfer fees:
    Current fee: 100bps
    Current maximum: 1000000000000
    Config authority: BJpejz8HQwF1TciYZEBD8VGu12wdVQxq3KkcECcT1AiK
    Withdrawal authority: BJpejz8HQwF1TciYZEBD8VGu12wdVQxq3KkcECcT1AiK
    Withheld fees: 0

I transferred 1,000 tokens to a second wallet and watched the protocol automatically withhold 10 tokens as the fee. Then I swept those withheld fees back with a single command:

spl-token withdraw-withheld-tokens <MY_ACCOUNT> <RECIPIENT_ACCOUNT>

When Would You Use This?

Anytime you want the protocol itself to enforce a take rate — royalties on a creator token, a protocol fee on a stablecoin, or a treasury skim on a community currency. The fee is baked into the mint. No one can transfer without paying it.

Mint 2: The Interest-Bearing Token (Transfer Fee + Interest Stacked)

Mint Address: GS7JaVubA3AxVbubg7tU8WsxLP2FLgMuMS82Yj8n6maL
Extensions: TransferFeeConfig + InterestBearingConfig

The Command

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

Two extensions on one mint. The transfer fee works exactly like Mint 1. The interest-bearing extension adds a 50% APR (5000 basis points) that makes the displayed balance drift upward over time.

The Subtle Thing That Matters

Here's what caught me off guard: the interest extension does not mint new supply. It updates the UI-displayed amount using a continuous compounding formula based on elapsed time. The raw token amount in the account stays the same. The "interest" is a presentation-layer calculation that wallets and explorers render.

The extension changes how wallets compute and display balances. The raw token amount stored on-chain never increases. If you're building a product on top of this, you need to understand that distinction — the displayed balance and the actual balance are two different numbers.

On-Chain Proof

Running spl-token display on the same account 30 seconds apart:

First check:
  1,000,000.332734

30 seconds later:
  1,000,000.730303

The displayed balance drifts upward without any transaction. That's the interest extension at work — pure math, zero minting.

Mint 3: The Soulbound Badge (Non-Transferable Extension)

Mint Address: 295DTMWYjrVwFqRDtmCh386gfHzj3EtVtFVUQtAdRoed
Extension: Non-transferable

The Command

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

Decimals 0, supply 1. A certificate of completion that can never leave the wallet it's minted to.

The Proof: Breaking It on Purpose

I pre-created a recipient's token account (so the transfer would actually reach the program), then tried to send my badge:

$ spl-token transfer 295DTMWYjrVwFqRDtmCh386gfHzj3EtVtFVUQtAdRoed 1 \
  9YCJgq52Msb8tehyyokP5YNhkv2cGK2Bd83aAtwjFUdy --allow-unfunded-recipient

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

Transfer is disabled for this mint — error 0x25 (decimal 37). The Token-2022 program itself refused the instruction. Not my code. Not an API layer. The validator rejected it at the protocol level.

When Would You Use This?

Proof-of-attendance tokens, certification badges, reputation scores, KYC stamps — any asset that should be permanently bound to its holder and never tradeable.

The Extension Map

Here's the full audit across all three mints:

Mint	Extensions	Behavior
`WjbwpciS...9Dp`	Transfer Fees	Charges 1% on every move
`GS7JaVub...maL`	Transfer Fees + Interest-Bearing	Charges 1% + accrues 50% APR display interest
`295DTMWY...oed`	Non-Transferable	Cannot be sent, sold, or moved. Ever.

What Surprised Me

The biggest thing I didn't expect was how composable extensions are. Stacking transfer fees and interest on one mint felt like adding two Express middlewares to a route — they don't interfere with each other, and the runtime handles the ordering.

The non-transferable extension was the most visceral. Seeing the validator print Transfer is disabled for this mint and reject your instruction at the protocol level hits differently than a 403 from an API. There's no backdoor. There's no admin panel. The rule lives in the bytes of the mint account, readable by anyone, enforceable by the network.

After building these three mints, the biggest takeaway for me is that Token-2022 turns token behavior into configuration rather than application logic. Instead of writing separate smart contracts for fees, rewards, or credentials, you compose extensions directly into the mint and let the Solana runtime enforce those rules everywhere the token is used.

This post is part of my #100DaysOfSolana journey. Follow along for daily hands-on Solana experiments.

Day 49 of #100DaysOfSolana: From Minting My First NFT to Building On-Chain Collections

atharv shukla — Wed, 15 Jul 2026 11:24:04 +0000

Day 49 of #100DaysOfSolana 🚀

Over the past week, I went from knowing almost nothing about Solana NFTs to building a complete NFT collection using the Token-2022 program.

One thing completely changed my understanding:

An NFT isn't a special kind of blockchain object. It's simply a token mint configured with the right properties and extensions.

What I Built

During this NFT arc I learned how to:

✅ Mint a 1-of-1 NFT (Supply = 1, Decimals = 0)
✅ Disable the Mint Authority to permanently lock the supply
✅ Store metadata directly on-chain using the Metadata extension
✅ Create NFT collections using the Group and Member extensions
✅ Audit NFT state directly from the blockchain
✅ Update NFT metadata live on Devnet
✅ Understand the difference between on-chain metadata and off-chain images

One of my favorite moments was updating an NFT's metadata with a single command:

spl-token update-metadata <MINT> name "Field Notes"
spl-token update-metadata <MINT> rarity legendary

Watching those changes appear on Solana Explorer made me realize that NFTs aren't static JPEGs—they can be programmable digital assets.

Biggest Takeaway

Coming from Web2, I expected NFTs to require complicated smart contracts.

Instead, I discovered that Solana's Token Extensions (Token-2022) provide many advanced capabilities directly at the protocol level.

Metadata, collections, transfer rules, and many other behaviors are built into the token itself rather than implemented separately in application code.

That was probably the biggest mental shift for me.

Read the Full Technical Deep Dive

I documented everything I learned in detail here:

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

https://dev.to/atharv_shukla_f7a20a5893f/solana-nfts-without-metaplex-what-i-learned-building-nfts-with-token-extensions-28n

If you're a Web2 developer curious about how NFTs actually work under the hood on Solana, I hope it helps.

This post is part of my *#100DaysOfSolana** journey. Every day I'm learning something new about building on Solana, one challenge at a time.*

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

atharv shukla — Wed, 15 Jul 2026 11:19:22 +0000

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

Before this week, I assumed every NFT on Solana required Metaplex. After spending several days building on Devnet, I realized that isn't the whole story.

Using Token-2022 (SPL Token Extensions), I built NFTs with on-chain metadata, grouped them into collections, audited their state directly on-chain, and even updated their metadata live—all without relying on Metaplex.

This post summarizes the biggest concepts that clicked for me.

🧠 What is a Solana NFT?

Coming from Web2, I initially thought NFTs were just images stored on a blockchain.

That isn't really true.

A Solana NFT is fundamentally just an SPL Token Mint configured with a few important properties:

Supply = 1
Decimals = 0
Mint Authority disabled
Metadata attached to the mint
Optional collection membership

Think of it like a database record.

Instead of

Users
Products
Orders

you have

Mint
Metadata
Collection
Owner

The mint address acts like the primary key, while metadata and collection information provide the additional context that wallets and marketplaces use to render the NFT.

🛠️ What I Built

During this NFT arc I progressively built more complex assets.

1. A 1-of-1 NFT

The journey started with the simplest NFT possible.

spl-token create-token --decimals 0
spl-token mint <MINT> 1
spl-token authorize <MINT> mint --disable

After disabling the mint authority, no additional copies could ever be created.

2. On-chain Metadata

Next, I enabled the Token Metadata extension.

Instead of relying on separate metadata accounts, Token-2022 lets metadata live directly on the mint itself.

I added:

Name
Symbol
Metadata URI
Image
Attributes

which immediately appeared inside Solana Explorer.

3. NFT Collections

Instead of leaving NFTs independent, I grouped them into an on-chain collection.

                Solana Sketchbook
                     │
        ┌────────────┴────────────┐
        │                         │
     Sketch #1               Sketch #2

The Collection Mint stores the Group Extension, while each NFT stores a Group Member Extension pointing back to its parent collection.

This felt very similar to foreign keys in relational databases.

4. Live Metadata Updates

The most interesting experiment was updating metadata after minting.

spl-token update-metadata <MINT> name "Field Notes"

spl-token update-metadata <MINT> rarity legendary

Refreshing Solana Explorer immediately showed the updated values.

Watching blockchain data behave like editable database rows completely changed how I think about NFTs.

⚡ What Surprised Me

The biggest surprise wasn't creating the NFT.

It was realizing that the NFT itself is just structured on-chain data.

The image isn't stored on-chain.

Instead, the NFT stores a URI pointing to a JSON file.

That JSON then points to the actual image.

NFT

↓

Metadata URI

↓

metadata.json

↓

Image URL

Changing the metadata happens immediately because it's stored on-chain.

Changing the image may take longer because wallets cache the off-chain assets.

That distinction between on-chain state and off-chain resources was probably the biggest lesson from this week.

🚀 What's Next?

Now that I understand how NFTs are built with Token Extensions, I'd like to explore more advanced functionality such as:

Transfer Hooks
Royalty enforcement
Programmable NFTs
Metaplex Core
Dynamic game assets

I'm particularly interested in seeing how these extensions can be combined to build gaming assets, memberships, and digital credentials.

Final Thoughts

This week completely changed my understanding of Solana NFTs.

Instead of thinking of NFTs as "JPEGs on the blockchain," I now think of them as programmable digital assets whose behavior and metadata are stored directly on-chain.

That mental model feels much closer to how software engineers already think about data structures and databases.

This post is part of my #100DaysOfSolana journey.

title: "3 Things That Changed How I Think About Solana Tokens"

atharv shukla — Wed, 15 Jul 2026 09:05:09 +0000

3 Things That Changed How I Think About Solana Tokens

Over the past week, while exploring Solana's Token-2022 Program, I realized that tokens can represent much more than digital currencies.

Here are the three biggest lessons that changed how I think about blockchain assets.

1. Tokens Can Behave Like Savings Accounts

Using the Interest-Bearing Extension, I created a token whose displayed balance grows over time without changing the raw on-chain balance.

Instead of constantly minting new tokens, wallets calculate the interest-adjusted balance using the interest rate and elapsed time.

This felt much closer to how modern banking applications display accrued interest.

2. Tokens Can Enforce Compliance

One extension that really surprised me was Default Account State.

By configuring new token accounts to start in the Frozen state, nobody could receive or transfer tokens until the account was explicitly approved.

This is exactly how regulated financial systems and KYC workflows operate.

3. Credentials Don't Have to Be Tradable

The most interesting experiment was combining:

Non-Transferable
Permanent Delegate
Metadata

to build a revocable digital credential.

The credential:

belongs permanently to one wallet,
cannot be transferred,
can still be revoked by the issuing authority.

This models real-world certificates, employee badges, and professional licenses surprisingly well.

Biggest Takeaway

Before this week, I thought blockchain tokens were simply balances stored on-chain.

Now I see them as programmable digital assets capable of representing financial products, regulated assets, memberships, and digital identities.

That completely changed how I think about Web3 development.

If you're interested in the technical implementation, CLI commands, and extension configurations, I documented everything in my full deep dive:

👉 Beyond Simple Transfers: 3 Solana Token Extension Patterns I Built This Week

atharv shukla

Jul 15

Beyond Simple Transfers: 3 Solana Token Extension Patterns I Built This Week

#solana #blockchain #web3 #learning

3 min read

Part of my #100DaysOfSolana journey.

Beyond Simple Transfers: 3 Solana Token Extension Patterns I Built This Week

atharv shukla — Wed, 15 Jul 2026 08:56:25 +0000

Beyond Simple Transfers: 3 Solana Token Extension Patterns I Built This Week 🚀

When most developers think about blockchain tokens, they imagine simple assets that move freely between wallets. That's how ERC-20 tokens work, and it's what I initially expected when I started learning Solana.

This week, while exploring Solana's Token-2022 Program, I realized that tokens can behave much more like real-world financial assets and digital credentials. Instead of writing custom smart contracts for every rule, Solana lets you configure those rules directly into the token itself.

Over the past few days, I experimented with three different Token Extension patterns that solve real-world problems.

1. Interest-Bearing Tokens

Think about a savings account.

Your bank doesn't constantly mint new money into your account every second. Instead, it stores your balance and calculates accrued interest whenever you view it.

Solana's Interest-Bearing Extension follows a similar idea.

The raw token balance never changes on-chain. Instead, the mint stores:

Interest rate
Initialization timestamp

Wallets calculate the displayed balance dynamically using those values.

Creating an interest-bearing token

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

Later, I updated the rate to make the effect more visible.

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

This taught me that Solana separates the ledger balance from the displayed balance, making continuous compounding possible without constantly modifying account balances.

2. Compliance-Gated Tokens (Default Frozen)

Not every asset should be usable immediately.

Think about:

Bank accounts
Brokerage accounts
KYC verification
Employee onboarding

New users often need approval before they can transact.

Using the Default Account State extension, every newly created token account starts in a Frozen state.

Only the Freeze Authority can approve (thaw) the account.

Creating the mint

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

Trying to mint immediately resulted in:

Error: Account is frozen

After thawing the account,

spl-token thaw <TOKEN_ACCOUNT>

minting succeeded normally.

This pattern maps directly to regulated financial systems where accounts must pass compliance checks before becoming active.

3. Revocable Digital Credentials

This became my favorite Token-2022 pattern.

Imagine issuing:

University degrees
Employee ID cards
Professional certifications
DAO membership badges

These credentials should:

belong permanently to one person
never be transferable
still be revocable by the issuer

To achieve this, I combined three extensions:

Non-Transferable
Permanent Delegate
Metadata

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

The Non-Transferable extension prevents the holder from transferring the credential.

The Permanent Delegate allows the issuer to revoke the credential by burning it directly from the holder's account.

The Metadata extension stores human-readable information such as:

Credential name
Symbol
Metadata URI

Together, these extensions model how real-world certifications work.

What Surprised Me

The biggest surprise wasn't the extensions themselves.

It was realizing that Solana treats token behavior as protocol-level configuration rather than application logic.

In a traditional Web2 application, these features would require:

Backend APIs
Databases
Scheduled jobs
Access-control middleware

With Token-2022, they're enforced directly by the blockchain.

Storage Isn't Free

Every extension adds extra data to the mint account.

That means:

Larger account size
Higher rent-exempt deposit
More features
Slightly higher creation cost

For example, I observed that:

Interest-bearing tokens used less storage than multi-extension tokens.
Tokens combining metadata, transfer fees, and interest required significantly larger mint accounts.

It's a useful reminder that protocol features come with storage costs.

Final Thoughts

Before this week, I thought blockchain tokens were simply balances stored on-chain.

After experimenting with Token-2022, I now see them as programmable digital assets that can model real-world business rules:

Savings accounts
Regulated financial assets
Employee credentials
University certificates
Loyalty programs

without writing custom smart contracts.

Token Extensions have completely changed how I think about token design on Solana.

If you're starting with Solana development, I highly recommend experimenting with Token-2022. Building these examples yourself makes the concepts much easier to understand than simply reading the documentation.

Resources

This post is part of my #100DaysOfSolana journey.

Day 35 of #100DaysOfSolana: The Moment Token-2022 Finally Clicked

atharv shukla — Wed, 15 Jul 2026 07:53:37 +0000

This week, I explored Solana's Token-2022 program by building custom SPL tokens with metadata, protocol-level transfer fees, and non-transferable (Soulbound) extensions using the Solana CLI.

Out of everything I built this week, one moment stood out.

The Experiment

After creating a non-transferable (Soulbound) token, I generated a second wallet and attempted to transfer the token.

Instead of succeeding, the blockchain rejected the transaction with the following message:

Program log: Transfer is disabled for this mint

That single line completely changed how I think about blockchain applications.

The Biggest Lesson

Coming from a Web2 background, I'm used to enforcing rules through:

Backend APIs
Database constraints
Frontend validation

On Solana, Token-2022 lets the asset itself define its behavior.

A non-transferable token doesn't rely on an application deciding whether a transfer is allowed. The Token-2022 program enforces the rule directly at the protocol level, meaning every wallet, application, and SDK automatically follows it.

That distinction between application-layer logic and protocol-layer logic was the biggest takeaway from this week's learning.

What's Next?

Next, I'll be implementing these same token interactions using:

@solana/web3.js
@solana/spl-token

before moving into on-chain development with Anchor Framework.

I also documented my complete journey—from creating my first token mint to experimenting with metadata, transfer fees, and Soulbound tokens—in my previous article:

👉 https://dev.to/atharv_shukla_f7a20a5893f/from-setup-to-soulbound-tokens-my-journey-into-solana-token-extensions-393m

Thanks for following along!

100DaysOfSolana

From Setup to Soulbound Tokens: My Journey into Solana Token Extensions

atharv shukla — Wed, 15 Jul 2026 07:43:30 +0000

Building on Web2 platforms usually means accepting the constraints of databases you don't control and rules enforced by someone else’s application logic. But what happens when the logic lives on the protocol level, and you hold the keys?

Over the past week, as part of my #100DaysOfSolana journey, I’ve gone from installing the Solana CLI to creating custom tokens with built-in metadata, permanent transfer fees, and even non-transferable "Soulbound" credentials. This is a look at what I built, how it works, and what surprised me along the way.

Context: Why Solana Token Extensions?

Before diving in, I assumed creating a token on a blockchain was as simple as writing a smart contract and deploying it. But on Solana, things work a bit differently. Instead of every developer writing their own custom smart contracts for tokens (like ERC-20 on Ethereum), Solana uses a standardized program called the SPL Token Program.

The Token Extensions Program (commonly called Token-2022) is an upgraded version of the original SPL Token Program that adds protocol-level features like metadata pointers, transfer fees, confidential transfers, and non-transferable (soulbound) tokens. I spent my week exploring exactly what this new program can do.

The Walkthrough: Building the Tokens

Here is a breakdown of the core token features I built using the Solana CLI and the Token Extensions program.

The Foundation: Minting My First Token

Before getting into the fancy extensions, I needed to understand the basics. In Solana, a Mint is the blueprint for a token. It doesn't hold tokens; it simply defines them.

Using the CLI, creating a mint on Devnet was incredibly fast:

spl-token create-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

Notice the --program-id Tokenz... flag? That tells the network to use the new Token-2022 program instead of the legacy SPL Token Program.

Giving it an Identity: The Metadata Extension

A token is just a string of numbers until you give it a name and a logo. Previously, metadata on Solana required interacting with a completely separate program (Metaplex). With Token-2022, you can embed metadata pointers directly into the token mint itself.

spl-token initialize-metadata <MINT_ADDRESS> "My Awesome Token" "MAT" "https://my-metadata-url.json"

This single command gave my token a name, ticker symbol, and a pointer to off-chain JSON metadata. No additional smart contracts were required.

Enforcing Economics: The Transfer Fee Extension

This is where things became really interesting.

In traditional finance or gaming platforms, operators often take a small percentage from every transaction. On a blockchain, however, users can transfer assets directly between wallets without any middleman.

Using the Transfer Fee Extension, I configured my token to automatically deduct a 50 basis point (0.5%) fee on every transfer while also setting a maximum fee limit.

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --transfer-fee 50 50000

The most impressive part was that this rule is enforced by the blockchain itself—not by a website or frontend application. Every wallet or application interacting with the token must respect the transfer fee because it is part of the token's protocol-level behavior.

Digital Credentials: The Non-Transferable Extension

Finally, I experimented with Soulbound Tokens.

In Web2, things like verification badges, employee IDs, and course certificates stay attached to your account. They aren't supposed to be sold or transferred.

The Non-Transferable Extension brings the same concept to blockchain assets.

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

I minted a few tokens and then attempted to transfer them to another wallet.

Instead of succeeding, the network rejected the transaction with the following message:

Program log: Transfer is disabled for this mint

That failure was actually the success of the experiment.

Unlike a frontend validation or backend API check, this restriction exists directly inside the Token-2022 program itself. No wallet, application, or script can bypass it.

Interestingly, although transfers are blocked, the token owner can still burn (destroy) the token if they choose. This makes it perfect for credentials such as:

University certificates
KYC verification badges
Event participation NFTs
Employee IDs
Membership credentials

What Surprised Me

The biggest "aha!" moment for me was understanding the difference between application-layer logic and protocol-layer logic.

As a Web2 developer, I'm used to enforcing rules through backend APIs, databases, and frontend validation. If I don't want users to transfer something, I simply disable the button or reject the API request.

On Solana, things work very differently.

By enabling a single flag during token creation, the blockchain itself becomes responsible for enforcing the rule. Every application, wallet, explorer, and SDK automatically follows the same behavior because the rule is part of the token's definition—not the application's implementation.

It completely changed the way I think about where business logic should live.

What's Next?

Building everything through the CLI gave me a solid understanding of how accounts, token mints, and extensions actually work under the hood.

My next goal is to move these concepts into JavaScript using:

@solana/web3.js
@solana/spl-token

I want to build a frontend application where users can create and interact with custom Token-2022 assets directly from their browser.

A week ago, terms like Mint, Metadata Pointers, and Token-2022 were simply buzzwords to me.

After building these tokens myself, I now understand that Solana isn't just about creating cryptocurrencies—it's about creating programmable digital assets whose behavior is enforced directly by the blockchain itself.

That shift in perspective has been one of the most valuable lessons I've learned during this journey, and I'm excited to keep building.

Helpful Resources

Solana Tokens: https://solana.com/docs/core/tokens
Token Extensions (Token-2022): https://solana.com/docs/core/tokens/token-2022
SPL Token CLI: https://spl.solana.com/token

This post was created as part of the #100DaysOfSolana challenge.

Day 27: Writing About the Solana Account Model

atharv shukla — Tue, 30 Jun 2026 10:45:29 +0000

Today, I took a step back from writing code to write about the core architectural foundation of Solana: The Account Model. To solidify my understanding, I wrote a comprehensive article aimed at Web2 developers who are new to blockchain, explaining how Solana manages state.

Below is the draft of the article, formatted for publishing on DEV.to.

DEV.to Article Draft

Title: Demystifying the Solana Account Model: A Guide for Web2 Developers
Tags: solana, blockchain, web3, beginners

If you are a Web2 developer dipping your toes into the Web3 waters, blockchain architecture can feel incredibly alien. You hear terms like "smart contracts," "state," and "ledgers," and you try to map them to things you know.

If you look at Ethereum, it might make sense at first: it uses an Account-based model where you have Externally Owned Accounts (EOAs, like your MetaMask wallet) and Contract Accounts (which contain both the code and the state/variables of a smart contract). This feels a bit like Object-Oriented Programming, where an object contains both its methods (code) and its properties (state).

But then you look at Solana, and everything you thought you understood gets flipped on its head.

On Solana, programs are completely stateless, and everything is an account.

Let's break down Solana’s Account Model using Web2 concepts you already use daily.

The Ultimate Analogy: Solana as a Filesystem

The easiest way to understand Solana's account model is to think of the entire blockchain as a global, decentralized filesystem.

The Ledger is the Hard Drive: A massive, shared storage space.
Accounts are Files: Every piece of information on Solana lives inside an "account," which acts just like a file.
Public Keys are File Paths: Every account has a unique 32-byte address (like BPFLoaderUpgradeab1e11111111111111111111111 or a wallet address). Think of this public key as the absolute path to the file (e.g., /users/alice/data.json).
The System Program is the OS Kernel: The underlying operating system kernel that manages file creation, allocating size, and assigning permissions.

Just like a file on your computer has metadata (file size, owner, read/write permissions) and file contents, a Solana account contains metadata and a raw byte array for data.

The Anatomy of an Account: The 5 Fields

Every single account on Solana shares the exact same basic structure. When you query an account using the Solana command-line interface (solana account <ADDRESS>), the JSON response reveals five main fields:

json
{
"pubkey": "3zcpeKkCFg1z3sR1u1qQcm6h4n5t282a5cQ5bX2gYp3Z",
"account": {
"lamports": 124806720,
"data": ["...", "base64"],
"owner": "BPFLoaderUpgradeab1e11111111111111111111111",
"executable": true,
"rentEpoch": 18446744073709551615
}
}

Let's unpack what these fields represent:

lamports (The SOL Balance): A lamport is the smallest fractional unit of SOL, named after Leslie Lamport (think of it like a Satoshi for Bitcoin or a Wei for Ethereum). 1 SOL = 1,000,000,000 lamports. This balance is used to pay for storage and transaction fees.
data (The File Contents): A raw byte array (Vec<u8>) containing the actual state stored by this account. For a wallet account, this might be empty. For a database account, it contains serialized variables.
owner (The File Owner/Permissions): This is the public key of the program that controls this account. Crucially, only the owner program is allowed to modify the account's data or deduct its lamport balance.
executable (Is it an App or a Document?): A boolean flag. If true, this account contains compiled WebAssembly/SBF bytecode that the Solana runtime can run. It is a program (smart contract). If false, it's just a data storage account.
rent_epoch (Storage Rent): Historically used to track rent collections. Today, rent is deprecated because all accounts are required to be "rent-exempt" (more on this below). It is now set to a placeholder max value (18446744073709551615).

Programs Don't Store State (Stateless Architecture)

In Web2, if you write a Node.js express server, the code is loaded into memory, and it might read/write from a local Postgres database. The server code itself doesn't dynamically change its own binary files on disk to save user data; it talks to an external database.

Solana works the exact same way. Solana programs are stateless.

On Ethereum, a smart contract's code and its variables are packed together in the same contract account. On Solana, they are strictly separated:

mermaid
graph TD
subgraph Program Account
A[Program ID / Proxy Address] -->|Executable: true| B[Program Data Account: Bytecode]
end

subgraph Data Accounts
    C[User Wallet Account A]
    D[User Wallet Account B]
    E[Protocol Configuration Account]
end

B -->|Reads/Writes Data| C
B -->|Reads/Writes Data| D
B -->|Reads/Writes Data| E

For example, the Token-2022 Program (TokenzQdBNbXt8TuTRCEjrpb5764uWo1tz5SQH376BB) contains the executable logic for minting and transferring tokens. But it doesn't store your token balance. Instead, your balance is stored in a separate Token Account owned by the Token-2022 program, which holds data indicating: "This wallet address owns X amount of this token."

The Rules of Ownership: Solana's Security Model

How does Solana ensure someone doesn't just write a malicious script to change another user's balance? Through strict runtime ownership rules:

Only the Owner Program can write to the account data.
Only the Owner Program can deduct lamports (debit) from the account.
Anyone can credit lamports to any writable account (just like anyone can transfer money to your bank account).
Anyone can read any account's data. All accounts are public by default.

If Program A tries to modify an account owned by Program B, the Solana runtime rejects the transaction immediately. This simple rule eliminates a massive class of security vulnerabilities.

Rent Exemption: Keeping the Ledger Lean

In Web2, if you rent an AWS EC2 instance or store files in an S3 bucket, you pay a recurring subscription. If you stop paying, AWS deletes your files.

Solana handles blockchain storage in a similar way. Because validators must keep all active accounts in memory (RAM) for fast transaction processing, storage isn't free.

To prevent the blockchain from being filled with abandoned accounts, Solana requires accounts to maintain a minimum lamports balance. This is called being Rent-Exempt.

The rent-exempt balance is directly proportional to the size of the account's data array.
For a basic wallet account with zero data bytes, the rent-exempt minimum is roughly 0.00089 SOL.
When you close a Solana account, you can reclaim all the rent lamports back into your main wallet! It's like getting a deposit refund on a rental apartment.

Summary

As a Web2 developer, you can master the Solana Account Model by keeping these four rules in mind:

Everything is a file (account) in a flat key-value store.
Metadata is standardized across all files (Lamports, Data, Owner, Executable).
Programs are stateless executables; they read and write to separate database files (data accounts).
Ownership is absolute; only the program marked as the owner can modify a file's contents or spend its funds.

Understanding this separation of code and state is the "aha!" moment for every Solana developer. Once you grasp this, building decentralized applications, understanding PDA (Program Derived Addresses) generation, and writing efficient Anchor programs starts to make perfect sense!

Have questions about how accounts work on Solana? Drop a comment below, and let's discuss!

Solana Transactions Explained for Backend Developers

atharv shukla — Tue, 30 Jun 2026 08:41:51 +0000

If you're coming from a Web2 backend background, your mental model of APIs is probably built on the standard HTTP client-server pattern: client makes a request, the database runs a transaction, and you return a status code.

When diving into Solana, you quickly run into a lot of the same terms—like "transactions"—but the actual execution under the hood is very different. Here's a quick guide on how Solana transactions actually work, what's inside them, and a few things that caught me off guard.

Anatomy of a Solana Transaction : An HTTP request is usually headers and a JSON body. A Solana transaction is a packed binary payload that cannot exceed 1,232 bytes (this limit exists so transactions can fit cleanly into a single IPv6 packet).

Inside that byte limit, a transaction contains:

Signatures: Cryptographic proof from the accounts authorizing the action.
Message: The instructions and context, which includes:
- Account Keys: Every single account the transaction will read from or write to. Solana needs this declared upfront so it can parallelize execution.
- Recent Blockhash: A hash from a recent block. This acts as a timestamp and prevents replay attacks. If the blockhash is too old (usually over 150 blocks, or about a minute), the transaction expires.
- Instructions: The actual operations to execute. Each instruction specifies an on-chain program (like calling a controller method) and passes along the necessary accounts and raw data.

The Transaction Lifecycle In Web2, a database transaction is either committed or it isn't. On a blockchain, consensus is reached in stages:
Processed: A single validator has included the transaction in a block.
Confirmed: A supermajority (66%+) of validators have voted on the block. At this point, the transaction is functionally irreversible.
Finalized: 31 or more blocks have been built on top of your block. The write is permanently locked into ledger history.

You can think of this as moving from a local write, to multi-region replication, to an immutable backup.

Failed Transactions Still Cost Fees This is the biggest shift. In Web2, if a request fails validation (say, a 400 Bad Request), you don't get billed for the server CPU cycles it took to reject the request.

On Solana, failed transactions still charge fees.

If your signatures are valid and the blockhash is recent, validators will execute your transaction. Even if the program logic fails halfway through (e.g. you tried to transfer more SOL than you actually have), you still pay for the compute.

Here is what it looks like when a transaction fails on-chain:

text
Transaction executed:
Signature: 5LseX35v...K4KgG7
Status: Error processing Instruction 0: custom program error: 0x1
Fee: 0.000005 SOL
Account 0 balance: 0.428975 SOL -> 0.42897 SOL
Compute Units Consumed: 150
Log Messages:
Program 11111111111111111111111111111111 invoke [1]
Transfer: insufficient lamports 428970000, need 500000000000
Program 11111111111111111111111111111111 failed: custom program error: 0x1

Notice that the fee-payer's balance still decreased by 0.000005 SOL even though the transfer failed.

To avoid wasting real money on failed execution, Web3 developers use Transaction Simulation (preflight checks) on the client side to test the transaction's success on a local state before broadcasting it to the network.

Key Takeaways
No ad-hoc lookups: You cannot query arbitrary accounts mid-transaction; every address you interact with must be declared in your instructions.
Keep it fast: Because of the recent blockhash requirement, signed transactions expire in about a minute.
Preflight is your friend: Run simulations on the RPC node first to save your users from paying fees on failed transactions.