Solana Account Model: Executable vs. Non-Executable Accounts

Hello and welcome to a new module, Solana Blockchain Fundamentals. We're now moving from the general-purpose power of Rust to the specific, and fascinating, architecture of the Solana blockchain.

In our previous module, we finished our tour of essential Rust concepts by mastering generics and trait bounds. You learned how to write flexible, reusable code that operates on abstract behaviors rather than concrete types—a skill that is central to writing efficient Solana programs.

Today, we will tackle the single most important concept in the entire Solana ecosystem. Your learning outcome is to describe the Solana account model and distinguish between executable (program) and non-executable (data) accounts. Grasping this is non-negotiable for any Solana developer. It is the foundation upon which everything else is built.

The Core Principle: Stateless Programs, Stateful Accounts

The first and most critical paradigm shift to make when learning Solana is this: programs are stateless.

Unlike smart contracts on some other blockchains which mix code and data storage, Solana enforces a strict separation. Think of it this way:

• Programs contain only logic (code).
• Accounts contain only data (state).

All data on Solana, from your SOL balance to the code of a DeFi protocol, is stored in "accounts." The network itself can be visualized as a giant key-value store, where the key is an account's address and the value is the structured data inside that account.

This model is analogous to how a modern operating system handles files. Some files are executables (.exe, binaries), and others are data files (.txt, .json, .dat). A single executable (like a text editor) can operate on many different data files. Solana programs work the same way.

Let's start with a short video that introduces this core philosophy.

This separation of code and state is a fundamental design choice in Solana, enabling a single deployed program to operate across countless different data accounts without needing to be redeployed.

The Structure of a Solana Account

So, what exactly is an account? At a low level, every account on Solana, regardless of its purpose, shares a common structure. This should feel familiar after our work with Rust structs.

Let's look at the fields that make up every account.

As you just read, every account is defined by the following fields:

Field	Type	Description
Address	32-byte array (Pubkey)	The unique "address" used to find the account. This is not explicitly in the structure but is the key in the global key-value store.
lamports	u64	The balance of the account in lamports (the smallest unit of SOL, where $10^9$ lamports = 1 SOL).
data	Vec<u8>	A byte array holding the account's data. This could be program code or program state.
owner	Pubkey	The public key of the program that is allowed to modify this account's data field. This is a critical security feature.
executable	bool	A boolean flag that tells the Solana runtime whether the data field contains executable code or just state.
rent_epoch	Epoch	A deprecated field related to an old rent-paying mechanism.

The two most important fields for our lesson today are owner and executable. The owner field dictates who can change the account, and the executable flag dictates what the account is.

Executable vs. Non-Executable Accounts

The executable boolean flag is the simple but powerful mechanism that divides all Solana accounts into two fundamental categories.

1. Executable Accounts (Program Accounts)

   • executable flag is set to true.
   • The data field contains compiled BPF (Berkeley Packet Filter) bytecode. This is the machine code that the Solana runtime can execute.
   • You can think of these accounts as the programs or smart contracts themselves.

2. Non-Executable Accounts (Data Accounts)

   • executable flag is set to false.
   • The data field can store any arbitrary data, up to a limit of 10MB.
   • This data is structured and managed by an executable program (its owner). Given your background in web development, you can think of the data field as being similar to a JSON object that has been serialized into a byte array for storage. The owning program knows how to deserialize and interpret these bytes.

Let's watch a clear explanation of this distinction.

To cement this, let's turn to a more comprehensive article that not only defines these types but also shows a practical code example.

The example you just saw is perfect proof: a Token Account, which stores data about a user's token balance, is a data account, and therefore has its executable flag set to false. The program that manages this account (the SPL Token Program) is an executable account owned by a Solana loader.

Test your understanding!

You are tasked with building a simple blog on Solana. Users should be able to create posts, each with a title and content.

1. Where would the logic for creating and editing a blog post be stored?
2. When a user creates a new post, where would its title and content be stored?
3. What would the executable flag be for each of these accounts?

Show answer

1. The logic (the code for functions like create_post and edit_post) would be stored in an executable Program Account.
2. Each blog post's data (title and content) would be stored in its own separate non-executable Data Account.
3. The Program Account would have executable: true. Each of the Data Accounts for the blog posts would have executable: false. The Program Account would be the owner of all the post Data Accounts.

Conclusion

Congratulations on completing your first lesson on Solana's core concepts! Understanding the account model is the biggest and most important first step. Everything we do from here on will build upon this foundation.

Here are the key takeaways from this lesson:

• Separation of Code and State: Solana programs are stateless. Their logic is stored in executable accounts, and the data they operate on is stored in separate, non-executable accounts.
• The Anatomy of an Account: All accounts share a common structure, including a SOL balance (lamports), an owner (the program that can write to it), and the crucial executable flag.
• Executable vs. Non-Executable: The executable flag is the simple boolean that distinguishes Program Accounts (code, true) from Data Accounts (state, false).
• Ownership: A program gains the ability to modify a data account by being designated as its owner. This is a cornerstone of Solana's security model.

In this lesson, we established that all data is stored in accounts. This raises a natural question: what's to stop the blockchain from filling up with data, and who pays for that storage? Our next lesson will answer this by exploring the concept of rent, the mechanism Solana uses to ensure the cost of on-chain storage is accounted for.