DEV Community: ajith pkumar

Solana Accounts 101

ajith pkumar — Tue, 02 Jun 2026 12:31:32 +0000

If you're coming from a traditional Web2 background, Solana's account model can feel strange at first. Terms like accounts, programs, owners, and rent exemption sound blockchain-specific. Let me make it easy for you.

A useful way to think about Solana is as a giant distributed filesystem. Once I started looking at it that way, the account model made much more sense.

Everything is an account.

Wallets are accounts. Programs are accounts. Data storage is accounts. Even special network configuration objects are accounts.

Every account lives in a giant key-value store:

Address (32-byte public key) -> Account

You can think of the address as a file path and the account as the file itself.

The five fields every account has: lamports, data, owner, executable, rent_epoch

Let's look at them one by one:

Lamports

Lamports are the smallest unit of SOL.

1 SOL = 1,000,000,000 lamports

This field stores the account's SOL balance.

For example:{ "lamports": 2135000000 } equals: 2.135 SOL

Data

The data field is simply a byte array.

Programs use this space to store application state.

Examples:

Token balances
NFT metadata
User profiles
Staking information

Unlike a traditional database, Solana stores state directly inside accounts.

Owner

The owner field is one of the most important concepts on Solana. Owner = Program that controls this account. For a normal wallet account, you'll often see:
11111111111111111111111111111111
This is the System Program.

The owner determines who can modify the account.

Executable

This field tells Solana whether an account contains executable code.
"Executable = false" means it's a data account. "Executable = true" means it's a program account.

For example, the System Program account is executable because it contains code validators can run.

Rent Epoch Solana used this field to track rent collection.

Ownership Rules: Solana's Security Model

Only the account's owner program can:

Modify account data
Remove (debit) lamports from the account

However:

Anyone can send lamports to a writable account

This ownership model is one of the key reasons Solana programs remain secure and predictable.

Programs Don't Store Their Own State

This is usually the biggest surprise for Web2 developers. In many application frameworks, code and state live together.

On Solana, programs are intentionally stateless.

Instead:
Program Account: Contains executable code
Data Account: Stores application state

The program reads and writes data from separate accounts. Think of it like a web server interacting with a database. The server contains the business logic. The database contains the data. The same pattern exists on Solana:
Program = Web Server
Data Accounts = Database
This separation allows multiple accounts to reuse the same program logic.

Rent Exemption

To prevent people from creating unlimited accounts and filling the network with junk data, Solana requires accounts to maintain a minimum balance. This is called rent exemption. The required amount depends on the size of the account's data. For a basic account with no extra data, it's roughly:0.00089 SOL.
You can check the exact value using: solana rent 0

or through the RPC method: getMinimumBalanceForRentExemption

As long as the account maintains the required balance, it remains rent-exempt and stays on-chain.

A Filesystem Analogy

The filesystem analogy helped me understand Solana much faster than blockchain terminology.

Imagine:

Filesystem
├── Files
├── Executables
├── Metadata
└── Permissions

Now map that to Solana:

Solana
├── Accounts
├── Programs
├── Account Metadata
└── Ownership Rules

More specifically:

Filesystem Solana
File Account
File contents Data
File owner Owner Program
Executable file Program Account
Documents Data Accounts
Operating System Kernel System Program

The System Program acts a bit like an operating system kernel. It handles core operations such as:

Creating accounts
Transferring SOL
Assigning ownership
Allocating storage

Everything else builds on top of that foundation.

Transactions in Solana

ajith pkumar — Mon, 18 May 2026 14:50:34 +0000

A few days ago, I knew almost nothing about how Solana transactions actually worked. I thought sending a transaction would feel similar to making an API request in a typical backend application — send data, get a response, done. But after building and debugging transactions on Solana devnet, I realized the mental model is very different.

In Solana, you interact directly with a decentralized state machine where every action is signed, validated, recorded on-chain, and eventually finalized by the network. They require cryptographic signatures. They expire after a short time because of blockhash validity. That last part surprised me the most. Transactions are tied to a recent blockhash, which means they cannot stay valid forever.
I started by creating a simple CLI tool that sends SOL on devnet.
One concept that really changed my understanding was commitment levels.
Initially, I assumed a transaction was either successful or failed. But Solana actually has multiple confirmation stages:

processed
confirmed
finalized

I added polling logic to track transactions through each stage.

await waitForCommitment(rpc, signature, "confirmed");
await waitForCommitment(rpc, signature, "finalized");

That made me realize blockchain confirmations are not instant yes/no responses. The take time, a transaction that is confirmed is updated to finalized only after 30+ blocks are stacked in front of it. This only takes few seconds. They represent increasing confidence from the network.
Failed Transactions Taught Me More Than Successful Ones. At the end we get the transaction signature providing all the details of the transaction.

One of the most useful exercises was intentionally breaking transactions.
What surprised me was that failed transactions can still consume fees. That’s why balance checks before sending are important.

The biggest lesson for me was understanding that transactions are not just “requests.” They are signed, time-sensitive that become part of a permanent public ledger.

I still have a lot to learn, especially around programs, PDAs, and full dApp architecture, but building and debugging transactions made Solana feel much more real and approachable.

Day 13: Solana I expected blockchain data to be complicated. But it’s essentially a public database where every transaction, account, and state change can be queried openly. Now I would like to understand solana contracts and dApps, create one of my own.

ajith pkumar — Fri, 08 May 2026 16:41:35 +0000