DEV Community: Jay Gurav

🚀 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