Most blockchains were built to run transactions one after another. Solana was built to run as many of them at the same time as possible. This single decision shapes everything else in the programming model. Where state lives, who owns it, what a transaction has to declare, how the runtime decides what runs together, what you pay to store a byte on chain. None of these choices are arbitrary. Each one falls out of the parallel-execution goal at the top.

A serial chain has a simpler life. One transaction at a time, one global state to read from and write to, a single thread of execution. The programmer writing code for that kind of chain can treat the state as a database that their contract reads and modifies. The runtime figures out which storage slots got touched. The developer doesn't have to think about it because there is only one thread.

Parallel execution doesn't work like that. If two transactions might run at the same time on different threads, the runtime has to know in advance which pieces of state each one will read and write. Otherwise it cannot schedule them safely, since a race condition between two threads writing the same byte produces inconsistent state and breaks consensus. The choice for parallelism therefore forces a chain of further choices, each one a constraint the developer has to live with.

There are four of them.

The first is statelessness. Programs on Solana do not hold storage of their own. A program is pure code. When it needs to read or write data, that data lives in a separate account that gets passed to it on every call. The program never knows what state exists on the chain except the state the current transaction handed it. This is unlike the standard smart-contract model where each contract has its own storage attached to its address.

The second is explicit account declaration. Every transaction lists every account it intends to touch, marked as read-only or writable. This list is the access plan. The runtime reads it before execution begins and uses it to decide which transactions are safe to run in parallel and which conflict. There is no way to discover what state a transaction touches by running it. The list has to be correct before the transaction is even submitted, which means the client building the transaction needs to know in advance what the program will need.

The third is per-account ownership. Every account on Solana is owned by exactly one program. Only that program is allowed to modify the account's data. The runtime enforces this before letting the program touch the bytes. Reads are open to anyone, but writes go through the owner program. This is the security model. A token balance held in a token account cannot be modified by an attacker's program, because the attacker's program is not the owner of that account.

The fourth is rent. Storing data on the chain takes space that every validator has to hold in memory, and the network charges for that. Solana asks each account to deposit enough lamports up front to cover its storage permanently, in proportion to the bytes it occupies. The deposit is refundable when the account is closed. In practice every account is created with this rent-exempt minimum, and rent stops being something the developer thinks about beyond the moment of creation.

These four are not separate ideas. They are different views of the same decision.

The programming model that comes out of these four constraints feels different to anyone who has written code for a serial chain. Three differences are worth naming.

You think about state ownership constantly during the early lessons and then stop thinking about it once the model is internalized. Every byte you read or write belongs to some account, and every account belongs to some program. The question "who can write this" is never ambiguous on Solana, because the runtime answers it for every transaction.

You build the access plan on the client side, before sending the transaction. The client has to know which accounts the program will read and which it will write. Most of the work in a Solana client library is figuring this out, because the program author has to either document the access pattern or expose it through a machine-readable interface called an IDL.

You stop worrying about contract storage growing unboundedly. Every account is sized at creation. Growing an account takes a deliberate call that pays for the new bytes. Programs cannot quietly accumulate state because every byte of state has an account behind it and someone paid for that account.

The cost of all this is that the programming model has more pieces. A Solana program is harder to write than the equivalent on a serial chain, especially the first time. You have to think about accounts, ownership, declaration, rent. You have to write tests that exercise the runtime's checks rather than relying on the runtime to discover them at execution time.

What you get is a chain where a token swap on one decentralized exchange does not have to wait for an unrelated NFT mint, and where the network can process thousands of independent transactions per second without one of them blocking the rest. The applications people built on Solana, payments at credit-card speeds, on-chain order books, decentralized exchanges with sub-cent fees, exist because the runtime can run their transactions in parallel. Take that away and the chain becomes another serial chain, slower than it should be.