Understanding Solana’s Account Model From a Web2 Perspective

In a previous article I posted on my #100daysofsolana journey, I wrote about how everything on Solana is an account. I spoke briefly about the difference between wallet accounts and program accounts. You can read the article here

In this article, we will go more in depth because I now have more knowledge after inspecting various accounts over the past few days.

Everything is an account. But not all accounts are the same

Unlike Ethereum, which separates wallet accounts from smart contracts, Solana uses the same model for all accounts. They all have the same five fields, but what differs is the meaning and value of those fields.

The Account's Five Fields

Every account on the Solana network has these five fields. Here's what they actually mean:

1.Lamports
This is the field that carries information on how much the account holds. Solana stores balances in lamports.

1 SOL = 1 billion lamports.

Sometimes, depending on how you are viewing the account structure, this field shows up as Balance with the value in SOL. Just know it's showing the same thing in a more human readable format.

2.Data
The data field refers to the storage space the account occupies. In Web2, this is similar to a database entry. It is stored as a raw byte array.
For example, the Token Program's data field looks like this in the raw output:

0000: 02 00 00 00 27 f1 90 b1 e8 ca df f9 f8 fc 45 cb
0010: d3 af 98 b8 8e 5f ac 42 0d 97 dd 37 ce 71 4c 44

In a more readable format, it shows up as `Length: 36 (0x24) bytes.

Wallet accounts have an empty or zero data field because they are simple SOL holders. They don't store anything beyond a balance. But program accounts, token accounts, and NFTs all have data because they store state.

This is also where something important happens:
Programs on Solana don't store their own state inside themselves. A program's executable code lives in one account, and the data it reads or writes lives in completely separate accounts. So when you see a program account with only 36 bytes, that's not where the user balances are, those live in their own individual accounts that the program manages externally.

3.Owner
This field tells us which program controls and is able to modify the account. Wallet accounts are owned by the System Program. Program accounts are typically owned by the BPF Loader. Built-in system programs, like the System Program itself, are owned by the Native Loader.
Solana has a security model in place such that a program can only write to the accounts it owns.

4.Executable
This is a boolean field that returns true or false. It tells us whether the account has a set of instructions written in code that it can run.
Program accounts have executable: true because they run programmed instructions. Other accounts like wallets and token accounts have executable: false because they don't run code, they just hold state.

5.Rent Epoch
Solana has a rent system; a cost for storing data on-chain. The rent epoch field was originally designed to show when the next rent would be deducted from the balance. Currently, accounts have been made rent-exempt by being funded with enough SOL upfront, which made this field less important.

How to think about it as a Web2 developer

We can compare Solana's account model to how a React app makes calls to a backend REST API in Web2. Stay with me.

The Solana program is like a backend API, and accounts are the databases the API reads or writes to. The frontend sends a request, and the backend(the program), executes what changes need to happen. On Solana, that request is called a transaction. Just like a REST API hits a POST or PUT endpoint, a Solana transaction invokes a specific program instruction.

The main thing to remember is that neither system stores information inside the request handler. Instead, data is stored separately, in a database in Web2, or in accounts on Solana. These accounts are like rows in a database. Each one holds some information about the application, identified by a special key.

So when you look at a Solana account, you can think of it like a record in a database:

• The public key is like the identifier for the record
• The data field is the actual information in the record
• The lamports field is like a balance or credit attached to the record
• The owner field is the service that is allowed to make changes to the record

Solana's ownership rules

Like I mentioned earlier, in Solana only the owner of an account can modify it. This sounds straightforward, but let's drive it home from both a Web2 and Solana perspective.

Only the owner can modify an account, but anyone can credit it. Meaning anyone can send SOL to any account. This is the security model Solana enforces at the protocol level.

Just like in a REST API system, only the backend service that owns a database table is allowed to modify the rows. Other services can request to read the data, but they can't write to it unless they're authorized. Solana enforces the same idea, only the owner program is allowed to mutate the account's data.

So if a token account is owned by the Token Program, no other program can directly edit its balance. They must go through the Token Program's instructions, just like a frontend must go through the correct API endpoint instead of writing directly to the database.

What are rent exemptions?

I mentioned that recently, accounts have been made rent-exempt. What does that actually mean?

In Solana, every account is like data stored on-chain, and you have to pay some amount to keep it there. That's rent. For a basic account with no extra data, it's roughly 0.00089 SOL.
But it's not a fixed amount, it's calculated based on the size of the data an account holds using the rent calculation formula.

In older versions of the model, this rent was collected periodically. When an account didn't have enough lamports, the network would reclaim it.But now, instead of paying periodically, you just fund the account with enough SOL to meet the minimum balance threshold. That makes it permanently rent-exempt. The SOL isn't spent, it's held as a deposit. Close the account, and you get it back.

You can check the rent exemption amount two ways:

Using the RPC method: getMinimumBalanceForRentExemption

Or through the CLI:

solana rent <DATA_SIZE>

Conclusion

When I started this journey, fields like owner, executable, and rent epoch were a bit abstract to me. I was staring at output I couldn't read.

Now I can look at any account on Solana and tell you exactly what it is and what it does just from those five fields. That's the account model, and if you've followed along to this point, you can too.

Everything on Solana is an account. What differs is just the configuration. That's it. That's the whole foundation.
Once that lands, a lot of other Solana concepts start making sense on their own.

If you want to make it stick, don't just take my word for it. Run this yourself:

solana account $(solana adress)

Then try it on the Token Program, then the System Program. See the same five fields show up every time. That's the moment it clicks.