Solana Accounts Explained: What Every Developer Must Know
By Mudassir Khan — Agentic AI Consultant & AI Systems Architect, Islamabad, Pakistan
Quick answer
What is a Solana account? A Solana account is the fundamental unit of storage on the network. Every piece of state lives in an account — wallets, program data, token balances, and deployed bytecode alike. Each account has a public key address, a lamport balance, an owner program, and a raw data field.
Section 01 · Concept
Everything on Solana is an account
Solana stores all state in accounts. If that sounds different from what you know, it is — and understanding it is the prerequisite for everything else.
If you are coming from Ethereum, the mental model shift takes a moment. In Ethereum, a smart contract stores both its executable bytecode and its own state in a single place. Solana separates those two concerns completely. A program account holds only compiled code. All state lives in separate data accounts that the program owns and manages.
This design is not accidental. When the runtime processes a transaction, it looks at which accounts that transaction touches and runs non overlapping transactions in parallel. The explicit account list is what makes Solana’s parallel execution possible. If state were implicit inside contracts, the runtime would not know what to lock.
Read What Is Solana? first if you want the full picture of how the network fits together before going deeper on accounts.
Section 02 · Anatomy
The six fields of every account
Every account on Solana, regardless of type, contains exactly these six fields.
key: Pubkey (32 bytes)
The account's address. This is a 32-byte public key that uniquely identifies the account on the network. For wallet accounts it is derived from a keypair. For Program Derived Addresses there is no corresponding private key.
lamports: u64
The account's SOL balance in lamports (1 SOL = 1,000,000,000 lamports). This balance must stay at or above the rent-exempt minimum for the account to persist. Transfers deduct and credit this field.
owner: Pubkey
The program that is allowed to modify this account's data and lamports. Only the owning program can write to an account. The System Program (address 11111111111111111111111111111111) owns all wallet accounts by default.
data: Vec<u8>
Raw bytes. For data accounts this holds Borsh-serialized program state. For program accounts it holds compiled BPF bytecode. For wallet accounts this is empty.
executable: bool
When true, the account contains a program that the runtime can load and execute. Executable accounts are read-only — you cannot modify a deployed program's bytecode through normal instruction calls.
rent_epoch: u64
A legacy field that tracked which epoch rent was last collected. The rent epoch system is deprecated and this field is now always 0 on new accounts, but it remains in the account struct for backwards compatibility.
Section 03 · Types
The four main account types in practice
The six fields stay the same across all accounts. What differs is how those fields are set.
Wallet account
Owned by the System Program (11111111111111111111111111111111). Holds a SOL balance. The data field is empty. A private key exists for it, so the owner can sign transactions. This is the account your browser wallet manages.
Data account
Owned by the program that manages it. Holds serialized program state in the data field — a user's score, an order book entry, a config struct. The account address is usually a PDA derived from seeds so the program can find it deterministically.
Program account
Has executable set to true. The data field contains compiled BPF bytecode. The runtime loads this bytecode when a transaction targets the program's address. Programs are stateless — they read from and write to separate data accounts.
Token account
Owned by the SPL Token Program. Holds a token balance for one specific mint and one specific owner. Always exactly 165 bytes. Every wallet that holds a token has a separate token account per mint — not one account per token type.
Section 04 · Rent
Rent and how accounts stay alive
Every byte an account stores costs lamports. Understand rent exemption before you create your first account.
Solana charges rent to keep account storage economically sustainable. Every account must hold a minimum lamport balance proportional to the number of bytes it stores. An account that holds exactly this minimum is called rent exempt, and it persists on chain indefinitely. The numbers are concrete: 0 bytes requires roughly 0.00089 SOL, 128 bytes requires roughly 0.00203 SOL, and 1 KB requires roughly 0.00940 SOL.
In practice, you always initialize accounts with the rent-exempt amount. The RPC method getMinimumBalanceForRentExemption(dataSize) returns the exact lamport amount for a given byte count. Pass it into the lamports field of the create account instruction and you are done.
What happens if an account drops below the minimum?
If an account's lamport balance falls below the rent-exempt threshold, the runtime can reclaim its lamports and close the account. In older Solana code you may see manual rent payments every epoch — ignore that pattern. Always fund to rent-exempt from the start.
Programs also let you explicitly close an account by zeroing its data and transferring its lamports to a recipient. This reclaims the rent deposit and is the correct way to clean up state your users no longer need.
Section 05 · Code
Reading account data in a Solana program
Here is what working with accounts looks like in native Rust and from the CLI.
// Reading account data in a Solana program (native, no Anchor)
use solana_program::{
account_info::{next_account_info, AccountInfo},
entrypoint::ProgramResult,
msg,
pubkey::Pubkey,
};
pub fn process_instruction(
_program_id: &Pubkey,
accounts: &[AccountInfo],
_instruction_data: &[u8],
) -> ProgramResult {
let accounts_iter = &mut accounts.iter();
let user_account = next_account_info(accounts_iter)?;
// Lamport balance
let balance = user_account.lamports();
msg!("Balance: {} lamports", balance);
// Owner of the account
msg!("Owner: {}", user_account.owner);
// Whether it is a program (executable)
msg!("Executable: {}", user_account.executable);
// Raw data bytes
let data = user_account.data.borrow();
msg!("Data length: {} bytes", data.len());
Ok(())
}# Inspect any account with the Solana CLI
solana account <ADDRESS>
# Example — inspecting a wallet account:
# Public Key: 9B5XszUGdMaxCZ7uSQhPzdks5ZQSmWxrmzCSvtJ6Ns6g
# Balance: 1.50000000 SOL
# Owner: 11111111111111111111111111111111 <- System Program owns wallets
# Executable: false
# Rent Epoch: 0
# Calculate rent-exempt minimum for an account size
solana rent 128 # bytes
# Rent-exempt minimum: 0.00203928 SOL// Client: calculate rent-exempt minimum before creating an account
import { Connection } from "@solana/web3.js";
const connection = new Connection("https://api.devnet.solana.com");
// How many lamports does a 128-byte account need to be rent exempt?
const rentExempt = await connection.getMinimumBalanceForRentExemption(128);
console.log(`Rent exempt minimum: ${rentExempt} lamports`);
// -> ~1,400,000 lamports (approximately 0.0014 SOL -- varies with network)For deeper coverage of how programs interact with accounts through instructions, read Solana Transactions Explained. If you want the Anchor framework’s account abstractions, the Anchor Accounts Deep Dive covers #[account] macros, init constraints, and PDA seeds in detail.
If you are building a Solana program for production and need architectural guidance, the blockchain development service covers program design, account layout, and security review from the start.
Section 06 · FAQ
Frequently asked questions
What is a Solana account?
A Solana account is the fundamental unit of storage on the Solana blockchain. Every piece of state — a wallet balance, a program's data, a token holding, a deployed program — lives inside an account. Each account has a 32-byte public key address, a lamport balance, an owner field that specifies which program controls it, and a data field that holds raw bytes. Programs read from and write to accounts through instructions rather than managing their own internal storage.
What is the difference between a wallet and a program account in Solana?
A wallet account is a regular keypair account owned by the System Program, the built-in Solana program at address 11111111111111111111111111111111. It holds a SOL balance and has no executable code. A program account has the executable flag set to true, meaning it contains compiled BPF bytecode rather than data. When you deploy a Solana program, you create a program account that the runtime can load and execute when a transaction targets its address.
What is rent in Solana?
Rent is the mechanism Solana uses to incentivize keeping account data small. Every account must maintain a minimum lamport balance proportional to the number of bytes it stores. An account that holds this minimum amount is called rent exempt, and it persists on chain indefinitely. If an account drops below the rent-exempt minimum, the runtime can reclaim its lamports and close the account. In practice, accounts are always initialized with the rent-exempt amount using getMinimumBalanceForRentExemption.
What is a Program Derived Address (PDA) in Solana?
A Program Derived Address is an account whose address is derived deterministically from a set of seeds and a program ID, rather than from a cryptographic keypair. Because a PDA is off the elliptic curve, no private key exists for it — only the program can sign on behalf of a PDA using the invoke_signed function. PDAs are the standard way for programs to own data accounts, manage vaults, and store state keyed to specific users or resources without relying on external key management.
How do Solana accounts compare to Ethereum accounts?
Ethereum and Solana both have accounts, but their purpose differs significantly. In Ethereum, a smart contract account stores both executable code and its own state in a single place. In Solana, those two concerns are separated. A program account stores only compiled code and is stateless. All state lives in separate data accounts owned by the program. This separation allows Solana's runtime to process many transactions in parallel, because it can identify which accounts each transaction touches and run non-overlapping transactions simultaneously.
Written by Mudassir Khan
Agentic AI consultant and AI systems architect based in Islamabad, Pakistan. CEO of Cube A Cloud. 38+ agentic AI launches delivered for global founders and CTOs.
View blockchain development service →See ChainTrust case study →
Solana Transactions Explained: Structure, Fees, Lifecycle
A Solana transaction bundles instructions, signers, and a blockhash into one atomic packet. Learn how transactions are built, sent, and confirmed.
What Is Solana? A Beginner's Guide to the Blockchain
Learn what Solana is, why developers choose it over other blockchains, how Proof of History works, and how to set up your first dev environment.
Need an AI systems architect?
Book a 30-minute architecture call. I will sketch the high-level design for your use case and give you an honest view of the trade-offs.