What Is an Account
In Solana, every bit of on-chain data lives inside an account. Your wallet balance is an account; compiled program code is an account; each token you hold, every liquidity pool, even Solana’s internal clock is an account. Ethereum divides its world into two categories–externally owned accounts and smart contracts–Solana has one single primitive and the entire state of the chain is simply a large map of 32 byte addresses mapped to accounts.
Think of it like a self-storage warehouse. Every locker has an address, contains contents and has only one manager on file. Any passerby can look at a locker but only the manager can move the contents. On Solana the manager is the owner program, and the rule is enforced by the runtime.
How Accounts Work Technically
Accounts in Solana contain four things: a lamport balance (lamports are 10e9th of a SOL), raw data as bytes, an owner program and an executable flag. Wallet accounts are initially owned by the System Program which processes simple SOL transactions. Your USDC is an account in the SPL Token program which is owned by a separate program. Only the SPL Token program has permission to update the data in that account and this is how your wallet balance cannot be modified by someone without a valid instruction.
Programs are also accounts which are denoted by the executable flag. A programs code is located within an account and the programs state (user positions, pool reserves, orderbooks) is stored in other accounts. Accounts are not free and require a deposit for storage, refundable upon account closure, proportional to their size, around 0.002 SOL for a standard token account.
This is where Solana really shines. Each transaction needs to pre-declare which accounts it will write to, and which it will read from. This is then processed by Solana’s runtime Sealevel, which allows two transactions that don’t touch the same accounts to execute simultaneously across multiple processor cores in parallel rather than sequentially. This is one of the primary reasons Solana can handle thousands of transactions per second in 400ms slots.
How Accounts Differ from Ethereum
In Ethereum, smart contracts are one address, one account (i.e. The Uniswap logic and its storage slots are all together). There is no pre-declaration of state access. The EVM processes things sequentially one at a time in Ethereum, whereas Solana has a strict separation between the state a program is touching and its code, which in turn allows for parallel execution. While Ethereum has optional access lists (EIP-2930), these are utilized for gas refunds by validators rather than transaction scheduling.
The tradeoff is on the development side. Because a Solana program cannot access accounts not included in the set provided in the inputted instruction to the program, developers need to assemble the full account set in their client for every instruction. If one account is misspecified, then the transaction will fail. This also explains a lot of indexing business like Helius, as processing large flat datasets is more difficult than querying individual contracts.
Why Accounts Matter
Take Phantom and open a dapp. The account model is all around us. Your SOL is one account, your tokens like USDC, JUP, and an NFT you own on Tensor are also their own accounts created the first time you received the token in your wallet. A Jupiter transaction names the pool accounts it will use for a path, allowing the validators to process the trade in parallel with thousands of other unrelated transfers in a slot. The account model is what allows Solana to be performant and explain many of the things that Ethereum users may find curious like why an account needs to be “created”, why it is not free and why account closure results in SOL being refunded.
Can anyone see the data in my accounts? On both chains, any account data is public and can be read by anyone. Solana restricts modification of data to the account’s owner program. There is no built-in privacy on the chains.
