If you've built on Ethereum and you're now exploring Solana, the first thing that will trip you up isn't the language (Rust takes getting used to, but it's learnable). It's the mental model. Solana separates code from state at a fundamental level — and once you internalize that, everything else clicks.
This article walks through the core differences in how both chains store data, why Solana's design enables parallel execution, and what it means for you as a DeFi developer writing programs (the Solana term for smart contracts).
The Ethereum Model: Code and State Live Together
In Ethereum, a smart contract bundles two things in one address:
The bytecode (the logic)
The state (the storage variables — balances, mappings, counters)
When you deploy an ERC-20 token, a single contract address owns both the transfer logic and the mapping that tracks every holder's balance. The contract is the source of truth for both.
This design is intuitive but has a structural consequence: if two transactions touch the same contract state at the same time, they must be serialized. Ethereum's EVM processes transactions sequentially by default. There's no safe way to run them in parallel when they share mutable state.
The Solana Model: Code and State Are Separate
Solana takes a different approach. Every piece of data on the chain lives in an account — a flat byte array with a fixed size, an owner program, and a lamport balance (SOL's atomic unit). That's it.
Here's the critical distinction:
Programs (executable accounts) hold only code. They are stateless and immutable after deployment.
Data accounts hold state. They are owned by a program, which is the only entity allowed to write to them.
// In an Anchor program, you define a data account like this:
[account]
pub struct UserPosition {
pub owner: Pubkey, // who owns this position
pub amount_deposited: u64, // tokens deposited (in lamports)
pub entry_price: u64, // price at deposit time
pub bump: u8, // PDA bump seed
}
// The program itself never stores this data — it reads from and writes to
// separate UserPosition accounts passed in by the caller.
When a user calls your DeFi program, they pass in all the accounts the transaction will touch — up front, before execution begins. The runtime inspects that list, identifies which accounts are being written to, and schedules transactions in parallel as long as they don't share write-locked accounts.
This is how Solana achieves 50,000+ TPS: the architecture makes parallelism structurally possible.
Program Derived Addresses: Deterministic State Without a Database
One of the most powerful patterns in Solana DeFi is the Program Derived Address (PDA). It solves a real problem: how does your program know where to find a user's data account?
On Ethereum, you'd typically use a mapping inside the contract:
mapping(address => UserPosition) public positions;
On Solana, you derive the address deterministically from seeds:
// Deriving a PDA for a user's position in your protocol
let seeds = &[
b"position", // static prefix — scopes to your program
user.key().as_ref(), // the user's wallet pubkey
&pool_id.to_le_bytes() // which pool they're in
];
let (pda, bump) = Pubkey::find_program_address(seeds, program_id);
// pda is always the same for the same (user, pool_id) combination
// No database lookup needed — you compute the address, then load the account
This has meaningful implications for DeFi protocols:
No global state bottleneck. Each user has their own data account. Two users interacting with the same protocol in the same block don't contend for the same account.
Composability is explicit. When your protocol calls another protocol (say, depositing into a lending pool), the accounts being touched are declared in the transaction. Cross-protocol interactions are auditable before execution.
Storage has a cost. Creating an account requires a rent-exempt lamport deposit proportional to its byte size. Closing an account returns that SOL. This makes state lifecycle management a first-class concern — something Ethereum developers aren't used to thinking about.
What This Means for DeFi Architecture
The account model shapes how you design protocols at every level.
Liquidity pools work differently. In a Uniswap V2 pool on Ethereum, one contract holds both the logic and the reserves. On Solana (Raydium, Orca, Meteora), the program is stateless — the reserves live in separate token accounts owned by the protocol's authority PDA.
The program computes the swap math and moves tokens between those accounts.
User positions are isolated by design. Perpetuals protocols like Drift don't store all positions in a single mapping. Each trader has a User account and a UserStats account derived from their pubkey. Liquidations can run in parallel across different users because the accounts don't overlap.
Cranks and crank-incentives exist because of pull-based design. Solana doesn't have block.timestamp as a trigger for logic — there's no native scheduler. Protocols that need time-based updates (funding rates, oracle refreshes, interest accrual) rely on off-chain "cranks" that call update instructions. This is an architectural pattern you don't see on Ethereum, and it's worth building for from day one.
Getting Your Bearings: A Practical Checklist
If you're porting a DeFi protocol from Ethereum to Solana, or building fresh:
Identify every piece of state your protocol needs. Map it to discrete accounts. Think about who owns each account and what seeds derive its address.
Declare account constraints explicitly. Anchor's #[account(...)] macros enforce ownership, signer requirements, and PDA derivation at the framework level — use them.
Design for rent. Decide upfront which accounts the user creates (and pays for) vs. which ones the protocol creates on their behalf.
Think about account limits. A single Solana transaction can reference up to 64 accounts. Complex DeFi operations (e.g., multi-hop swaps through three pools) hit this limit fast. Plan your instruction decomposition accordingly.
Read a real protocol. The Drift Protocol and Kamino Finance repos are public and well-structured. Reading 500 lines of their account definitions teaches more than most tutorials.
Where to Go Next
The account model is the foundation everything else builds on. Once it's clear, the rest of Solana development — Cross-Program Invocations, versioned transactions, Anchor's constraints system — starts making sense structurally rather than feeling like arbitrary rules.
If you want to go deeper:
Anchor's official docs cover account constraints and PDA patterns in detail
The Solana Cookbook has worked examples for common account operations
The solana-program crate documentation explains the runtime's account validation rules at the lowest level
The learning curve is real, but the architecture is coherent. It was designed to be fast by design, not patched to be fast after the fact.