If you come from Web2 development, the easiest way to understand Solana is to stop thinking about contracts first and start thinking about accounts.
On Solana, almost everything is an account. A wallet is an account. A token balance is an account. A program which is Solana's version of a smart contract is also an account. Instead of storing application state in a database table or inside a contract object, Solana stores state in accounts that live on-chain.
A Solana account is like a file in a filesystem. It has an address, some metadata, and some contents. The address is a 32-byte public key. The metadata tells you who owns it, whether it is executable, and how much SOL it holds. The contents are just raw bytes.
Every Solana account has five core fields:
{
"lamports": 1000000000,
"owner": "11111111111111111111111111111111",
"executable": false,
"rentEpoch": 18446744073709551615,
"data": []
}
lamports are the account's SOL balance. One SOL equals one billion lamports.
data is a byte array. This is where programs store custom state. A normal wallet account usually has zero bytes of data. A token account or NFT metadata account has structured data inside this field.
owner is the program that controls the account. This is one of the most important ideas in Solana. Only the owner program can modify an account's data or debit its lamports.
executable tells you whether the account is a program. If it is true, the account contains executable program code. If it is false, it is a regular data account.
rentEpoch is a legacy field. Today, accounts are generally rent-exempt, and this field is usually set to the maximum value.
The ownership rule is Solana's security model in one sentence: only the owning program can change an account's data. For example, your wallet is owned by the System Program, so the System Program handles SOL transfers. Token accounts are owned by the Token Program, so only the Token Program can move tokens or update token balances.
The part that surprises many Web2 developers is that Solana programs do not store their own state. Programs are stateless. A program account stores executable code, while separate data accounts store the actual application state.
A useful analogy is a web server and a database. The program is like the backend server: it contains the logic. The accounts are like database records: they contain the data. When a transaction runs it tells the program which accounts it wants to read or write.
This is different from Ethereum, where a smart contract usually owns both the code and the state together. On Solana code and state are separated. That separation is one reason Solana can process many transactions in parallel. If two transactions touch different accounts, they can often run at the same time.
There is also the idea of rent exemption. Because account data takes space on-chain accounts must hold a minimum SOL balance based on their size. This keeps the account alive. For a basic account with no extra data, the rent-exempt amount is small roughly around 0.00089 SOL. You can calculate exact values with the Solana CLI or the getMinimumBalanceForRentExemption RPC method.
So the mental model is simple:
Solana is a giant public key-value store. The key is an account address. The value is an account object with balance, owner, executable status, and raw data. Programs are accounts that contain code. Data accounts are accounts that contain state. The owner field decides who is allowed to modify what.
Once this clicks, the rest of Solana starts to make more sense. Tokens, NFTs, DeFi protocols, staking, governance, and games all use the same basic building block: accounts.
Top comments (0)