The One Idea That Changes Everything

When I started learning Solana after years of Web2 development, one sentence kept appearing everywhere: "Everything is an account." I nodded along without really understanding it. It sounded like a slogan.

It isn't. This is the most important architectural decision Solana made, and once you understand it, everything else about how Solana works starts to make sense.

This post explains Solana's account model from scratch, written for developers who know databases, filesystems, and APIs, but are new to how Solana organizes on-chain state.

What Is an Account?

In Solana, an account is a record stored on the blockchain. Think of it like a row in a global database, except this database is replicated across thousands of validators worldwide, nobody owns it, and every write to it costs a small fee.

Every account has the same structure, regardless of what it's used for:

• Lamports: the account's SOL balance, denominated in the smallest unit (1 SOL = 1,000,000,000 lamports)
• owner the program that has the authority to modify this account's data
• data: an arbitrary byte array; this is where state is stored
• executable: a boolean flag; if true, this account contains a program

That's it. Four fields. Wallets, programs, token balances, NFT metadata, swap pool state they're all just accounts with these four fields filled in differently.

The Four Fields, Explained

lamports

Every account must hold enough SOL to stay "rent-exempt" (more on that below). The lamports field tracks this balance. For a wallet account, this is your spendable SOL. For a program account, it's the deposit that keeps the account alive.

When you send SOL to someone, you're reducing the lamports in your account and increasing the lamports in theirs. Simple. But this same mechanism is also how you pay for storing data on-chain the more data an account holds, the more lamports it needs to stay rent-exempt.

owner

This is the field Web2 developers find most surprising. Every account on Solana is "owned" by a program. The owner field contains the address of the program that has permission to modify that account's data field.

Your wallet account? Owned by the System Program. Your USDC token balance? Stored in a token account owned by the Token Program. A DEX's liquidity pool? An account owned by the DEX's program.

Here's the key rule: only the owner program can modify an account's data. Anyone can read any account. But writes are gated by ownership. This is Solana's access control model, and it's enforced at the runtime level — no exceptions.

data

This is the payload. For wallet accounts, the data is empty; wallets only need to track a SOL balance, which lives in lamports. For program-owned accounts, data contains whatever state the program needs to store, serialized as bytes.

A token account's data contains: the mint it belongs to, the owner's wallet address, and the token balance. An NFT's metadata account contains: the name, symbol, URI, and royalty information. A DEX pool's account contains: the reserve amounts, fee configuration, and liquidity parameters.

The program defines the structure. The account stores the bytes. Solana's runtime doesn't care what's in the data field that's between the program and whoever wrote it.

executable

If this boolean is true, the account's data field contains compiled program bytecode rather than state data. The Solana runtime will execute this bytecode when the program is invoked.

This is the elegance of the account model: programs and data use the exact same storage primitive. A program is just an account where executable = true. There's no separate "smart contract" type, just accounts.

Why Programs and Data Live in Separate Accounts

Coming from Ethereum, this is the biggest conceptual shift. On Ethereum, a smart contract bundles its logic and its state together. The contract code and the contract's storage live at the same address.

Solana separates them completely. A program account contains only executable bytecode it holds no mutable state. All state is stored in separate data accounts that the program owns.

Why? Two reasons that matter a lot in practice:

Programs are immutable by default. Because a program account only contains code and no state, upgrading a program doesn't affect the data accounts it manages. You can deploy a new version of a program without migrating user data. The data accounts keep pointing to the program's address, and the new code reads and writes them in the new way.

Parallelism. Solana can execute transactions in parallel when they don't touch the same accounts. By separating program logic from program state, Solana's scheduler can identify which transactions are truly independent and run them simultaneously. This is a significant part of how Solana achieves high throughput.

How Ownership Controls Who Can Change Data

Imagine a user's token account, let's call it Account A. It's owned by the Token Program. It stores the token balance.

If you submit a transaction that tries to directly modify Account A's data without going through the Token Program, the Solana runtime will reject it. Full stop. The runtime checks the owner field and enforces that only the Token Program can write to this account.

So how does a user move their tokens? They submit a transaction that calls the Token Program with the right instruction. The Token Program verifies the user's signature, checks that they're the authority for Account A, and then as the owner modifies Account A's data to reflect the new balance.

The user doesn't write to their account directly. They ask the program that owns their account to write on their behalf, after proving they have the right to make that request.

This is a fundamentally different mental model from Web2, where your server code writes directly to your database. On Solana, the "database row" specifies which "server" is allowed to modify it, and that rule is enforced by the network itself.

What Is Rent Exemption?

Storing data on a blockchain costs resources validators need to keep every account in memory to process transactions quickly. Solana handles this with a concept called rent.

Originally, accounts paid a small ongoing fee (rent) to stay alive. Accounts that ran out of SOL would be deleted. This created complexity you'd have to top up accounts periodically or lose your data.

The modern approach is rent exemption: if an account holds enough SOL (roughly 0.002 SOL per kilobyte of data, though the exact amount varies), it's considered rent-exempt and will live forever. It never pays ongoing rent.

This is why creating a new token account costs a small amount of SOL you're depositing the rent-exempt minimum upfront. When you close an account, that SOL is returned to you.

As a developer, the practical implication is that when you create any new on-chain account, you need to fund it with enough SOL to be rent-exempt. Your users will pay this deposit when they interact with your program for the first time.

Putting It Together

Here's the mental model that clicked for me:

Solana is a global key-value store. Every account is a value (with four fields) stored at a key (its address). Programs are values where executable = true. Data are values where a program's address is set as the owner.

When you interact with Solana, you're either

1. Reading values from this store (free, anyone can do it)
2. Writing values by submitting transactions (costs fees, gated by ownership rules)

Every concept in Solana wallets, tokens, NFTs, DeFi protocols is built on top of this single primitive. Once you have this model in your head, the rest of Solana starts to feel like a natural consequence of a few simple rules applied consistently.

That's what "everything is an account" actually means.