Program Development Prerequisites

Solana programs are built around three key components: accounts, instructions, and transactions.

Accounts

An account on Solana is essentially a storage unit holding data. Every one is associated with a unique 32-byte address that identifies it and an “Owner” which specifies the Solana program that has exclusive authority to modify or interpret the account's data.

For example, Solana wallets are a type of account owned by the Solana system program. The System Program is a native program on Solana responsible for creating accounts, allocating data to accounts, and assigning ownership of accounts to connected programs.

Your wallet address is the unique identifier for your wallet account. In addition to having an owner and an identifier, each account also holds:

• Lamports, which are fractional units of SOL tokens. Lamports are used to pay transaction fees and to fund the rent required for storage on-chain.
• Data Storage, which is arbitrary binary data managed explicitly by the account's owner program.
• An Executable Flag, indicating whether the account stores executable code, such as a smart contract program.

Here’s the structure of a Solana account in code:

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 (legacy field, no longer in use)
    pub rent_epoch: Epoch,
}

Types of accounts

Based on their function, accounts on Solana can be categorized into executable and non-executable accounts. As the name suggests, executable accounts store program code. The only type of accounts that fall under this category are called Program Accounts. An example of a Program Account is the Metaplex NFT Program, which executes logic related to NFT minting, transfers, and metadata management.

Non-executable accounts, by contrast, hold persistent data. They may represent token balances, order books, NFT metadata, anything the owner program needs to remember between calls. Accounts that fall into this category include:

• System Accounts, which store SOL balances and are used in fundamental operations like transfers and account creation, which the System Program executes. An example of a system account is your user wallet.
• Data Accounts, which store arbitrary data managed by a program (e.g., user state, NFT metadata). An example of a data account is an NFT metadata account that stores the details of a specific NFT, managed by the Metaplex program.

There are other types of non-executable accounts, and you will encounter them as you progress in the course.

As we mentioned before, only the account owner can change their data. Using user wallets as an example, only the system program can modify their data (increase or reduce the balance).

When you send or receive SOL using a wallet, a transaction that invokes the system program is executed under the hood to update your balance. In the next section, you will explore the concepts of transactions and instructions.

Transactions and Instructions

A transaction is a signed collection of one or more instructions. It describes what should happen on-chain and which accounts are involved.

To authorize a transaction, you must sign it with the private key of the account you’re using. This proves you control the account and grants permission to modify it or spend from it.

Each instruction inside a transaction is a call to a Solana program. It specifies:

• The program ID to invoke (e.g., System Program, Token Program)
• The accounts involved
• A data payload, usually a serialized structure that encodes what action the program should perform

You can think of an instruction as, “Tell this program to do X, using these accounts, with this data.”

Example: Transferring SOL

When you transfer SOL from your wallet to another, here’s what actually happens:

1. A System Program instruction is created that says “transfer X lamports from Account A to Account B”.
2. This instruction includes:
   • Your wallet (Account A)
   • The recipient's wallet (Account B)
   • The amount to transfer (in lamports)
3. The transaction is signed with your private key and submitted to the network.
4. The Solana runtime validates the signature and executes the instruction by calling the System Program with the provided data.

Multiple Instructions, One Transaction

Transactions can include multiple instructions. This is powerful because you can group several actions together atomically. Either all instructions succeed, or none do.

For example, in a single transaction, you could:

• Create a new account
• Fund it with SOL
• Initialize it with some program-specific data

You’ll use this pattern frequently when working with Solana programs.

Rent

Solana uses a rent model to manage storage costs and discourage unused data from bloating the network.

Every account must hold a minimum number of lamports to remain rent-exempt. If an account’s balance drops below this threshold, the network may reclaim the account’s storage over time.

To avoid this, you typically prepay rent by funding the account with enough lamports to make it rent-exempt. This is a one-time cost, and the account stays alive permanently — unless you explicitly close it and reclaim the SOL.

You’ll see rent-exemption checks often when creating new accounts:

let rent_lamports = rent.minimum_balance(account_size);

This calculates the number of lamports required to make the account rent-exempt, based on its size.

You have covered all the concepts you need to know to build your first Solana program. In the next module, you will build a counter program.