Introduction: Understanding the Solana Programming Model

When you interact with Solana, sending tokens, playing a game, or trading on a DEX, thousands of operations are happening simultaneously across the network. Solana handles stress tests that no other blockchain has ever experienced.  

This performance stems from how Solana separates code from information. Understanding Solana means grasping how several concepts work together: accounts, programs, ownership, transactions, PDAs, and their coordination.

This article builds a mental model using an analogy to see how the pieces fit together. Once you understand the big picture, the details will fall into place.

The Warehouse Analogy

Imagine Solana as a warehouse with millions of labeled boxes. Everything on Solana lives in these boxes: your token balance, game scores, even executable code. Each box is what Solana calls an account.

But a warehouse full of boxes isn't useful without rules about who can access what. That's where permissions come in.

Some boxes you control with your private key (your wallet). You sign to authorize changes. When you send tokens, you're telling the Token Program to move them; the program does the actual work.

Some boxes contain instruction manuals (programs).These manuals are pure logic, rules for how to process information. Crucially, the instruction manual (code) lives in its own box, separate from the data it processes. When you send instructions to a program, it reads from data boxes, performs calculations, and writes results back to those data boxes. The program never stores your balance or game state, it only holds the logic for manipulating that data.

Some boxes have no keys at all (PDAs). These are special addresses only a program can control. You can't access them directly. You must go through the program's rules. This is how a game can hold a reward vault without anyone being able to steal from it.

Here's why this matters:
One instruction manual (program) can be used by thousands of people at the same time, each working on their own boxes (accounts). As long as different transactions touch different boxes, no one has to wait. This is how Solana processes thousands of operations per second.

Ethereum processes transactions sequentially, one after another. Solana enables parallel execution by allowing transactions that access non-overlapping sets of accounts to run simultaneously. Transactions that touch the same writable account still run sequentially to prevent conflicts. This separation of code and data, combined with explicit account declarations in transactions, is the key to Solana's performance.

Quick Example

You send 100 USDC to a friend:

1. You sign: "move 100 from my box to friend's box"
2. Token Program reads both boxes
3. Token Program moves the tokens
4. Done

While your transaction processes, 5,000 others are doing the same with different token accounts. Same Token Program, different accounts = all run simultaneously.

What you'll learn 

Six concepts make Solana work:

• Accounts: What's in these boxes 
• Programs: How instruction manuals work and why they're stateless
• Ownership: Who can modify which boxes 
• Transactions: How you request changes 
• PDAs: How programs control boxes without keys 
• Cross-Program Invocations: How programs call each other

Each concept builds on the previous. Let's start with accounts.

Accounts: The Foundation of Solana

On Solana, everything is an account. Your wallet? An account. The Token Program? An account. Your game data? An account. Even the programs themselves? Accounts.

This is the single most important concept. Once it clicks, everything else makes sense.

An account is a storage location with a unique address. Think of it as one of those labeled boxes in our warehouse. Every validator maintains these boxes, keeping them synchronized through consensus.

Inside Every Account

Every account contains five essential pieces of information:

• Address: Where this information lives. Like a permanent box number. Once assigned, it never changes.
• Lamports: The amount of SOL this account holds. One SOL equals one billion lamports, similar to how dollars relate to cents but at a much smaller scale.
• Data: It is a byte array holding the actual content. For programs, this stores executable bytecode. For data accounts, it stores application state like balances, game scores, or user profiles. This can be empty or up to 10 megabytes.
• Owner: Which program has permission to modify this account. We'll explore this in the Ownership section.
• Executable: A flag marking whether this contains executable code. If true, it runs as a program. If false, it's stored information only.

Two Types of Accounts

1. Executable Accounts have the executable flag set to true. They contain compiled code the Solana runtime (the software that executes programs) can run. Examples: System Program, Token Program, custom DeFi protocols.
2. Data Accounts have the executable flag set to false. They store information only, no code. Examples: your wallet, token balances, game scores, NFT metadata.

Why Separate Code from State?

Here's the architectural choice that makes Solana fast: programs contain only code with no stored information. The whole state of the application lives in separate data accounts.

The Token Program is one executable account serving millions of tokens. How? Each token balance lives in its own data account. Person A transfers tokens using their accounts. Person B transfers tokens using their accounts. Same program, different data, both happening simultaneously.

When you submit a transaction, you declare upfront which accounts it will touch (which state changes will be made). Validators instantly see which transactions access different accounts and run them in parallel. Transactions touching the same writable accounts (same state) run sequentially, but everything else processes simultaneously.

This is parallel execution: separating stateless programs from stateful accounts so thousands of users can use the same program at the exact same time without conflicts.

Solana vs. Ethereum

Ethereum: A token contract bundles code and all user balances together. Creating a new token means deploying an entirely new contract.

• 1,000 tokens = 1,000 separate contracts
• Each redeploys transfer logic
• Code and state are inseparable

Solana: The Token Program is one executable account with only code. Each balance lives in a separate data account.

• 1,000 tokens = 1 Token Program + thousands of data accounts
• One codebase serves all tokens
• Code and state are separate

One Token Program serves every SPL token on Solana, millions of tokens, and one set of rules. It's like installing Excel once for many spreadsheets versus installing Excel separately for each spreadsheet.

This separation enables parallelism. Thousands of people use the Token Program simultaneously, each with their own data accounts, without conflicts. Validators process these in parallel because they know exactly which accounts each transaction touches and avoid these conflicts.

Programs: Executable Code that processes Accounts

We've covered accounts as storage locations. But how does information in these accounts actually change? That's where programs come in.

Programs are accounts with a special flag: executable = true. Technically, the code is still data stored in the account. The executable flag simply tells the Solana runtime whether to load that data as executable code.

When executable is true, the account gets special permissions: it can return arbitrary data as the result of instructions and can "sign" for PDAs (special accounts we'll cover later). When executable is false, the account can only return data it already contains and cannot sign for PDAs, though it can be used as a seed to generate them.

Programs are Stateless

Programs store no information themselves except their code (functional logic). Between different executions, programs remember nothing. When a program finishes running, it resets completely. The data field holds code, not application state. If a program needs to remember something, it must write to a separate data account.

This is the technical reason for the separation we discussed earlier: programs process, accounts store. This division enables parallel execution.

How Programs Are Executed

When a program runs, it is receiving 3 things:

• Program ID: Which program is being executed
• Accounts: List of accounts to work with
• Instruction data: Parameters for this operation

The program reads from the provided accounts, processes according to its code, writes results back to accounts, then resets.

Three Types of Programs

Programs fall into three categories based on who creates and maintains them:

Native Programs are built into Solana's core and update only with network upgrades. These foundational programs include:

• System Program: Creates accounts and transfers SOL
• Token Program: Manages all SPL tokens
• Program Loaders: Deploys new programs to the network

Custom Programs are what developers build for specific applications: DeFi protocols, NFT marketplaces, games, and DAOs. You write the code, compile it, and deploy it as an executable account.

SPL Programs are battle-tested, reusable programs for common functions: advanced token standards, staking pools, and governance systems. 

The System Program

The System Program deserves special attention because it creates every account on Solana.

Your wallet is a data account owned by the System Program. When you send SOL, you're asking the System Program to do it on your behalf. You prove authorization by signing with your private key.

Every other program depends on the System Program to create accounts first. Creating game data means your program calls System Program's create_account instruction. Deploying a program means System Program creates the executable account first, then you must explicitly tell System Program to transfer ownership to your program. This doesn't happen automatically.

Ownership: Who Can Modify What

Every account is owned by a program. Only the owner program can modify that account's data or deduct its lamports.

3 simple rules govern this:

• Only the owner can modify an account's data
• Only the owner can deduct lamports
• Anyone can add lamports

Anyone can read any account (transparency), but only the owner can write (security).

When you send SOL, your wallet is owned by the System Program. You can't directly change your balance; instead, you sign a transaction authorizing the System Program to modify your wallet on your behalf.

When you play a game, the game program creates an account for your score owned by itself, not you. Why? To enforce rules. If you owned it, you could change your score arbitrarily. The program owns it to ensure changes follow game logic.

Ownership Transfer is Explicit

Accounts can change owners, but you must explicitly instruct the transfer. System Program creates an account and initially owns it. If you want your program to own it, you must tell the System Program to transfer ownership. This doesn't happen automatically, a common mistake for early developers.

This ownership model enables both security and speed. Programs can only modify what they own. Users authorize changes by signing. And because ownership is explicit, validators know exactly which transactions can run in parallel without conflicts.

Now we understand accounts store information, programs process it, and ownership controls permissions. But how do these pieces actually work together? Through transactions.

Transactions: How Changes Happen

A transaction is how you tell the network: "Execute these programs on these accounts with my authorization."

Think of it as a list of instructions for programs to execute according to their rules. You bundle instructions together, sign to prove authorization, and send them to the network. Either all instructions succeed, or all fail (atomicity).

When you send SOL, you create an instruction calling the System Program's transfer, sign it with your private key, and the System Program executes the transfer. Both wallets are updated. Done.

The key insight: you must declare upfront which accounts the transaction touches. This lets validators verify permissions and identify which transactions can run in parallel. Different accounts mean simultaneous (parallel) execution. The same accounts mean sequential execution.

Transactions coordinate everything. Programs don't run on their own. Every state change happens through transactions, enforcing ownership rules and enabling parallel processing.

Now let's look at how programs control accounts without private keys: PDAs.

Program Derived Addresses: Programs Controlling Accounts

Programs are stateless and can't have private keys. But programs need to control accounts, hold deposits, manage treasuries, and lock escrow funds. How? PDAs solve this.

Program Derived Addresses (PDAs) are addresses generated from a program's ID and seeds you choose. They're deterministic; the same inputs always produce the same address.

The key property: PDAs have no corresponding private key. Only the program that derived the PDA can "sign" for it using invoke_signed.

How Programs Use PDAs

Programs provide the seeds that generated the PDA. The runtime verifies: "Does this program plus these seeds equal this PDA address? Yes. Allow the operation."

Example: Your DeFi program transfers SOL from a PDA vault. It calls invoke_signed with seeds ["vault", user_pubkey]. Runtime verifies the match and allows the transfer.

Why PDAs Matter

PDAs allow programs to change data without letting users have direct control. The data can only change if the program's rules are followed.

When you deposit into an escrow, the program creates a PDA to hold the funds. You can't access them directly, no private key exists. Only the escrow program can release funds when conditions are met. You must go through the program's rules.

This is how programs enforce rules users can't bypass. It's the foundation of secure, trustless applications on Solana.

Let's look at the final core concept: how programs call other programs.

Cross-Program Invocations

Programs often need other programs. Your game wants to reward users some tokens, but it doesn't own token accounts: Token Program does.

Solution: Your program calls Token Program through a Cross-Program Invocation (CPI). This is composability, programs building on other programs.

Two Types of Calls

Regular invoke is used when calling another program to execute logic.
Special invoke_signed is used when your program needs to "sign" on behalf of a PDA it controls. Your program provides the seeds. The runtime verifies the program controls the PDA, then allows the operation.

Example: User deposits tokens. Your program calls the Token Program to transfer from the user's account to the PDA vault. User withdraws. Your program calls the Token Program using invoke_signed with PDA seeds. Transfer executes.

CPI enables composability. DeFi protocols call the Token Program. NFT marketplaces call multiple programs. Every complex application is a program calling programs.

Conclusion

You now understand Solana's programming model from the ground up. This architecture is why Solana handles thousands of transactions per second while maintaining security and decentralization. You're ready to explore deeper: build programs, interact with protocols, or understand how applications work under the hood.

‍