Solana Account Model

On Solana, all data is contained in what we call "accounts". You can think of data on Solana as a public database with a single "Accounts" table, where each entry in this table is an individual account with the same base Account type.

Accounts

Key Points

Accounts can store up to 10MiB of data, which contain either executable program code or program state.
Accounts require a rent deposit in lamports (SOL) that is proportional to the amount of data stored, which is fully refundable when the account is closed.
Every account has a program owner. Only the program that owns an account can modify its data or deduct its lamport balance. However, anyone can increase the balance.
Sysvar accounts are special accounts that store network cluster state.
Program accounts store the executable code of smart contracts.
Data accounts are created by programs to store and manage program state.

Account

Every account on Solana is identifiable by a unique 32 byte address, which is generally displayed as a base58 encoded string (e.g 14grJpemFaf88c8tiVb77W7TYg2W3ir6pfkKz3YjhhZ5).

The relationship between the account and its address can be thought of as a key-value pair, where the address serves as the key to locate the corresponding on-chain data of the account.

Account Address

Most Solana accounts use an Ed25519 public key as their address.

While public keys are commonly used as account addresses, Solana also supports a feature called Program Derived Addresses (PDAs). PDAs are special addresses that are deterministically derived from a program ID and optional inputs (seeds). The details are covered on the Program Derived Address page.

Account Type

Accounts have a max size of 10MiB and every account on Solana has the same base Account type.

Account Type

Every Account on Solana has the following fields:

data: A byte array that stores arbitrary data for an account. For non-executable accounts, this generally stores state that is meant to be read-only. For program accounts (smart contracts), this contains the executable program code. The data field is commonly referred to as "account data".
executable: This boolean flag used to indicate if an account was a program.
lamports: The account's balance in lamports, the smallest unit of SOL (1 SOL = 1 billion lamports).
owner: The program ID (public key) of the program that owns this account. Only the owner program can modify the account's data or deduct its lamports balance.
rent_epoch: A legacy field from when Solana had a mechanism that periodically deducted lamports from accounts. While this field still exists in the Account type, it is no longer used since rent collection was deprecated.

Base Account Type

pub struct Account {
    /// lamports in the account
    pub lamports: u64,
    /// data held in this account
    #[cfg_attr(feature = "serde", serde(with = "serde_bytes"))]
    pub data: Vec<u8>,
    /// the program that owns this account. If executable, the program that loads this account.
    pub owner: Pubkey,
    /// this account's data contains a loaded program (and is now read-only)
    pub executable: bool,
    /// the epoch at which this account will next owe rent
    pub rent_epoch: Epoch,
}

Rent

To store data on-chain, accounts must also maintain a minimum lamport (SOL) balance that is proportional to amount of data stored on the account (in bytes). This minimum balance is called "rent", although it functions more like a deposit because the full amount can be recovered when an account is closed. You can find the calculation here using these constants.

The term "rent" is due to a deprecated mechanism that regularly deducted lamports from accounts that fell below the rent threshold. This mechanism is no longer active.

Program Owner

On Solana, "smart contracts" are referred to as programs. Program ownership is a key aspect of the Solana Account Model. Every account has a designated program as its owner. Only the owner program can:

Modify the account's data field
Deduct lamports from the account's balance

System Program

By default, all new accounts are owned by the System Program. The System Program performs several key tasks:

New Account Creation: Only the System Program can create new accounts.
Space Allocation: Sets the byte capacity for the data field of each account.
Transfer / Assign Program Ownership: Once the System Program creates an account, it can reassign the designated program owner to a different program account. This is how custom programs take ownership of new accounts created by the System Program.

All "wallet" accounts on Solana are simply accounts owned by the System Program. The lamport balance stored in these accounts represents the amount of SOL owned by the wallet. Only accounts owned by the System Program can be used as transaction fee payers.

System Account

Sysvar Accounts

Sysvar accounts are special accounts located at predefined addresses that provide access to cluster state data. These accounts are dynamically updated with data about the network cluster. You can find the full list of Sysvar Accounts here.

Program Account

Except for loader-v3 all loaders store the executable code of the programs they manage in a so called program account: Program Account

For simplicity, you can think of the program account as the program itself. When invoking a program's instructions, you specify the program account's address (commonly referred to as the "Program ID").

Buffer Account

Loader-v3 has a special account type for temporarily staging the upload of a program during deployment or redeployment / upgrades. In loader-v4 there are still buffers, however they are just normal program accounts.

Programdata Account

Loader-v3 works differently from all other loaders as it has one indirection for each program. The program account only contains the address of the programdata account which then in turn holds the actual executable code: Programdata Account

These programdata accounts are not to be confused with the data accounts of programs (see below).

Data Account

On Solana the executable code of a program is stored in a different account than the state of the program is. This is comparable to how operating systems typically have separate files for programs themselves and their data.

To maintain state, programs define instructions to create separate accounts that are owned by the program. Each of these accounts has its own unique address and can store any arbitrary data defined by the program.

Data Account

Note that only the System Program can create new accounts. Once the System Program creates an account, it can then transfer / assign ownership of the new account to another program.

In other words, creating a data account for a custom program requires two steps:

Invoke the System Program to create an account, which then transfers ownership to the custom program
Invoke the custom program, which now owns the account, to then initialize the account data as defined by the program's instruction

This account creation process is often abstracted as a single step, but it's helpful to understand the underlying process.

Spis treści