If you're a Web2 developer looking at Solana for the first time, the account
model will either click immediately or confuse you completely. I was in the
second camp — until I spent 26 days building on Solana daily as part of the
100 Days of Solana challenge.
Here's the explanation I wish I'd had on Day 1.
The Filesystem Analogy
Think of Solana like a filesystem.
Each account is a file. Every file has metadata (owner, permissions, size)
and contents (data). Programs are executable files. Data accounts are the
documents those programs read and write. The System Program is the
operating system kernel that manages file creation and ownership transfers.
That's the whole model. Let's go deeper.
Everything Is an Account
In Ethereum, there are two types of things: externally owned accounts (wallets)
and contract accounts (smart contracts). They behave differently.
Solana has one type: accounts. Everything — your wallet, a smart contract,
a token mint, a clock showing the current time — is an account. They all live
in one flat key-value store where the key is a 32-byte address and the value
is the account itself.
This uniformity is powerful once it clicks.
The Five Fields Every Account Has
Every single Solana account — whether it's your wallet or the System Program
itself — has exactly five fields. Here's what they look like when you inspect
your own wallet with the Solana CLI:
solana account $(solana address)
Public Key: AWKYsCGBcfGLSz6QpmXzRn7EJ9fRhiJsjYSLDV3c9L9y
Balance: 6.137925 SOL
Owner: 11111111111111111111111111111111
Executable: false
Rent Epoch: 18446744073709551615
And in JSON:
{
"lamports": 6137925000,
"data": ["", "base64"],
"owner": "11111111111111111111111111111111",
"executable": false,
"rentEpoch": 18446744073709551615,
"space": 0
}
Let's break each field down:
1. lamports — your SOL balance in the smallest unit. 1 SOL = 1,000,000,000
lamports. My wallet has 6,137,925,000 lamports = 6.137925 SOL. Think of
lamports like wei in Ethereum, or paise in INR — the atomic unit.
2. data — a raw byte array. For a basic wallet, this is empty (0 bytes).
For a token mint, it's 82 bytes of structured data. For a program, it's the
compiled bytecode. This field holds the entire state of the account.
3. owner — the program that controls this account. My wallet is owned by
11111111111111111111111111111111 — the System Program. Only the owner program
can modify the account's data or debit its lamports. Anyone can add lamports,
but only the owner can remove them. This one rule is most of Solana's
security model.
4. executable — a boolean. false for wallets and data accounts. true
for programs. When you call a program, Solana checks this flag first.
5. rent_epoch — deprecated. Ignore it. It's always set to the maximum u64
value (18446744073709551615) for all rent-exempt accounts, which is everything
on mainnet today.
Programs Don't Store Their Own State
This is the part that surprises every Web2 developer.
In Web2, a server typically owns its own database. In Solana, programs are
stateless. A program's executable code lives in one account. Any data it
needs to read or write lives in separate data accounts that are passed in
with each transaction.
Here's the direct comparison:
| Web2 | Solana |
|---|---|
| Web server | Program account (executable=true) |
| Database | Data account (executable=false) |
| Database row | Individual account's data field |
| HTTP request | Transaction instruction |
| Request body | Instruction data + account list |
Why does this matter? Because it means Solana can process transactions in
parallel. If two transactions touch different accounts, they can run at the
same time. That's a big reason Solana achieves 3,000–4,000 TPS on mainnet.
The Ownership Rules Are Simple But Powerful
Three rules govern everything:
- Only the owner program can modify an account's data
- Only the owner program can debit lamports from an account
- Anyone can credit (send) lamports to any account
That's it. No complex permission system. No role-based access control. Just:
you own it, you control it.
When you send SOL to someone, the System Program (owner of both wallets)
executes the transfer. When a token program moves a token, it's the owner of
the token account doing the write. The ownership chain is always clear.
Rent Exemption
Every account must hold a minimum lamport balance proportional to its data
size to stay on-chain permanently. This is called being rent-exempt.
For a basic wallet (0 bytes of data):
solana rent 0
# Rent-exempt minimum: 0.00089088 SOL
For a token mint account (82 bytes):
solana rent 82
# Rent-exempt minimum: 0.0015 SOL
Think of it as a deposit you make to reserve space on the network. You get it
back if you ever close the account. The network needs this mechanism to prevent
people from spamming millions of empty accounts.
Seeing It All in Practice
After 26 days of building on Solana, the account model stopped being abstract
and became obvious. When I inspected the System Program itself:
solana account 11111111111111111111111111111111
Owner: NativeLoader1111111111111111111111111111111
Executable: true
Data: system_program ← literally the program name in bytes
And the Clock sysvar:
solana account SysvarC1ock11111111111111111111111111111111
Owner: Sysvar1111111111111111111111111111111111111
Executable: false
Length: 40 bytes ← slot, epoch, unix timestamp packed as binary
The pattern is always the same: executable=true means it's code,
executable=false means it's data. The owner tells you who controls it. The
data tells you what it stores.
The Mental Model That Clicked For Me
After weeks of building, here's the one-sentence summary:
Solana is a global key-value store. Keys are 32-byte addresses. Values are
accounts with 5 fields. Programs are accounts that transform other accounts
when you call them.
Everything else — tokens, NFTs, DeFi protocols, oracles — is built on top of
this foundation. Once you see it, you can't unsee it.
I'm building in public with the 100 Days of Solana
challenge by MLH. Follow along on GitHub
and X/Twitter.
Day 27 of 100. #100DaysOfSolana
Top comments (0)