DEV Community: Gopichand

Solana Transactions Explained for Backend Developers (With Real Failures)

Gopichand — Sat, 09 May 2026 11:00:56 +0000

I've been building on Solana for the past few weeks as part of the

100DaysOfSolana challenge by MLH. Days 15–19 were all about transactions —

sending them, reading them, tracking them through confirmation stages, and
deliberately breaking them. Here's what I learned, explained for backend
developers who think in HTTP requests and database calls.

A Solana Transaction Is Not an API Call

When you hit a REST endpoint, you send a request and get a response.
If it fails, you retry. No cost, no permanent record, no cryptographic proof
it ever happened.

A Solana transaction is different in every one of those ways:

It requires a cryptographic signature from the fee payer's private key
It is permanently recorded on-chain whether it succeeds or fails
It expires after ~60–90 seconds based on a recent blockhash
It costs a fee even if it fails

That last point surprised me the most. Let me show you with real output.

The Anatomy of a Transaction

Every Solana transaction has these parts:
Signature 0: 2xQrSQU...
Account 0: srw- AWKYsCGB... (fee payer)
Account 1: -rw- 8nwngJPM...
Account 2: -r-x 11111111... (System Program)
Instruction 0
Program: 11111111... (System Program)
Transfer { lamports: 9999000000000 }
Recent Blockhash: FVSnvFfG...

Signature — cryptographic proof the fee payer authorized this tx
Accounts — every account the tx will read or write must be declared upfront
Instructions — the actual operations (transfer SOL, call a program, etc.)
Recent Blockhash — acts like a timestamp + nonce; tx expires if too old

The account permission flags (srw-, -rw-, -r-x) tell you exactly what
each account can do: signer, readable, writable, e*x*ecutable.

Solana's 3 Confirmation Levels

Unlike a database commit that's either done or not, Solana confirmation
happens in stages:

Level	What it means	Web2 analogy
Processed	Validator included tx in a block	POST reached the server
Confirmed	66%+ validators voted on the block	200 OK from load-balanced API
Finalized	31+ blocks built on top	DB commit flushed + replicated

I built a live tracker that shows each stage in real time:
Tracking confirmation stages...
[Processed → Confirmed] ✅ reached in 0.3s
[Confirmed → Finalized] ✅ reached in 0.2s

Transaction successful! 🎉
Signature: 3hYmkD3m...

On devnet, Processed→Confirmed takes ~400ms. Confirmed→Finalized takes
~6–12 seconds. In production those numbers matter for UX decisions.

What Happens When Transactions Fail

This is where things get interesting. I deliberately triggered a failed
transaction by skipping preflight simulation (skipPreflight: true) and
attempting to send 9,999 SOL when my wallet only had ~6.14 SOL.

Here's the real on-chain output from solana confirm -v:
Status: Error processing Instruction 0: custom program error: 0x1
Fee: ◎0.000005
Account 0 balance: ◎6.13593 -> ◎6.135925
Account 1 balance: ◎0
Compute Units Consumed: 150
Log Messages:
Program 11111111111111111111111111111111 invoke
Transfer: insufficient lamports 6135925000, need 9999000000000
Program 11111111111111111111111111111111 failed: custom program error: 0x1

Three things stand out:

1. The fee was charged anyway.
Account 0 balance dropped by 0.000005 SOL — just the fee, not the transfer.
The network did work (verified signature, attempted execution), so it got paid.

2. The error is structured.
custom program error: 0x1 from the System Program always means insufficient
lamports. As you write your own programs, these error codes become your
primary debugging tool — like HTTP status codes but for on-chain logic.

3. The Log Messages are your stack trace.
Transfer: insufficient lamports 6135925000, need 9999000000000 tells you
exactly what was available vs what was needed. This is how you debug failed
instructions in production.

Two Types of Failure: Local vs On-Chain

Not all failures reach the chain:

Failure type	Where it stops	Fee charged?
CLI preflight (insufficient funds check)	Never leaves your machine	❌ No
On-chain failure (skipPreflight)	Executed by validators	✅ Yes

This is why production apps use simulateTransaction before submitting.
Simulation catches errors locally for free. Every on-chain failure is real
money, even if it's tiny amounts.

The Mental Model Shift

The biggest shift from Web2 to Solana transactions:

Web2: You send a request. The server decides what happens. You get a
response. If something breaks server-side, you don't pay for it.

Solana: You sign and broadcast a state change. Validators execute it
atomically. The result — success or failure — is permanent and public.
You pay regardless.

The blockhash expiry (~60–90s) also changes how you think about retries.
You can't just retry the same signed transaction forever — the blockhash
goes stale. You need to rebuild and re-sign with a fresh blockhash.

What I Built This Week

Day 15 — Inspected transaction anatomy: signatures, accounts, instructions, compute units
Day 16 — Sent first SOL transfer on devnet (<1s settlement)
Day 17 — Built a reusable Node.js CLI transfer tool with balance checks and Explorer links
Day 18 — Added live confirmation tracking (Processed→Confirmed→Finalized)
Day 19 — Deliberately broke transactions, read on-chain errors with solana confirm -v

All code is on my GitHub:
github.com/gopichandchalla16/100-days-of-solana

If you're coming from a Web2 background and starting with Solana, the
transaction model will feel strange at first. The fee-on-failure behavior,
the blockhash expiry, and the upfront account declaration all exist for
good reasons — they're what makes Solana fast, parallel, and predictable.
Once it clicks, it's actually elegant.

Day 20 of #100DaysOfSolana — building in public every day 🚀
Follow my progress: @GopichandAI

Week 2 on Solana: When the "Public Database" Finally Clicked

Gopichand — Mon, 04 May 2026 07:55:21 +0000

I'm doing the 100 Days of Solana challenge by MLH, and Week 2 just changed how I think about blockchain data entirely.

Week 1 was about identity — generating keypairs, understanding wallets, getting devnet SOL. That part felt familiar, like setting up a dev environment.

Week 2 was different. Week 2 was about reading the chain — and that's where the mental model shift actually happened.

What I expected vs what I got

I expected reading blockchain data to feel like calling a mysterious, slow, complex API. Something with heavy setup, authentication tokens, and confusing docs.

What I got was this:

const { value: lamports } = await rpc.getBalance(address).send();
const sol = Number(lamports) / 1_000_000_000;

No API key. No login. No permissions. Anyone can call this for any address, anytime.

In Web2, if I want someone's account balance, I need DB credentials, role permissions, and middleware. On Solana, I just ask. Publicly. That's not a flaw — that's the design.

The moment it clicked

Day 11 was a conceptual challenge: compare Solana accounts to Web2 databases. I ran:

solana account $(solana address)

Output:
Public Key: AWKYsCGBcfGLSz6QpmXzRn7EJ9fRhiJsjYSLDV3c9L9y
Balance: 2.5 SOL
Owner: 11111111111111111111111111111111
Executable: false

Then I ran:

solana account TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

Output:
Owner: BPFLoaderUpgradeab1e11111111111111111111111
Executable: true
Length: 36 bytes

Same command. Same account model. One is a wallet holding SOL. The other is the Token Program — compiled code that manages every SPL token on Solana. Both are just "accounts."

That's when "everything is an account" stopped being a slogan and started being a mental model.

The devnet vs mainnet surprise

Day 12 was the most satisfying. One script. Two RPC connections:

const devnetRpc  = createSolanaRpc(devnet("https://api.devnet.solana.com"));
const mainnetRpc = createSolanaRpc(mainnet("https://api.mainnet-beta.solana.com"));

Same address. Same getBalance call. Completely different output:
DEVNET → 0.001159846 SOL | Slot: 459,981,397
MAINNET → 0.069875097 SOL | Slot: 417,486,413

Different balances. Different slots. Completely different transaction histories. I already knew they were separate — but seeing it side by side in the terminal made it real in a way docs never did.

What's still confusing

PDAs — Program Derived Addresses. I understand they're derived from a program + seed with no private key, so only the program can sign for them. But I haven't used one yet. I can describe them but I can't feel them. That's my Week 3 target.

What I'd tell Week-1-me

Stop thinking in tables and rows. Start thinking in accounts and owners. Every piece of state on Solana is an account. Every account has an owner program. Only that program can modify it. That's not a restriction — that's what makes the system trustless.

Also: devnet is your playground. Break things there first.

If you're also doing #100DaysOfSolana, drop your DEV.to link below — I want to read what clicked for you.

→ My code: https://github.com/gopichandchalla16/100-days-of-solana

Your Public Key IS Your Identity: What Web2 Devs Need to Know About Solana

Gopichand — Tue, 28 Apr 2026 16:55:00 +0000

If you've been a Web2 developer for any amount of time, you know what identity
looks like: a username in a database, an email address, a session cookie,
maybe an OAuth token from Google. Your "identity" is really just a record that
some company controls. They can delete it. They can lock you out. They can sell
the data. You don't own it — you just borrow it.

Solana works completely differently. And once you understand how, you can't
unsee it.

It Starts with a Keypair

When I started the 100 Days of Solana challenge, the first thing I did was run:

solana-keygen new --no-bip39-passphrase -o wallet.json

This generated two things:

A public key — a 32-byte Ed25519 address like AWKYsCGBcfGLSz6QpmXzRn7EJ9fRhiJsjYSLDV3c9L9y
A private key — stored in wallet.json, never shared

That's it. That keypair IS my identity on Solana. No signup form. No email
verification. No "username already taken."

The SSH Key Analogy

If you've ever set up a server on AWS or DigitalOcean, you already understand
this model. You generate an SSH keypair, paste the public key into the server's
authorized_keys file, and prove your identity by holding the private key.

Solana works identically — except instead of one server, it's the entire
global network. Every node on Solana knows your public key. You prove ownership
by signing transactions with your private key.

The difference from Web2 is critical: no company stores your credentials.
There is no database row. There is no admin who can reset your password or
lock your account.

What a Solana Address Actually Is

A Solana address is a Base58-encoded 32-byte Ed25519 public key. Base58 was
chosen deliberately — it removes visually confusing characters like 0, O,
I, and l to prevent copy-paste mistakes.

In Web2, your username lives in someone's Postgres table:

SELECT * FROM users WHERE username = 'gopichand';

On Solana, your identity is derived from math. It exists everywhere and nowhere
simultaneously — it only becomes real when you sign something with the private key.

Cryptographic Ownership vs Company-Granted Access

Here's the most important mental shift:

In Web2, you "own" your account because a company says you do. Twitter can
ban you. Your bank can freeze your account. Google can lock your Gmail. You
have access because they allow it.

On Solana, ownership is cryptographic. If you hold the private key, you control
the account — period. No appeal process, no customer support ticket, no
waiting for a human to review your case.

This is both powerful and terrifying. Lose your private key? Your funds are gone
forever. No recovery email. That's why seed phrases and hardware wallets exist.

Identity Enables Everything Else

Once I had a keypair, I could:

Receive devnet SOL — just by sharing my public key
Connect a browser wallet — Phantom connected on Day 4 without me ever sharing my private key
Sign transactions — prove I authorized a transfer without revealing my secret
Own tokens and NFTs — because ownership is just a signed record on-chain

This one keypair is the foundation for token ownership, dApp interactions,
governance votes, and on-chain reputation — across every application on the
network, without asking anyone's permission.

Which Wallet Type Should You Use?

During Day 5 of the challenge, I compared three wallet types:

Wallet	Key Storage	Best For
CLI (`id.json`)	Plaintext file	Devnet scripting
Browser (Phantom)	Encrypted + password	dApp interactions
Mobile (Phantom)	Hardware-backed + biometrics	Personal daily use
Hardware (Ledger)	Never leaves device	Long-term storage

The underlying keypair concept is identical across all of them. What differs
is where the private key lives and how it's protected.

The Big Takeaway

In Web2, identity is a database record owned by someone else.
In Web3, identity is a mathematical keypair owned by you.

Your public key is your username, your account number, and your proof of
existence on the network — all at once. The private key is the only password
that matters, and only you should ever hold it.

I'm documenting every step of this journey publicly as part of the
100 Days of Solana
challenge by MLH.

All my code is on GitHub: github.com/gopichandchalla16/100-days-of-solana

Follow along if you're on the same journey! 🚀

100daysofsolana #solana #web3 #blockchain #beginners

Starting 100 Days of Solana as an AI Web3 Builder.

Gopichand — Sat, 18 Apr 2026 05:39:28 +0000

Hi DEV community 👋
I’m Gopichand, a CSE graduate from India, and I’m building in public around AI × Web3.
I’ve recently joined the 100 Days of Solana challenge, and I want to use this journey to learn Solana step by step, share what I build, and connect with other developers who are exploring web3.

My goal is simple: learn by doing, document the process, and turn each small win into a real project.
I’ll be sharing updates, experiments, and lessons as I go.

Excited to be here — and I’d love to hear from anyone else learning Solana or building on chain.

Follow my progress:

gopichandchalla16 (Gopichand) · GitHub

AI × Web3 builder | LangChain · Solidity · On-chain agents | Building in public daily → @GopichandAI - gopichandchalla16

github.com

x.com