DEV Community: LittleNezhaMin

Understanding Solana’s Account Model as a Web2 Developer

LittleNezhaMin — Sun, 17 May 2026 14:44:14 +0000

When I first started learning Solana, the thing that confused me most wasn’t transactions or wallets.

It was accounts.

Every tutorial kept talking about accounts:

Wallet accounts
Program accounts
Token accounts
Data accounts

At first, it sounded like blockchain jargon overload.

But after spending a few days inspecting accounts using the Solana CLI and Explorer, something finally clicked:

On Solana, everything is an account.

Once you understand that idea, the rest of Solana starts making a lot more sense.

In this article, I’ll explain Solana’s account model from the perspective of a Web2 developer.

⸻

The Mental Shift: Solana Is a Giant Key-Value Store

In Web2, we usually think in terms of:

databases
tables
backend servers
APIs
application state

Solana works differently.

Instead of storing application state inside a backend server, Solana stores everything inside accounts on-chain.

Every Solana Account Has the Same Structure

No matter what type of account you inspect, they all contain the same core fields.

A Solana account contains:

lamports
data
owner
executable
rent_epoch

Here’s an example using the Solana CLI:
solana account <ACCOUNT_ADDRESS>
Example output:
`{

"lamports": 1505728269681,

"owner": "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA",

"executable": false,

"rentEpoch": 18446744073709551615,

"data": [...]

}`
Let’s break those fields down.

Lamports = SOL Balance

Lamports are the smallest unit of SOL.

Think of them like satoshis in Bitcoin.
1 SOL = 1,000,000,000 lamports
If an account has:
1500000000 lamports
That means it owns:
1.5 SOL
Every account can hold SOL, not just wallets.

That surprised me at first.

Data = Arbitrary State Storage

The data field is where programs store information.

This could contain:

token balances
NFT metadata
game inventory
DeFi positions
DAO governance state

The important thing is:

Solana stores raw bytes.

Programs are responsible for interpreting those bytes.

This feels similar to reading binary files or serialized objects in traditional systems.

⸻

Owner = Who Controls the Account

This is one of the most important concepts in Solana.

Every account has an owner.

But the owner is usually NOT a user.

It’s typically a program.

Example:
TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
That’s the SPL Token Program.

If an account is owned by the Token Program, only the Token Program can modify that account’s data.

This creates a very clean security model.

Ownership Rules

On Solana:

Only the owner program can modify account data
Only the owner program can debit lamports
Anyone can send lamports into a writable account

That’s surprisingly elegant.

⸻

Executable = Is This a Program?

This field is simply:
true or false
If:
executable = true
then the account contains executable program code.

If:
executable = false
then it’s just a data account.

This is where Solana differs a lot from Ethereum.
Programs Don’t Store Their Own State

This was probably the biggest mental shift for me.

In Ethereum, smart contracts usually contain both:

code
state

On Solana, programs are stateless.

The executable code lives in one account.

The data lives in separate accounts.
Programs read and write external accounts instead of storing state internally.

That design allows Solana to parallelize transactions more efficiently.

Rent Epoch (Deprecated)

Older Solana docs talk about rent_epoch.

Today, this field is effectively deprecated and usually set to:
18446744073709551615
Most developers can ignore it now.
Rent Exemption

One thing I found interesting is that storing data on Solana costs money.

Every account must maintain a minimum balance to remain on-chain.

This is called being:
rent-exempt
The larger the account data size, the more SOL it needs.

For example:
solana rent 0
returns the minimum balance needed for an empty account.

At the time I tested it, it was around:
0.00089 SOL
This mechanism prevents the blockchain from being flooded with useless data forever.
My Favorite Analogy: Solana as a Filesystem

The analogy that finally made everything click for me was this:

Imagine Solana as a giant operating system filesystem.

Each account is like a file.

Accounts contain:

metadata
permissions
contents

Programs are executable files.

Data accounts are documents those programs read and write.

The System Program acts like the operating system kernel managing account creation and ownership.

Once I started thinking about Solana this way, the architecture suddenly felt much more familiar.

⸻

Final Thoughts

At first, Solana’s account model felt strange coming from Web2.

But now I actually think it’s one of the cleanest parts of Solana’s design.

The key ideas that helped me most were:

Everything is an account
Programs are stateless
Ownership controls security
Accounts are just structured storage

Once those concepts click, reading Solana transactions and programs becomes much easier.

If you’re a Web2 developer learning Solana right now, my advice is simple:

Spend time inspecting real accounts.

Use:
solana account <address>
Look at Explorer.

Read the raw JSON.

Eventually the patterns start revealing themselves naturally.

And honestly, that’s when blockchain development starts becoming really fun 🚀

Solana Transactions Explained for Backend Developers

LittleNezhaMin — Sun, 10 May 2026 07:11:09 +0000

Over the past few days in #100DaysOfSolana, I went from knowing almost nothing about Solana transactions to building my own CLI transfer tool, tracking transaction confirmations in real time, and debugging failed on-chain transactions.

Coming from a backend/web2 background, Solana transactions initially felt confusing. Terms like signatures, blockhashes, commitment levels, and atomic state changes sounded very different from the APIs and databases I was used to.

But after building and breaking transactions myself, something finally clicked.

In this post, I want to explain Solana transactions from the perspective of a backend developer.

⸻

The Mental Model Shift

At first, I treated a Solana transaction like an HTTP request:
`POST /transfer

{

"from": "...",

"to": "...",

"amount": 0.01

But that mental model is incomplete.

A Solana transaction is closer to a signed, atomic database transaction that gets executed by a decentralized network.

Unlike a normal API request:

there is no centralized server
every transaction must be cryptographically signed
transactions expire quickly
failures still cost fees
consensus happens in stages

That last point surprised me the most.

⸻

Transaction Confirmation Is Not Binary

In web2 systems, requests are usually either:

pending
successful
failed

But on Solana, transactions move through multiple commitment levels:

Processed

A validator received and processed the transaction.

This is similar to:

“The server accepted your request.”

But it is not finalized yet.

⸻

Confirmed

A supermajority of validators voted on the block containing your transaction.

This is effectively:

“The network agrees your transaction succeeded.”

Interestingly:

no confirmed transaction in Solana history has ever been reversed.

⸻

Finalized

31+ additional blocks were built on top of your transaction.

At this point, the transaction is considered irreversible.

This feels similar to:

replicated database commits
durable writes
globally finalized state

⸻

Building My Own Transfer Tool

One of the most useful exercises was building a reusable CLI transfer tool using:

Node.js
@solana/kit
Solana CLI keypairs

Instead of manually typing transfer commands every time, the tool:

accepts recipient + amount arguments
checks balances
signs transactions locally
submits transactions to devnet
tracks confirmation progress
prints Explorer links node transfer.mjs <RECIPIENT> 0.01 Terminal output: `Solana Transfer Tool ==================== Connected to Solana devnet.

Status: processed ✅
Status: confirmed ✅
Status: finalized ✅

Transaction successful!`
his felt very similar to building internal tooling around payment APIs in web2.

Except this time:

there was no Stripe
no backend server
no payment gateway

The transaction went directly to the blockchain network.

⸻

Failed Transactions Taught Me More Than Successful Ones

One thing I underestimated:

failed transactions are incredibly educational.

For example, I intentionally tried sending more SOL than my balance:
node transfer.mjs RECIPIENT 999
Result:
Transaction failed: Insufficient balance...
I also learned:

failed transactions still consume fees
blockhashes expire
commitment levels matter
RPC polling is essential for good UX

This changed how I think about blockchain applications.

⸻

The Biggest Difference From Web2

The biggest mindset shift for me was this:

In web2:

servers own state

In Solana:

the network owns state

Your application becomes more like:

a transaction builder
a signing interface
a state interpreter

instead of a traditional CRUD backend.

That changes everything.

⸻

Final Thoughts

A week ago, Solana transactions looked intimidating.

Now they feel surprisingly elegant.

Once I stopped trying to force blockchain into traditional web2 mental models, the architecture started making sense:

atomic state changes
cryptographic authorization
distributed consensus
deterministic execution

I still have a lot to learn, but building and debugging real transactions helped far more than just reading documentation.

If you’re a backend developer exploring Solana for the first time:
my biggest recommendation is simple:

build small tools yourself.

That is when the concepts really start to click.

Solana #Blockchain #Web3 #100DaysOfSolana

Week 2 of #100DaysOfSolana: When “Public Database” Finally Clicked

LittleNezhaMin — Sat, 02 May 2026 14:09:07 +0000

After two weeks building on Solana, I feel like my mental model of “blockchain” has completely changed.

Before this, I used to think blockchain data was something abstract, complex, and hard to access. Something like a black box where transactions go in, and magic comes out.

Reality?
It’s surprisingly simple… and surprisingly different.
🧱 What I Expected vs Reality
Coming from a fullstack background (PHP, Go, APIs, databases), I expected:

Tables
Queries (SELECT, JOIN, WHERE)
Structured schemas

But on Solana, there are no tables.

Instead:

Accounts = your data
Programs = your logic
RPC = your API

At first, this felt strange.

But once I reframed it like this:

Solana = a giant public database you can read from

Things started to make sense.

⸻

⚡ The Moment It Clicked

The biggest “aha” moment came when I fetched:

Balance of an address
Recent transactions

Using just an RPC call.
No authentication.
No backend.
No database setup.
Just:

const balance = await rpc.getBalance(address).send();

That’s it.
At that moment, it clicked:
This is just a read-only API… but global and trustless.
🧩 What Surprised Me Most

Same Code, Different Network = Completely Different Data

When I compared devnet vs mainnet, I got:

Devnet → 5 SOL + transactions (from testing)
Mainnet → 0 SOL + no activity

Same address. Same code.

Completely different reality.

This felt exactly like:

Devnet = staging DB
Mainnet = production DB

But with real money involved.

Everything is Public

In Web2:

You need auth
You need permission
You need APIs

In Solana:

You can read anything
Anytime
From anywhere

That’s powerful… and a bit scary 😅

RPC Feels Like an API, But It’s Not Quite the Same

Working with Solana RPC feels familiar:

Request → Response
JSON data
Async calls

But the mindset is different:

You’re not querying your backend
You’re querying a shared global state

That changes how you think about data completely.
🚧 What I’m Still Confused About

A few things I’m still figuring out:

How to write data safely (transactions, signing, fees)
How programs (smart contracts) actually store structured data
Best practices for building real apps on top of accounts

Reading data feels easy.

Writing data feels like the next big challenge.
🚀 What I Want to Learn Next

Next, I want to focus on:

Sending transactions
Interacting with programs
Building a real dApp with a wallet (Phantom, etc.)
Moving from “read-only” → “read + write”

⸻

Final Thoughts

Week 2 made one thing clear:

Blockchain isn’t magic.
It’s just a different way of structuring and accessing data.

And once that clicks…

Everything becomes a lot more approachable.

⸻

If you’re also doing #100DaysOfSolana, I’d love to connect and see what you’re building 🚀

Week 2 of #100DaysOfSolana: When “Public Database” Finally Clicked After two weeks building on Solana, I feel like my mental model of “blockchain” has completely changed. Before this, I used to think blockchain data was something abstract, complex, and h

LittleNezhaMin — Sat, 02 May 2026 13:59:49 +0000