In Solana, nearly all on-chain state is represented through accounts. Unlike traditional blockchain architectures that tightly couple code and storage together, Solana separates executable programs from state storage. This design makes the Solana account model one of the most important concepts for developers building on the network.
Understanding account fields is essential when working with wallets, SPL tokens, NFTs, PDAs, or DeFi protocols.
The Core Structure of a Solana Account
A Solana account is typically represented internally as:
pub struct Account {
pub lamports: u64,
pub data: Vec<u8>,
pub owner: Pubkey,
pub executable: bool,
pub rent_epoch: Epoch,
}
Each field serves a different purpose within the Solana runtime.
Lamports
The
lamports
field stores the SOL balance associated with the account.
pub lamports: u64
Lamports are the smallest unit of SOL.
1 SOL = 1,000,000,000 lamports
This is conceptually similar to:
- Wei in Ethereum
- Satoshi in Bitcoin
Lamports are used for:
- Transaction fees
- Rent exemption
- Holding SOL balances
- Funding new accounts
For example:
5 SOL = 5,000,000,000 lamports
Every account on Solana must maintain a certain balance to remain active on-chain.
Data
The
data
field stores arbitrary binary data.
pub data: Vec<u8>
This is where application state is stored.
In Solana, programs are stateless executables, while data accounts hold mutable state separately. Because of this architecture, nearly every decentralized application relies heavily on account data layouts.
Examples of stored data include:
SPL Token Accounts
A token account typically stores:
- Mint address
- Owner address
- Token amount
- Delegation information
- Account state
NFT Metadata
NFT metadata accounts may contain:
- Name
- Symbol
- Metadata URI
- Royalty configuration
- Creator addresses
DeFi Protocols
Liquidity pools and AMMs often store:
- Pool reserves
- Fee structures
- LP supply
- Administrative settings
Most Solana programs serialize account data using formats such as:
- Borsh
- Anchor serialization
- Raw byte layouts
Owner
The
owner
field specifies which program controls the account.
pub owner: Pubkey
This is one of the most important security mechanisms in Solana.
Only the owner program is allowed to modify the account’s data field.
For example:
System Program
11111111111111111111111111111111
The System Program owns standard SOL wallet accounts.
SPL Token Program
The SPL Token Program owns:
- Token accounts
- Mint accounts
Custom Programs
If a developer creates a PDA account for a custom protocol, the owner field is usually set to the project’s program ID.
This ownership model creates strict execution boundaries between programs and prevents unauthorized state modifications.
Executable
The
executable
field determines whether the account contains executable program code.
pub executable: bool
If the value is:
true
the account is treated as a program account.
Program accounts store compiled BPF bytecode that can be executed by the Solana runtime.
Typical examples include:
Account TypeexecutableWallet AccountfalseToken AccountfalsePDA AccountfalseProgram Accounttrue
Most accounts on Solana are non-executable data accounts.
Rent Epoch
The
rent_epoch
field is related to Solana’s rent system.
pub rent_epoch: Epoch
Because on-chain storage consumes validator resources, Solana originally introduced rent to prevent unlimited storage growth.
Accounts with insufficient balances could eventually be reclaimed by the network.
Today, most applications avoid rent collection entirely by making accounts rent-exempt.
Developers usually calculate the minimum balance required using:
getMinimumBalanceForRentExemption(space)
Once an account holds enough lamports to satisfy rent exemption requirements, it can remain permanently active.
Account Addresses and Pubkeys
When using RPC APIs, developers commonly see an additional field:
{
"pubkey": "...",
"account": {
"lamports": 123,
"owner": "...",
"data": "...",
"executable": false,
"rentEpoch": 123
}
}
The
pubkey
is the account address.
Interestingly, the public key is not stored inside the account structure itself. Instead, Solana internally maps addresses to account data structures.
Conceptually, this resembles:
HashMap<Pubkey, Account>
Why Solana Uses This Architecture
The account model is one of the reasons Solana achieves extremely high throughput.
Before executing a transaction, Solana requires the transaction to declare which accounts will be read or written.
This allows the runtime to determine:
- Which transactions conflict
- Which transactions can run in parallel
- Which state accesses are isolated
As a result, Solana can process many independent transactions simultaneously rather than executing everything sequentially.
This parallel execution model is fundamentally different from many traditional blockchains.
