How Solana's Account Model Differs from Ethereum — and Why It Matters for DeFi Developers

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 lifec