DEV Community: Jay Gurav

What I Learned About Token Design on Solana as a Web2 Developer

Jay Gurav — Sun, 24 May 2026 16:27:13 +0000

*From Minting Tokens to Building Soulbound Credentials on Solana
*
Coming from a traditional Web2 development background, I always thought digital assets were just database entries controlled by backend APIs. But after spending several days building on Solana, I realized blockchain changes the entire approach to ownership, permissions, and trust.

Over the past few days, I explored token creation, metadata, transfer fees, and even non-transferable (soulbound) tokens using Solana’s Token Extensions Program. In this post, I’ll share what I built, what surprised me, and why Solana’s token ecosystem feels much more powerful than I initially expected.

🌍 My Starting Point

Before this journey, my experience was mostly focused on:

HTML/CSS/JavaScript
PHP & MySQL
Python scripting
Cybersecurity projects
Web2 application development

I had heard terms like:

SPL Tokens
Token Metadata
Soulbound Tokens
Token Extensions

…but I never truly understood how they worked internally.

My goal was simple:

Learn how tokens actually work on-chain by building them myself.

⚡ Why Solana Token Extensions Matter

One of the biggest things I learned is that Solana now supports advanced token functionality directly at the protocol level using the Token Extensions Program.

Instead of relying only on application logic, features can now be enforced directly on-chain.

That means:

✅ Transfer fees
✅ Permanent delegates
✅ Metadata
✅ Non-transferability
✅ Interest-bearing tokens

…can all exist natively inside the token itself.

This felt very different from Web2 systems where rules are usually enforced by backend servers.

🪙 Creating My First Token

The first thing I did was create a token mint on Solana.

I installed the Solana CLI and SPL Token CLI tools and connected to Devnet.

solana config set --url devnet

Then I created my wallet:

solana-keygen new

Airdropped SOL for testing:

solana airdrop 2

And finally created a token:

spl-token create-token

After that, I created an associated token account:

spl-token create-account

Then minted tokens:

spl-token mint 1000

Seeing my own token exist on-chain for the first time was honestly exciting.

📝 Adding Metadata to the Token

A token without metadata is difficult to recognize.

So I learned how metadata works using Metaplex standards.

I added:

Token Name
Symbol
Description
Image URI This made the token display properly inside wallets and explorers.

Example metadata:

{
"name": "JayToken",
"symbol": "JAY",
"description": "My first Solana token",
"image": "https://example.com/token.png"
}

This helped me understand how wallets identify and display assets visually.

💰 Exploring Transfer Fees

This was one of the most interesting parts.

Using Token Extensions, I created tokens that automatically charge fees during transfers.

In Web2, this would require backend logic.

But on Solana, the blockchain itself enforces the rule.

That means nobody can bypass it.

Example concept:

User sends 100 tokens
Receiver gets 98
2 tokens become fees

This opened my mind to how DeFi systems automate economics directly in protocol design.
**
🔒 Soulbound (Non-Transferable) Tokens
**
The most fascinating concept I explored was non-transferable tokens.

These are tokens that:

✅ Can be received
❌ Cannot be transferred

They work perfectly for:

Academic certificates
Digital IDs
Event participation badges
Skill verification
DAO reputation systems

This instantly reminded me of real-world credential systems.

Imagine universities issuing permanent blockchain-based certificates that cannot be sold or transferred.

That’s powerful.

🤯 What Surprised Me the Most

Blockchain Rules Are Enforced at the Lowest Level

In Web2:

Backend validates actions
Users trust servers

In Solana:

The blockchain validates actions
Rules are immutable

That difference completely changed how I think about application design.

Token Extensions Are Extremely Flexible

I originally thought tokens were just balances.

But Solana tokens can actually contain programmable behavior.

That makes them more like smart financial objects rather than simple currencies.

Debugging Was Harder Than Expected

Not everything worked perfectly.

I faced issues like:

Incorrect wallet configuration
Devnet connection problems
Missing token accounts
Metadata upload errors

But solving those problems helped me understand the ecosystem much better.

📚 Key Things I Learned

By the end of this journey, I learned:

✅ How Solana wallets work
✅ How token minting works
✅ Difference between Token Program and Token Extensions
✅ How metadata is attached
✅ Why transfer fees matter
✅ How soulbound tokens work
✅ How blockchain enforces rules automatically

🔗 Helpful Resources

Here are some resources that helped me:

Solana Docs
SPL Token Documentation
Token Extensions Guide
Metaplex Documentation

🚀 What’s Next

Next, I want to build:

DAO-based systems
Decentralized identity platforms
Web3 credential verification
DeFi applications on Solana
Full-stack dApps with wallet integration

I’m also interested in combining blockchain with cybersecurity and authentication systems.

*🎯 Final Thoughts
*
This experience completely changed how I view digital ownership and application design.

Building tokens on Solana taught me that blockchain is not just about cryptocurrency — it’s about programmable trust.

As a developer coming from Web2, learning Solana felt challenging at first, but incredibly rewarding once the concepts started connecting together.

If you’re a beginner thinking about exploring Web3 development, my advice is simple:

Start building. The best way to understand blockchain is by creating something on-chain yourself.

100DaysOfSolana #solana #blockchain #webdev

Day 28 of #100DaysOfSolana 🚀

Jay Gurav — Mon, 18 May 2026 13:32:54 +0000

Exploring Solana Devnet Transactions Using Solana Explorer

As part of my #100DaysOfSolana journey, today I explored Solana block explorers and inspected my own Devnet wallet activity using Solana Explorer.

I analyzed:

Wallet balances
Transaction history
System Program transfers
On-chain account details
Instruction-level transaction data

One thing I found really interesting was how Solana Explorer exposes detailed transaction information such as program invocations, execution results, and instruction logs. It feels very similar to using browser DevTools, but for blockchain debugging.

The transparency of on-chain data makes it much easier to understand how Solana accounts and transactions work internally.

Explorer Used:
Solana Explorer

Wallet Address:
Fd2gNkVgTRsfHRWWviq3hPApTDMHtYHhMfzSLX99P8N2

Solana #Web3 #Blockchain #Devnet #100DaysOfSolana

Understanding Solana’s Account Model: A Beginner-Friendly Guide for Web2 Developers

Jay Gurav — Sun, 17 May 2026 12:13:53 +0000

If you’re coming from a Web2 development background, Solana’s account model can feel confusing at first.

When most developers hear the term “blockchain account,” they usually think about wallets holding cryptocurrency. But in Solana, accounts are much more than wallets.

On Solana, everything is an account.

Wallets are accounts.
Programs are accounts.
NFT metadata is stored in accounts.
Token balances are stored in accounts.

At first this sounds strange, but once you understand the account model, the entire Solana ecosystem starts making sense.

In this article, I’ll explain Solana’s account model in simple terms using Web2 analogies so that even if you’ve never touched blockchain before, you’ll understand the fundamentals.

What Makes Solana Different?

Many developers first learn blockchain through Ethereum.

Ethereum separates:

Externally Owned Accounts (EOAs)
Smart Contract Accounts

Solana takes a different approach.

Instead of multiple account types, Solana uses a single unified account model.

Everything lives inside accounts stored in a massive distributed key-value database.

Think of it like this:

Key	Value
Public Address	Account Data

Each account has:

a unique address
stored data
ownership rules
permissions

This design is one of the reasons Solana is fast and scalable.

A Simple Web2 Analogy

The easiest way to understand Solana accounts is to compare them to a filesystem.

Think about your operating system.

You have:

executable files
documents
folders
permissions
ownership metadata

Solana works similarly.

Web2 Filesystem	Solana
File	Account
Executable Program	Program Account
Database/Data File	Data Account
Operating System Kernel	System Program

Programs read and modify data accounts just like backend applications interact with databases.

This analogy helps explain one of Solana’s most important ideas:

Programs do not store their own state.

We’ll come back to that shortly.

The Structure of Every Solana Account

Every Solana account contains the same five fields.
These fields define how the account behaves.

1. Lamports

Lamports are the smallest unit of SOL.

1 SOL=1,000,000,000 lamports

Just like:

1 dollar = 100 cents
1 bitcoin = 100 million satoshis

Solana uses lamports for precision.

The lamports field stores the account balance.

Lamports are used for:

paying transaction fees
transferring SOL
maintaining rent exemption

*2. Data
*
The data field stores arbitrary bytes.

This is where applications store information such as:

token balances
NFT metadata
DeFi protocol state
user profiles
staking information

Programs read and write this data during execution.

Unlike traditional databases, the data is stored directly on-chain.

3. Owner

The owner field is extremely important in Solana.

It specifies which program controls the account.

Only the owner program can:

modify the account’s data
debit lamports from the account

This creates a strong security model.

For example:

token accounts are owned by the Token Program
system wallets are owned by the System Program

Ownership ensures programs cannot randomly modify accounts they do not control.

4. Executable

This is a simple boolean flag.

true → the account contains executable program code
false → the account stores regular data

Program accounts are basically Solana smart contracts.
Most accounts on Solana are non-executable data accounts.
**

Rent Epoch**

Historically, Solana charged rent for storing data on-chain.

The rent_epoch field tracked rent collection.

Today this field is deprecated and usually set to the maximum value.

Most developers ignore it now, but it still exists in the account structure.

Programs Don’t Store Their Own State

This is the concept that surprises most Web2 developers.

In Ethereum:

contracts store logic and state together

In Solana:

programs are stateless
data lives in separate accounts

Think about a traditional backend application.

Your:

backend server contains logic
database stores data

That’s exactly how Solana works.
| Web2 Backend | Solana |
| ------------ | ------------- |
| API Server | Program |
| Database | Data Accounts |

Programs process instructions and update external accounts rather than storing everything internally.

This separation allows Solana to process transactions in parallel, which greatly improves scalability and performance.

Why Solana Separates Programs and Data

This architecture provides several advantages.

Parallel Processing

Because accounts are separate, Solana can process multiple transactions simultaneously if they touch different accounts.
This is a major reason why Solana achieves high throughput.

Better Security

Ownership rules prevent unauthorized modification of accounts.
Programs can only modify accounts they own.
This creates very clear security boundaries.

Flexibility

Programs can interact with many independent data accounts.
This makes Solana applications modular and efficient.

Ownership Rules Explained
Solana’s ownership model is simple but powerful.
Rule 1:
Only the owner program can modify account data.
Rule 2:
Only the owner program can debit lamports.
Rule 3:
Anyone can send lamports to any writable account.
These rules help maintain security and predictable behavior across the network.

*Rent Exemption
*
Since storing data on-chain consumes validator resources, Solana requires accounts to maintain a minimum balance.

This is called being rent exempt.

The required amount depends on the account’s data size.

For small accounts, it is approximately:

≈0.00089 SOL

You can calculate exact rent-exempt balances using:

solana rent
getMinimumBalanceForRentExemption If an account does not maintain sufficient balance, it may eventually be removed from the network.

This mechanism prevents blockchain storage spam.

Example: Viewing an Account in Solana CLI

You can inspect accounts directly using the Solana CLI.

solana account

Example output:

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

Let’s break this down:

Field	Meaning
lamports	Account balance
owner	Controlling program
executable	Whether it’s a program
data	Stored bytes
rentEpoch	Deprecated rent field

This single structure powers nearly everything on Solana.

Real-World Examples of Accounts

Here are some examples of accounts you interact with daily on Solana.

Account Type	Purpose
Wallet Account	Holds SOL
Token Account	Stores SPL tokens
NFT Metadata Account	Stores NFT information
Program Account	Stores executable smart contract code
PDA (Program Derived Address)	Stores program-controlled state

Everything eventually comes back to accounts.

Why Understanding Accounts Matters

The account model is the foundation of the Solana ecosystem.

Whether you’re building:

DeFi applications
NFT marketplaces
DAOs
blockchain games
staking protocols

you’ll constantly work with:

accounts
ownership
stored data
permissions

Understanding accounts is essential for becoming a Solana developer.

Final Thoughts

At first, Solana’s architecture can feel unfamiliar, especially if you come from Web2 or Ethereum development.

But once you stop thinking about Solana as “just another blockchain” and start thinking about it like a distributed operating system, the design becomes much easier to understand.

Programs act like backend services.
Accounts act like files or databases.
Ownership rules act like permissions.

And together, they create one of the fastest blockchain architectures in the industry.

Learning the account model is the first major step toward understanding how Solana really works.

solana#100DaysOfSolana#web3

🚀 Day 10 of #100DaysOfSolana

Jay Gurav — Mon, 11 May 2026 16:08:30 +0000

Built a CLI-based Solana Transfer Tool using Node.js and @solana/web3.js that sends SOL transactions directly on Solana Devnet.

⚡ What the tool does:
• Accepts recipient wallet + amount as command-line arguments
• Connects to Solana Devnet
• Signs transactions using a wallet keypair
• Confirms and returns a live transaction signature

One of the biggest things I learned while building this project was how Solana transactions are structured internally — especially recent blockhashes, fee handling, and transaction signing using cryptographic keypairs.

🖥️ Demo Screenshot:

🔗 Verified Devnet Transaction:
https://explorer.solana.com/tx/55LmbhsqTsM6anvDGnAHYdbgMzcnrsWZt7Gg5XvjhqKEbsVJazbJuiFbYcqhsyKtGK4Z2k2oJZgajo6t4mZHBDrm?cluster=devnet

Really enjoying the journey of learning Solana development and building real blockchain tools in public 🔥

Solana #Web3 #Blockchain #NodeJS #Crypto #Developer #BuildInPublic #100DaysOfSolana

Solana Transactions Explained for Backend Developers

Jay Gurav — Sat, 09 May 2026 14:05:23 +0000

When I first started learning Solana, transactions felt very different from the request/response flow I was used to in Web2 development.

In a traditional backend app, you send an HTTP request, the server processes it, and you get a response. Simple.

But on Solana, a transaction is more like a cryptographically signed database operation that gets broadcast to a distributed network of validators, executed atomically, voted on by consensus, and eventually finalized permanently on-chain.

Over the last few days, I built a CLI transfer tool, tracked transaction confirmations in real time, and even intentionally created failed transactions to understand how Solana handles errors.

This post explains the mental model shift that finally made Solana transactions click for me.

The Anatomy of a Solana Transaction

A Solana transaction contains:

Instructions
Accounts
Signatures
A recent blockhash

At first glance, this looks similar to an API request body, but there’s a major difference:

The transaction itself is signed cryptographically before it ever reaches the network.

Here’s part of the transfer tool I built:

const transactionMessage = pipe(
createTransactionMessage({ version: 0 }),
(tx) => setTransactionMessageFeePayerSigner(sender, tx),
(tx) =>
setTransactionMessageLifetimeUsingBlockhash(
latestBlockhash,
tx
),
(tx) =>
appendTransactionMessageInstruction(
getTransferSolInstruction({
source: sender,
destination: recipientAddress,
amount: transferLamports,
}),
tx
)
);

This transaction defines:

who pays the fee
which accounts are involved
what instruction should execute
which recent blockhash makes the transaction valid

Why the Recent Blockhash Exists

One thing that surprised me was that Solana transactions expire.

In Web2, if a request gets delayed, the server can still process it later.

On Solana, transactions include a recent blockhash that acts like a time window. If the network doesn’t process the transaction quickly enough, it expires automatically.

This prevents replay attacks and keeps the network efficient.

The validity window is usually around 60–90 seconds.

That means Solana transactions are not just signed requests — they are time-sensitive signed requests.

Tracking Confirmation Levels

Initially, my transfer tool used a helper that handled everything automatically.

But I later replaced it with manual transaction tracking so I could see the transaction move through Solana’s commitment levels:

Processed
Confirmed
Finalized

I added live terminal updates like this:

statusUpdate("📤 Sending transaction...");
statusUpdate("🟡 Transaction processed...");
statusUpdate("🟢 Transaction confirmed...");
statusUpdate("✅ Transaction finalized!");

This helped me understand how Solana consensus works.

Processed

A validator received and executed the transaction.

Confirmed

Most validators agreed on the block containing the transaction.

Finalized

Enough additional blocks were built afterward that the transaction became effectively irreversible.

This is very different from a simple HTTP 200 OK response.

Consensus happens in stages.

Failed Transactions Taught Me the Most

The most useful exercise was intentionally breaking transactions.

I created a script that skipped preflight checks and attempted to send an impossible amount of SOL.

The transaction failed on-chain, but the network still charged fees.

That was a huge learning moment.

Using:

solana confirm -v --url devnet

I could inspect:

error messages
compute units consumed
program logs
fee deductions
balance changes

Example failure:

InstructionError: insufficient funds

Even though the transfer failed, validators still spent compute resources processing it.

That means failed transactions still cost money.

In Web2, a failed request usually costs nothing extra.

On Solana, every transaction consumes network resources.

The Biggest Mental Shift

The biggest realization for me was this:

A Solana transaction is not just a request.

It’s an atomic state transition proposal signed by the user and executed by a decentralized runtime.

That changes how you think about application architecture.

In Web2:

Client → Server → Database

In Solana:

Client → Validators → Consensus → State Change

There’s no central server controlling execution.

The network itself becomes the execution environment.

Final Thoughts

Learning Solana transactions forced me to think differently about:

state management
trust
signatures
execution
error handling
distributed systems

What helped me most was building things manually instead of relying entirely on abstractions.

Once I started constructing transactions myself, tracking confirmations, and debugging failures, the system finally started making sense.

If you’re learning Solana, I highly recommend intentionally breaking transactions and inspecting the logs. You’ll learn far more from failures than from successful transfers.

solana #blockchain #web3 #100daysofsolana

# My Second Week in #100DaysOfSolana 🚀

Jay Gurav — Sat, 02 May 2026 12:28:36 +0000

Over the past two weeks of the #100DaysOfSolana challenge, I’ve gone from barely understanding how blockchain data works to actually interacting with on-chain accounts, reading balances, and building small applications using Solana’s SDK.

One thing that surprised me the most was how different blockchain development feels compared to traditional backend development. Before starting, I imagined blockchain data as something complicated and hidden behind smart contracts. But after working with Solana, I realized that accounts on the blockchain are more like a giant public database that anyone can read from.

The moment things really “clicked” for me was when I started fetching account information directly from the Solana network. Seeing lamports, wallet addresses, and transaction data in real time made the blockchain feel less abstract and more practical.

For example, reading wallet balances using the Solana Web3.js SDK felt surprisingly simple:

const balance = await connection.getBalance(publicKey);
console.log(balance);

At first, RPC calls were confusing. I had trouble understanding how the client communicates with validators and how data is fetched from the network. But after experimenting with different RPC methods, I started understanding how decentralized applications interact with Solana behind the scenes.

Another interesting thing was comparing blockchain accounts to traditional databases. In normal applications, we usually store data in MySQL or MongoDB and control access ourselves. On Solana, the data is public, distributed, and structured differently. That shift in thinking took some time to understand.

I’m still confused about some advanced topics like account ownership, program-derived addresses (PDAs), and how smart contracts manage state efficiently. But that’s also what excites me the most. I want to learn more about building real decentralized applications and writing on-chain programs.

So far, this journey has been challenging but really rewarding. Every day I learn something that changes the way I think about decentralized systems and Web3 development.

Solana #Web3 #Blockchain #100DaysOfSolana

Week 1 of #100DaysOfSolana has been an amazing learning experience!

Jay Gurav — Sun, 26 Apr 2026 17:46:52 +0000

This week I generated my first Solana CLI keypair, explored different wallet types, connected a browser wallet, and even built a small wallet connection app using Solana Labs tools and the Phantom wallet.

One of the biggest mindset shifts coming from Web2 was realizing that on Solana, your identity is just a cryptographic keypair. No usernames, no passwords, no centralized account system — ownership is completely tied to your private key.

I also experimented with:

Creating and managing wallets using the Solana CLI
Viewing balances in SOL and lamports
Checking transaction history on devnet
Connecting browser wallets to a frontend app
Understanding the difference between CLI wallets, browser wallets, and mobile wallets

What surprised me the most was how simple yet powerful the wallet system is. A wallet is not really a “container” for tokens — it’s proof of ownership on the blockchain.

Excited to keep building and learning more about smart contracts, dApps, and on-chain development in the coming days! 🔥

solana #web3 #blockchain #100DaysOfSolana #beginners

From Usernames to Wallets: Understanding Identity on Solana for Web2 Developers

Jay Gurav — Sun, 26 Apr 2026 17:38:17 +0000

If you are a Web2 developer stepping into Web3, one of the biggest mindset shifts is understanding identity. In traditional applications, identity is controlled by platforms. In Solana and other blockchain ecosystems, identity is controlled by cryptography.

At first, this idea sounded confusing to me. After spending time learning about wallets, keypairs, and Solana accounts, I realized that blockchain identity is actually very similar to tools developers already use every day — especially SSH authentication.

In this blog, I’ll explain how identity works on Solana using concepts familiar to Web2 developers.

How Identity Works in Web2

In Web2 applications, identity usually depends on centralized systems.

When you create an account on a website, you typically provide:

A username
An email address
A password

That information is stored inside the company’s database.

Whenever you log in, the platform checks whether your credentials match the stored records. If they do, you gain access.

This means your identity is controlled by the platform itself.

For example:

GitHub controls your GitHub account
Google controls your Gmail account
Your bank controls your banking account

If the company decides to suspend or delete your account, you can lose access instantly.

Your identity is fragmented across different services, and each platform owns its own authentication system.

Solana Takes a Different Approach

On Solana, identity starts with something called a keypair.

A keypair contains:

A public key
A private key

The public key acts like your address or identity on the blockchain.

The private key proves ownership of that identity.

If you have ever used SSH keys, this concept becomes much easier to understand.

With SSH:

You generate a public/private keypair
The server stores your public key
Your private key proves that you are authorized to connect

Solana works in a similar way, except instead of authenticating with one server, you authenticate with the entire blockchain network.

Your wallet address is your identity everywhere on Solana.

Example of a Solana public key:

14grJpemFaf88c8tiVb77W7TYg2W3ir6pfkKz3YjhhZ5

This is not just a username stored in a database. It is a cryptographic identity recognized across the network.

Why Solana Uses Public Keys Instead of Usernames

In Web2, usernames are controlled by companies.

On Solana, your identity is mathematically tied to your cryptographic keys.

Solana addresses are based on Ed25519 public keys and encoded using Base58 encoding.

Base58 is used because it removes confusing characters like:

0 (zero)
O (capital O)
I (capital i)
l (lowercase L)

This reduces mistakes when copying wallet addresses.

Unlike usernames, public keys are globally usable across applications.

One wallet can connect to many decentralized applications (dApps) without creating separate accounts for each one.

That means:

No repeated signups
No password reuse
No dependency on centralized authentication systems

Your wallet becomes your universal identity.

Ownership Without Permission

One of the most powerful ideas in Solana is self-custodied ownership.

In Web2, you only “own” your account because a company allows you to access it.

On Solana, ownership depends entirely on the private key.

If you control the private key, you control the account.

No administrator can reset your password.

No support team can recover your account.

No company can freeze your identity without access to your keys.

This creates true digital ownership, but it also creates responsibility.

If you lose your private key or recovery phrase, you may permanently lose access to your assets.

That is why wallets are extremely important in Web3.

For example:

CLI wallets are useful for development and scripting
Browser wallets like Phantom are convenient for daily dApp interactions
Hardware wallets provide stronger security for storing valuable assets

Each wallet type makes different tradeoffs between convenience and security.

Identity Is More Than Logging In

On Solana, identity is not only used for authentication.

Your wallet identity connects to everything you do on-chain:

Holding tokens
Owning NFTs
Voting in governance systems
Interacting with smart contracts
Building on-chain reputation

Because this identity is shared across the ecosystem, applications can recognize your wallet without needing permission from each other.

This is very different from Web2 platforms where identity systems are isolated and controlled separately.

Final Thoughts

Learning about identity on Solana completely changed how I think about authentication and ownership online.

In Web2, identity is platform-owned.

In Solana, identity is cryptographically owned by the user.

Your wallet is not just a storage tool for crypto assets. It is your authentication system, your proof of ownership, and your portable identity across the blockchain ecosystem.

For developers entering Web3, understanding this concept is essential because it changes how applications are designed and how users interact with them.

The biggest lesson I learned is this:

In Web3, you do not rely on a company to prove who you are. Your cryptographic keys do that for you.

100DaysOfSolana#solana#web3#blockchain#beginners