If you want to understand how Solana works under the hood, you have to understand accounts.
I like to think of the Solana blockchain as a distributed operating system, where every account is simply a file on a filesystem. Unlike traditional Web2 architectures where applications live on a server and data lives in a database, Solana stores everything using a unified file-type system.
Here is a breakdown of how these "files" work, what they contain, and how they shape the network.
The 5 Anatomy Fields of a Solana Account
Every single account on Solana shares the exact same five-field structure. This structure is mapped to a 32-byte address, ensuring it aligns perfectly with IPv6 minimum MTU requirements.
- Lamports: The account's SOL balance, where 1 SOL = 1,000,000,000 lamports.
- Data: A byte array that stores arbitrary state. For a wallet, this might be token balances; for a program, it stores the executable byte code.
- Owner: The specific program that controls the account (for most standard wallets, this is the System Program). Only the owner program can modify an account’s data or debit its lamports.
- Executable: A binary flag (true/false) that tells the network whether the account can execute code and instructions.
- Rent Epoch: A legacy field (now deprecated) previously used to track the balance an account needed to maintain to avoid paying storage rent. Today, almost all accounts are loaded with enough SOL to be permanently rent-exempt.
The Two Main Categories: Logic vs. Data
Solana strictly separates code from data. Because of this, accounts broadly fall into two categories:
1. Executable Accounts (The Apps)
These accounts have their executable flag set to true. They contain smart contract code (program logic) stored directly on the blockchain that automatically runs when specific conditions are met. Think of these as the applications or software running on the OS.
2. Non-Executable Accounts (The Databases)
These accounts cannot execute code. Instead, they store data-such as balances, user info, or state-that executable programs read from and write to. Think of these as the databases or storage files used by the apps.
The Four Functional Account Types
To make development practical, these categories are split into four functional types that you interact with daily:
| Account Type | Description | Web2 Analogy |
|---|---|---|
| System Accounts | Regular user wallets (e.g., Phantom or Solflare). They hold your SOL balance and do not execute code. | Your personal bank account |
| Program Accounts | Accounts that store compiled smart contract logic. They dictate how things work but don't hold user state. | The application software |
| Data Accounts | Accounts managed by programs to store specific information like user profiles, token balances, or settings. | A database row or file |
| Sysvars (System Variables) | Special global accounts that provide real-time network info (e.g., current time, fees, slot data). | The system clock / OS settings |
The Big Picture: Everything is a File
By looking at Solana through the lens of an operating system, the architecture becomes incredibly intuitive. Every account is just a file, and each file consists of two things:
Metadata: Who owns it, whether it can execute code, and how much money (lamports) it holds.
Contents: The actual data or program code stored inside.
In Solana, programs act on accounts rather than possessing their own internal memory. By treating everything as a unified file system, Solana achieves incredible speed, transparency, and composability.