Solana Account Fundamentals: Part 1 -The Building Blocks
Solana’s account system forms the backbone of its high-performance blockchain architecture. In this comprehensive guide, we’ll explore how Solana accounts work, their fundamental properties, and why they’re crucial for developing efficient blockchain applications.
This article assumes that you have some prior knowledge of Rust
What is a Solana Account?
A Solana account is a fundamental data structure that stores both tokens and data on the blockchain. Every account in the Solana network has a unique 32-byte public key address and can hold SOL tokens, program code, or application data.
Think of Solana accounts as containers. Unlike your regular bank account that just holds money, Solana accounts can store both DATA and TOKENS. Pretty cool, right? Every time you interact with a Solana dApp, you’re actually working with these accounts behind the scenes.
Here’s the basic structure of a Solana account:
pub struct Account {
lamports: u64, // Your SOL tokens (1 SOL = 1 billion lamports
// think of it like `wei`)
data: Vec<u8>, // Where your account stores its data (in a vector)
owner: Pubkey, // The program that controls this account
executable: bool, // Can this account run as a program?
rent_epoch: u64, // When rent is due (more on this later!)
}Core Components of Solana Accounts
Public Key Address
Every Solana account is identified by a unique public key, generated using Ed25519 cryptography. This address serves as both the identifier and the public key for verifying transactions.
Account Ownership
In Solana’s architecture, programs own accounts — not users. This fundamental design choice enables Solana’s high security and performance. Only the owner program can modify an account’s data, enforcing strict access control at the protocol level.
I know, I know — it sounds strange, but stick with me here. Think of it like this: if accounts were safety deposit boxes, programs would be the bank, and you’d be the customer with the key.
Let’s say you want to transfer some tokens. You can’t just reach in and move them — you need to ask the token program (the owner) to do it for you. This might seem like extra work, but it’s actually brilliant for security.
Data Storage
Accounts store data directly in a byte array, allowing for:
- Fast, direct access to data
- Predictable storage costs
- Efficient data serialization
- Clear ownership boundaries
Let’s say you’re building a simple game on Solana. You might need an account that stores your data like something like this:
// Example game state stored in a PDA
#[account]
pub struct GameAccount {
player: Pubkey, // Player's wallet address
score: u64, // Current score
tokens_earned: u64, // In-game rewards
last_played: i64, // Timestamp
}Please ignore the syntax right now if you are unfamiliar with Anchor basics and focus more on the concept of data storage.
Understanding Account Types in Solana
System Accounts
System accounts are the most basic type of Solana account. They can hold SOL tokens and serve as user wallets. These accounts are owned by the System Program and form the foundation of user interaction with the Solana network.
Here’s a fun fact: every time you create a new Solana wallet, you’re actually creating a system account owned by the System Program.
Program Accounts
Program accounts store executable code (smart contracts) on the Solana blockchain. These accounts have their executable flag set to true and are owned by the BPF Loader. Program accounts are immutable by default, ensuring code security.
To understand these better think of these as the brains of the operation. We developers upload our code to program accounts. When you deploy a smart contract on Solana, you’re creating a program account that will contain the code of your program. The cool thing about program accounts is that they have their executable flag set to true, meaning they can actually run code!
Program Derived Addresses (PDAs)
Here’s where Solana gets really clever. PDAs are special accounts that are derived from programs — kind of like a program’s personal filing cabinet. They’re perfect for:
- Storing program data
- Creating predictable addresses
- Managing program state
The neat thing about PDAs is that no one can generate their private key — they’re truly program-controlled! You can read more about them here
Token Accounts
If you’ve ever used SPL tokens (Solana’s equivalent of ERC-20), you’ve used token accounts. Each token account represents your balance of a specific token. Here’s something that might surprise you: you need a separate token account for each type of token you own! And most importantly they are owned by the Token-Program which is a Program Account and contains code to manage the data of Token Accounts
Data Accounts
Data accounts store program state and user data. They’re owned by their respective programs and can only be modified through program instructions. This design ensures data integrity and controlled access.
This means that these accounts cannot be manually modified because they have Data in them. As per Solana’s architecture, only the Program’s code is allowed to make changes to them
For example: You have a Struct to store the details of a user’s stake data. So, what you will do is store this struct in a DATA Account and in order to modify that struct, only your Program’s Instructions (The Rust Code you have written) will be able to modify this data.
The Rent System: Why Your Accounts Need “Allowance”
Now, let’s talk about something unique to Solana — rent. Just like in the real world, storing data on Solana isn’t free. Your accounts need to pay rent to stay alive on the network. But don’t worry! If you keep enough SOL in your account (about 0.002 SOL per kilobyte), it becomes “rent-exempt” — like buying your apartment instead of renting it.
The rent calculation follows this formula:
let rent_exempt_minimum = account_size * LAMPORTS_PER_BYTE * 2;Best Practices for Account Management without Anchor
Anchor, the popular Solana development framework, simplifies account management while enforcing best practices. In this Article we will not deep dive into anchor but understand the core model of Solana first because it will make us understand Anchor faster
If you don’t understand this right away don’t worry. We will have a Separate Anchor series soon!
Size Planning:
Calculate account sizes carefully before initialization:
// Calculate account size with padding
const ACCOUNT_DISCRIMINATOR: usize = 8;
const GAME_STATE_SIZE: usize =
ACCOUNT_DISCRIMINATOR + // Required prefix
32 + // Pubkey
1 + // game_type
2 + // current_round
4 + // total_players
1; // is_activeRent Exemption:
Always make accounts rent-exempt during creation:
let rent = Rent::get()?;
let rent_exempt_lamports = rent.minimum_balance(GAME_STATE_SIZE);Owner Validation:
Always verify account ownership in your programs:
if account.owner != program_id {
return Err(ProgramError::IncorrectProgramId);
}Security Considerations
When working with Solana accounts, consider these security aspects:
- Account ownership verification
- Proper permission checks
- Secure data serialization
- Rent exemption status
Performance Implications
Solana’s account model contributes to its high performance through:
- Direct data access
- Parallel transaction processing
- Efficient state management
- Clear ownership boundaries
Next Steps
Understanding Solana’s account system is essential for building efficient blockchain applications. In Parts 2 and 3, we’ll explore more about account management, interactions and their real-world usage.
Start experimenting with these concepts in your local development environment. The best way to understand Solana accounts is to build with them.
Key Takeaway: Solana accounts provide a flexible, secure foundation for blockchain development through their unique ownership model and efficient data storage system.
