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.
Top comments (0)