Solana Account Model: Deep Dive & Ethereum Contrast

The Code-Data Separation Model

In Ethereum, an account is a single entity that bundles together its balance, nonce, code, and storage. A smart contract's logic and its state live together within the same contract account.

Solana takes a radically different approach. It separates code from data. Think of it like a traditional computer operating system: you have executable files (programs) and data files (documents, images, etc.). The programs operate on the data files but don't store the data themselves.

On Solana:

• Program Accounts store immutable, executable code (compiled from Rust, in our case). They are stateless.
• Data Accounts store all the mutable data that programs interact with, from a user's token balance to the state of a complex DeFi protocol.

This means that a single, deployed program can interact with a virtually unlimited number of data accounts. This design is key to Solana's performance and scalability, but it also creates a new set of challenges and potential security flaws that do not exist in Ethereum.

To get a better sense of this fundamental concept, please read the introductory sections of the following article from Helius.

The Anatomy of a Solana Account

Now that you have a high-level view, let's dissect the structure of a Solana account. Since you're comfortable with Rust, the best way to visualize this is as a struct. Every account on Solana, whether it holds a program or data, shares a common metadata structure.

The fields in this struct are the building blocks of all on-chain state and logic. Let's explore what each one means.

As you've just read, the core fields are:

• lamports: The number of native tokens (SOL) owned by the account, in the smallest denomination (1 SOL = 1,000,000,000 lamports). This is analogous to Ethereum's balance.
• data: A raw byte array (Vec<u8>) that stores the actual state. For a program account, this holds the executable BPF bytecode. For a data account, this is where your program will read from and write to. The interpretation of these bytes is entirely up to the program that owns the account.
• owner: The address of the program that is allowed to modify this account's data and subtract lamports. This is a runtime-enforced rule and is the single most important field for security. An incorrect owner can lead to a complete loss of control over an account's state. By default, new accounts are owned by the System Program.
• executable: A boolean flag. If true, the account is a program and its data is treated as BPF bytecode. If false, it's a data account.
• rent_epoch: A field related to Solana's storage cost mechanism, known as rent.

The Rent Lifecycle

Unlike Ethereum, where you pay a one-time gas fee to store data forever, Solana requires accounts to pay a recurring "rent" to cover the cost of storage. This prevents the blockchain's state from bloating indefinitely with unused accounts.

However, the modern implementation of this is simple: any new account must deposit enough SOL to be rent-exempt, which covers the cost of storage for approximately two years. This deposit is locked in the account's lamports balance. If the account is later closed, this SOL deposit is refunded to the user.

Let's watch a short video that explains this concept clearly.

The key takeaways on rent are:

1. Storage is not free on Solana; it requires a SOL deposit.
2. All new accounts must be funded with enough SOL to be rent-exempt.
3. This rent deposit can be reclaimed by closing the account and reducing its lamports balance to zero.

Owner, Authority, and Signer: The Pillars of Solana Security

Understanding the distinction between owner, authority, and signer is non-negotiable for a security researcher. Confusion between these terms is a primary source of critical vulnerabilities.

• Owner: As we've covered, this is a field in the account's metadata. It's a program ID. The Solana runtime guarantees that only this program can modify the account's data. This is a powerful, low-level security guarantee.
• Signer: This refers to an account whose private key was used to sign a transaction. When a program receives an account, it can check a boolean flag, is_signer, to see if that account's holder authorized the transaction. However, the program must perform this check. If it doesn't, anyone can pass in the account, and the program will proceed as if it were authorized. This is a classic bug class: missing signer check.
• Authority: This is a design pattern, not a runtime concept. It's typically a public key stored inside an account's data field. A program's logic will define that for a specific action (e.g., withdrawing funds), the transaction must be signed by the authority address stored in its state. For example, a token mint account has a mint_authority field in its data. Only the mint_authority can sign a transaction to mint new tokens.

The following video is one of the most important resources you'll encounter for understanding these core security primitives. The creator, Solandy, does an excellent job of demonstrating these concepts with code.

To solidify this, let's recap with an example of a user's token account:

• Owner: The SPL Token Program. Only this program can change the token balance in the account's data.
• Signer: The user's wallet. To transfer tokens, the user must sign the transaction, proving they hold the private key.
• Authority: The user's public key. This is stored in the token account's data. The SPL Token Program checks that the signer of the transaction matches the authority stored in the account data before allowing a transfer.

Conclusion

In this foundational lesson, we've unpacked the Solana account model, which is fundamentally different from Ethereum's. You learned about the crucial separation of code and data, the structure of an account, and the rent mechanism that governs its lifecycle.

Most importantly, you now understand the distinct and critical roles of owner, signer, and authority.

• The owner is the program with write-access, enforced by the runtime.
• The signer is a proof of identity, which a program must manually check.
• The authority is a concept in a program's logic that designates who is allowed to perform certain actions.

Mastering these distinctions is the first major step on your path as a security researcher. Nearly every major Solana exploit involves a misunderstanding or misapplication of one of these three concepts.

In our next lesson, we will move from theory to practice. You will set up your local development environment and use the Solana Command-Line Interface (CLI) to query the blockchain and inspect the fields of live accounts, seeing these concepts in action.