DEV Community: Vinay

⚓My Deep Dive into Solana Transactions: Shifting the Web2 Perspective

Vinay — Sun, 10 May 2026 15:14:24 +0000

Over the last few days, I’ve been learning how Solana transactions actually work. At first, I approached them like I would approach API requests in Web2: you send something to the network, wait for a response, and either it succeeds or fails.
But after building transfer tools, tracking confirmations, and intentionally forcing failed transactions, I realized Solana transactions are much closer to atomic state transitions in a distributed system than traditional request/response workflows.

🏗️ The Foundation

Before this post, I documented two earlier parts of the journey:

Vinay

May 6

Sending Your First SOL Transfer (Devnet, via CLI)

#100daysofsolana #web3 #blockchain #solana

Comments

3 min read

Vinay

May 6

Understanding Solana's transaction anatomy

#100daysofsolana #web3 #blockchain #solana

Comments

2 min read

Those experiments helped me understand the structure underneath every transaction before I started building tooling around them.

🔍 Deconstructing the Transaction Anatomy

The first thing that stood out to me was how much information exists inside a transaction. Once I started inspecting transactions in Solana Explorer and using solana confirm -v, I stopped seeing transfers as simple wallet operations.

A single transaction includes:

Signatures
Instructions
Account keys
Recent blockhashes
Fee payer information
Execution logs

🧠The Mental Model Shift:
A Solana transaction is not just a request. It’s a signed set of instructions that tells the network how on-chain state should change.

🛠️ Building the Tooling

After getting comfortable with CLI transfers, I built a reusable transfer tool instead of manually typing commands every time.

The tool eventually handled:

Recipient and amount validation
Balance checks before sending
Explorer link generation
Confirmation tracking
Transaction failure handling

The balance checks were especially interesting because failed transactions on Solana still cost fees. That’s very different from most backend systems I’m used to. In Web2, failed requests are usually just errors. On Solana, even failed execution still consumes validator compute resources.

⛓️ Understanding the Lifecycle of Confirmation

One of the most useful things I learned was how confirmation actually works. At first, I thought transactions were either pending or complete.

But Solana has multiple commitment levels:

Processed: Received by a validator.

Confirmed: Voted on by the network supermajority.

Finalized: Effectively irreversible after additional confirmed blocks.

Watching transactions move through those stages made the network feel much more real. Instead of treating blockchain confirmation like a black box, I could actually observe the lifecycle happening in real time.

⚠️ Learning Through Failure

The most valuable part of the process, though, was intentionally breaking transactions.

I created empty wallets. I forced failed transfers. I inspected logs and Explorer traces. I compared local CLI validation with actual on-chain failures. That ended up teaching me more than successful transactions did.

Seeing compute usage, log messages, and failure metadata made the debugging side of Solana feel surprisingly similar to debugging distributed backend systems—except here, every mistake has an economic cost attached to it.

🧠 Key Takeaways

The biggest takeaway from this journey is that understanding transactions is really about understanding how Solana itself thinks.

Once I stopped comparing transactions directly to REST API calls, concepts like signatures, blockhash expiration, commitment levels, and transaction simulation started making much more sense. Intentionally exploring failed transactions was the point where everything finally clicked for me.

Understanding Solana's transaction anatomy

Vinay — Wed, 06 May 2026 11:23:11 +0000

📖 Overview

For the past week, I’ve been reading data from the Solana blockchain. This project marks the shift from reading state to writing state. The goal was simple but fundamental: understand what actually happens when a transaction is sent on Solana.

🎯 Objective

Send a real transaction on Solana Devnet

Inspect it using CLI and Explorer

Understand its internal structure

Build a mental model for how state changes occur

⚙️ What I Did

1. Created a Temporary Wallet

Generated a fresh keypair to act as the recipient.

solana-keygen new --no-bip39-passphrase -o /tmp/temp-wallet.json

This generated a transaction signature, which acts as:

A receipt

The transaction ID

The first cryptographic signature

Example:

2. Sent a Transaction

solana transfer --allow-unfunded-recipient $(solana address -k /tmp/temp-wallet.json) 0.001 --url devnet

Transferred a small amount of SOL on Devnet.
This produced a transaction signature (ID).

Example:

3. Inspected the Transaction via CLI

solana confirm -v <TRANSACTION_SIGNATURE>

This revealed:

Transaction status and slot

Accounts involved

Instruction execution details

Example:

4. Analyzed in Explorer
Visualized It in Solana Explorer

Using the transaction signature, I examined:

Signatures → Authorization proof

Recent Blockhash → Freshness + anti-replay

Account Keys → All accounts involved

Instruction → System Program transfer

🧠Mental Model Upgrade

What you sent is not:

“Send 0.001 SOL to X”

It is:

“Execute instruction #2 of the System Program, using these accounts, with this encoded data, authorized by this signature.”

Sending Your First SOL Transfer (Devnet, via CLI)

Vinay — Wed, 06 May 2026 09:43:38 +0000

This walkthrough focuses on executing a SOL transfer using the Solana CLI - while understanding the underlying mechanics at each step. If you’ve used payment APIs like Stripe or PayPal, the flow is conceptually similar: authenticate, define recipient, specify amount, submit. The difference is architectural, transactions go directly to the network and finalize in sub-seconds, without intermediaries.

Environment Requirements

Terminal (macOS, Linux, or Windows WSL)

Solana CLI installed

A keypair (existing or newly generated)

1. Configure CLI to Devnet

solana config set -ud
solana config get

Key point:
You are selecting the cluster (network). Devnet is a sandbox environment with no real economic cost. The RPC endpoint (https://api.devnet.solana.com) acts as your interface to the validator network.

Why it matters:

All subsequent commands - balance queries, transfers, account creation are executed against this network.

Example:

2. Check Balance and Fund Wallet

solana balance
solana airdrop 2

Key point:

Transactions require:

Sufficient balance for the transfer amount
A small fee for network processing

Airdrop behavior:

Devnet validators mint SOL for testing
Requests are capped (typically 5 SOL)

If airdrop fails:
You can fund your wallet using the Solana Faucet as an alternative.

Why it matters:
Without sufficient balance, the transaction cannot be constructed or submitted.

Example:

3. Generate a Recipient Keypair

solana-keygen new --outfile ~/recipient-keypair.json --no-bip39-passphrase

Key point:
You are creating a cryptographic identity:

Private key → signs transactions
Public key → acts as the address

Important nuance:
This account does not yet exist on-chain - it becomes a real account only after being funded.

Why it matters:
Solana distinguishes between:

Off-chain keypairs (identity)

On-chain accounts (state containers)

Example:

4. Execute the Transfer

solana transfer <RECIPIENT_PUBLIC_KEY> 0.5 --allow-unfunded-recipient

Key point:
This command:

Constructs a transaction with a System Program transfer instruction

Signs it with your private key

Submits it to a validator via RPC

Flag explanation:

--allow-unfunded-recipient allows the network to create the recipient account implicitly

Why it matters:
On Solana, accounts must be explicitly created and funded. This step combines:

Account creation
Value transfer into a single atomic transaction.

Example:

5. Verify State Changes

solana balance
solana balance <RECIPIENT_PUBLIC_KEY>

Key point:
You are querying on-chain state post-finalization.

Expected outcome:

Sender balance decreases (transfer + fee)

Recipient balance increases

Recipient account now exists on-chain

Why it matters:
This confirms the transaction was validated, executed, and finalized by the network.

Example:

6. Inspect the Transaction

Open your transaction using the signature in Solana Explorer:

Key point:
You are viewing the transaction as recorded in the ledger.

Details include:

Accounts involved
Instruction data
Fees
Slot (block inclusion)
Confirmation status

Why it matters:
The explorer reflects canonical on-chain data - this is the definitive record of execution.

Example:

View above transaction in solana explorer

Full Command Flow

solana config set -ud
solana airdrop 2
solana-keygen new --outfile ~/recipient-keypair.json --no-bip39-passphrase
solana transfer <RECIPIENT_PUBLIC_KEY> 0.5 --allow-unfunded-recipient
solana balance
solana balance <RECIPIENT_PUBLIC_KEY>

What This Demonstrates

Direct transaction submission to a decentralized validator network

Atomic state transitions (account creation + transfer)

Explicit account model requiring funding for existence

At a systems level, you:

Defined network context (devnet RPC)

Generated identities

Authored and signed a transaction

Submitted it to the network

Observed deterministic state changes

This is the foundational workflow for interacting with Solana.

A few early takeaways from learning Solana

Vinay — Sun, 03 May 2026 17:42:17 +0000

I’ve been exploring Solana for the past few days and a few things stood out pretty quickly

No traditional database everything revolves around accounts
Reads happen through RPC calls not queries
Writes are transactions not simple updates
Access control is handled by signatures not roles or middleware

The biggest shift so far has been adjusting to the accounts model. Coming from a typical backend mindset it forces you to think differently about how data is stored who owns it and how state changes over time

I also built a small dashboard in the browser to fetch wallet balance and recent transactions. Moving from scripts to something visual made the flow of data much clearer

Had a session with Solana DevRel as well where we discussed Anchor validators and PDAs. That helped connect some of the concepts around how programs actually manage data on chain

Still early but things are starting to click. Planning to go deeper into Anchor and understand how to structure programs better

Two weeks with Solana - Personal experience

Vinay — Sun, 03 May 2026 17:18:05 +0000

Been spending the last ~10 days getting hands-on with Solana as part of a hackathon. Went in expecting things to feel completely different from what I’m used to.

It wasn’t as far off as I thought.

What I’ve Done So Far

Generated a keypair + airdropped devnet SOL
Created a wallet and checked balance programmatically
Understood SOL vs lamports
Connected a browser wallet
Read on-chain data (accounts, transactions)
Fetched recent transactions
Built a small browser dashboard
Compared devnet vs mainnet data
Tried mapping accounts vs traditional databases

What Took a Bit to Understand

Fetching data wasn’t the hard part - it’s pretty similar to calling APIs.

The shift was in how things are structured:

Accounts aren’t users, they’re just data containers
There’s no backend I control
Data is public, transactions update state

The point where it clicked was pulling transaction history for a wallet and realizing there’s no access layer in between. You just query it.

Building in the Browser

Moving from scripts to a simple dashboard helped a lot.

Showing balances, listing transactions, switching networks - it made things feel more real than just running CLI scripts.

MLH Session

Also attended an MLH session with Brianna (Solana Developer Relations). where she briefed on:

Anchor Framework
Validators
PDAs
Program structure on Solana

I haven’t used these hands-on yet, but it gave me a better picture of what’s happening under the hood.

Still Figuring Out

Program design
Handling storage (accounts + rent)
Better ways to query data beyond basic RPC

Why My Solana Wallet Broke Without "extractable: true" — And What PKCS8 Taught Me About Private Keys

Vinay — Mon, 27 Apr 2026 09:34:20 +0000

Last week, I built a small Solana wallet script where I could create, export, save, and reload a keypair.

Here's the link of the script for reference: Github

It all started with this line:

const wallet = await generateKeyPairSigner({ extractable: true });

When I tried exporting the private key:

await crypto.subtle.exportKey("pkcs8", wallet.keyPair.privateKey);

I learned two important things:

1. Why `extractable: true` is required

If the key is not extractable:

exportKey simply fails
The private key stays locked inside the crypto subsystem
You cannot save or reuse the wallet

So without extractable: true, the wallet is temporary (in-memory only).

2. Why "pkcs8" and not "raw"?

This part was subtle but important.

"pkcs8" is the standard format for exporting private keys
It wraps the key with metadata (algorithm, structure, etc.)
The Web Crypto API only allows private keys to be exported in PKCS#8 format

If you try:

crypto.subtle.exportKey("raw", wallet.keyPair.privateKey);

It will fail.

Because:

"raw" format is only valid for public keys
Private keys require a structured, secure encoding → hence PKCS#8

🧩 What I Did Next

After exporting in PKCS#8, I extracted the actual 32-byte private key:

const privateKeyBytes = new Uint8Array(pkcs8Buffer.slice(-32));

Then combined it with the public key:

`const keyPairBytes = new Uint8Array(64);
keyPairBytes.set(privateKeyBytes, 0);
keyPairBytes.set(publicKeyBytes, 32);`

This gave me the standard 64-byte Solana keypair, which I could:

Save to a file
Reload later

⚖️ Big Takeaway

This small detail clarified a bigger concept for me:

extractable: true → enables portability (save, backup, restore)
"pkcs8" → the only valid way to export private keys
"raw" → only works for public keys

🔑 From Usernames to Keypairs: Understanding Identity on Solana

Vinay — Sat, 25 Apr 2026 12:10:32 +0000

A few days ago, if you asked me what “identity” means in tech, I’d give you a very Web2 answer:

Email + password = identity

Every platform I used - GitHub, banking apps, social media - had its own login system. Different usernames, different passwords, all controlled by the companies behind them.

Then I started learning Solana.

And my understanding of identity completely changed.

🏨 Web2 vs Web3: A Simple Analogy

Web2 identity is like staying in a hotel.

You get a key card, but the hotel can deactivate it anytime.

Solana identity is like owning your own house.

You hold the only key. No one can lock you out… but if you lose it, you're stuck outside.

This shift from platform-controlled access to user-controlled ownership is the core idea behind on-chain identity.

🔑 Identity = Keypair

On Solana, your identity starts with a cryptographic keypair:

Public Key → your address (safe to share)
Private Key → your proof of ownership (must stay secret)

If you’ve used SSH before, this will feel familiar.

No signup. No email. Just keys.

🤯 One Keypair = My Identity

In Web2, my identity is scattered. Each service (Google, Social Media, Github, etc..) manages its own version of "me".

But on Solana, everything connects to one thing:

That’s when it clicked:

My public key isn’t just an address — it’s my identity across the entire network.

👀 The Weird Part: No Username?

In Web2, we all know how a username looks like..
I expected something like that.
Instead, I got this 😵‍💫:

14grJpemFaf88c8tiVb77W7T...

Not exactly memorable 😅

But then I learned, On Solana, your identity is your public key:

It’s mathematically generated
It uses Base58 encoding, avoiding confusing characters like 0, O, I, and l
Not controlled by any company

🔐 “Logging In” Doesn’t Exist

This is a subtle but important shift.

You’re not logging in. You’re proving ownership cryptographically.

No passwords. No sessions. Just signatures.

🏁 Final Thought

I started this journey thinking I was just learning how wallets and transactions work.

Instead, I ended up rethinking what “identity” even means.

And honestly, once that clicks — everything else in Web3 starts to make a lot more sense.

DEV Community: Vinay

⚓My Deep Dive into Solana Transactions: Shifting the Web2 Perspective

Sending Your First SOL Transfer (Devnet, via CLI)

Understanding Solana's transaction anatomy

Understanding Solana's transaction anatomy

📖 Overview

🎯 Objective

⚙️ What I Did

🧠Mental Model Upgrade

Sending Your First SOL Transfer (Devnet, via CLI)

Environment Requirements

1. Configure CLI to Devnet

2. Check Balance and Fund Wallet

3. Generate a Recipient Keypair

4. Execute the Transfer

5. Verify State Changes

6. Inspect the Transaction

Full Command Flow

What This Demonstrates

A few early takeaways from learning Solana

I’ve been exploring Solana for the past few days and a few things stood out pretty quickly

Two weeks with Solana - Personal experience

What Took a Bit to Understand

Building in the Browser

MLH Session

Still Figuring Out

Why My Solana Wallet Broke Without "extractable: true" — And What PKCS8 Taught Me About Private Keys

1. Why extractable: true is required

2. Why "pkcs8" and not "raw"?

🧩 What I Did Next

⚖️ Big Takeaway

🔑 From Usernames to Keypairs: Understanding Identity on Solana

🏨 Web2 vs Web3: A Simple Analogy

🔑 Identity = Keypair

🤯 One Keypair = My Identity

🔐 “Logging In” Doesn’t Exist

🏁 Final Thought

1. Why `extractable: true` is required