Write about the account model

Solana’s account model can feel confusing at first. Terms like lamports, owners, and program accounts sound very blockchain-specific, and when you inspect a Solana account in the CLI or Explorer, the JSON output can look intimidating.

But once you stop thinking about Solana like Ethereum and start thinking about it like a filesystem or database system, things begin to click.

In this article, I’ll break down Solana’s account model in plain English for developers who have never worked with blockchain before.

Everything on Solana Is an Account

One of the biggest differences between Solana and Ethereum is how state is stored.

In Ethereum, there are two main account types:

Externally Owned Accounts (EOAs) → user wallets
Contract Accounts → smart contracts

Solana simplifies this idea.

On Solana, everything is an account:

Wallets
Smart contracts (called programs)
Token balances
NFTs
Application state

All of them are stored using the same account structure.

You can think of Solana like a giant key-value database:

Key Value
32-byte public address Account data

Each account lives at a unique public address and contains metadata plus optional data.

A Web2 Analogy: Solana as a Filesystem

The easiest way to understand Solana accounts is to compare them to files in an operating system.

Imagine:

Each account = a file
The data field = file contents
The owner = which program controls the file
Programs = executable files
Data accounts = documents/databases
The System Program = operating system kernel

Programs don’t directly “own” all their data internally. Instead, they read and write to separate accounts, similar to how a backend server interacts with a database.

This design makes Solana extremely flexible and parallelizable.

The Five Fields Every Account Has

Every Solana account follows the same structure.

Here are the five important fields:

1. Lamports

Lamports are the smallest unit of SOL.

1 SOL = 1,000,000,000 lamports

This field stores the account’s SOL balance.

Example:

"lamports": 2039280

That means the account holds 0.00203928 SOL.

1. Data

This is a byte array that stores arbitrary information.

Programs use this field to save state such as:

token balances
NFT metadata
game progress
user profiles

Example:

"data": ["", "base64"]

If the array is empty, the account stores no custom data.

1. Owner

The owner field defines which program controls the account.

Example:

"owner": "11111111111111111111111111111111"

That address belongs to the System Program.

The important rule is:

Only the owner program can modify the account’s data.

This is one of Solana’s core security mechanisms.

1. Executable

This is a boolean value:

true → the account contains executable program code
false → normal data account

Example:

"executable": false

Most accounts are non-executable.

Program accounts are special because they store deployable smart contract code.

1. Rent Epoch

This field is now deprecated and usually set to the maximum value.

Historically, it tracked when rent payments were due.

You’ll still see it in account output, but modern Solana apps rarely interact with it directly.

Ownership Rules: Solana’s Security Model

Solana’s ownership model is surprisingly simple.

Rule 1:

Only the owner program can:

modify account data
subtract lamports from the account
Rule 2:

Anyone can send lamports to any writable account.

This is similar to how anyone can transfer money to your bank account, but only you can spend from it.

Because ownership is enforced by the runtime itself, programs cannot randomly modify accounts they do not control.

The Concept That Surprises Most Developers

Here’s the part that usually shocks Web2 developers:

Programs Don’t Store Their Own State

In Ethereum, smart contracts usually contain both:

code
storage/state

Solana separates them.

A Solana program is mostly stateless.

Instead:

Program account → stores executable code
Data accounts → store application state

Think of it like this:

Web2 Backend Solana
Express server Program
PostgreSQL database Data accounts

The program reads and writes data from separate accounts passed into each transaction.

This architecture allows Solana to process many transactions in parallel because the runtime already knows which accounts a transaction will touch.

Rent Exemption

Accounts on Solana are not free.

Every account must maintain a minimum SOL balance based on how much data it stores.

This is called rent exemption.

Why?

Because validators need storage resources to keep accounts on-chain.

For a basic empty account, the minimum balance is roughly:

0.00089 SOL

Larger accounts require more lamports.

You can calculate rent exemption using:

solana rent

Or through the RPC method:

getMinimumBalanceForRentExemption

If an account doesn’t maintain enough balance, it may eventually be cleaned up by the network.

Example Account Output

Here’s what a typical account might look like:

{
"lamports": 2039280,
"owner": "11111111111111111111111111111111",
"executable": false,
"rentEpoch": 18446744073709551615,
"data": ["", "base64"]
}

Now you can actually read this:

It holds some SOL
It’s controlled by the System Program
It is not executable
It stores no custom data
It is rent exempt

That’s the account model in action.

Why Solana Uses This Design

At first, separating programs from state can feel awkward.

But it gives Solana major advantages:

better parallel transaction execution
predictable state access
flexible storage patterns
improved scalability

Instead of programs hiding internal storage, all state is explicit and passed into transactions directly.

That design is one of the reasons Solana can achieve very high throughput.

Final Thoughts

The Solana account model is the foundation of everything on the network.

Once you understand:

accounts
ownership
data storage
rent exemption
stateless programs

…you can understand how tokens, NFTs, DeFi protocols, and nearly every Solana application works internally.

For Web2 developers, the biggest mental shift is this:

On Solana, programs behave more like APIs interacting with databases than traditional objects storing their own internal state.

And honestly, once that clicks, the entire ecosystem becomes much easier to understand.

For more details, check out the official documentation from Solana Foundation and the developer resources on Solana Docs and DEV Community.