T10 · Solana Programs

A Real-World Problem

You plan to move the deposit contract from T7 to Solana. You get stuck on the first line.

You want to write balanceOf[user] += amount, but a program has no storage. There are no state variables or mappings, and the documentation offers no location for “this program’s own data.”

Then comes a second surprise: when submitting a transaction, the caller must list in advance which accounts the transaction will read and write. The program does not search for data. The caller hands it over.

A third surprise follows: if the caller supplies the accounts, what happens if one is wrong? What if they hand you someone else’s account and you modify it?

All three point to the same fact: on Solana, the chain does not guarantee that “this data belongs to this person” for you; you must prove it yourself. This chapter explains where state lives and how to prove it is the right state.

Thought Experiment

Imagine a Solana program as a pure function with no hard drive.

It contains code but no private storage. On each call, someone hands it a stack of folders (accounts). The function reads and edits the folders, then ends. The folders do not belong to the function; it is merely authorized to change them.

Each folder has four labels:

address     Where this folder lives
owner       Which program may change its contents
data        The bytes inside
lamports    The money inside (also its “rent deposit”)

The key rule: only the owner program can modify a folder’s contents. Other programs may read them but cannot change them. This is the foundation of the model.

Consider two questions.

Question one: can callers hand over the wrong folder?

Yes, and easily. Your program should “increment this user’s counter,” but the caller supplies someone else’s counter. The function modifies it because all it sees is a stack of bytes.

Therefore, the program must check that “the folder you handed me really is the one I expect.” On the EVM, balanceOf[msg.sender] inherently selects the caller’s entry. On Solana, you must write that guarantee yourself.

Question two: if callers supply folders, how can a program create a folder “belonging only to itself”?

Derive the folder’s address from the program ID and a label you choose. Such an address has two properties: anyone can calculate it (so clients know which account to pass), but no one has its private key (so only the deriving program can act on its behalf).

Thus EVM’s balanceOf[user] becomes the account derived from “[label, user address]” on Solana. Each entry of the mapping becomes a separate, addressable account.

Your Decision

You want a simple counter: each user has their own count, and increment adds one. How do you ensure a user can increment only their own?

What Happens

Together, the four designs show how Solana’s account model determines both security and performance:

Make this conclusion second nature:

On the EVM, the chain ensures that “you only change your own entry.” On Solana, you write the check that makes that true.

This is not about one model being better. It is an exchange: Solana requires “which data will this transaction access?” to be declared in advance, enabling parallel execution. The price is moving validation responsibility from the platform to program authors.

That is why Solana and EVM security audits look so different. EVM reviews focus on reentrancy, overflow, and permissions. Solana reviews concentrate on missing account validations.

Build a Model

Five Account Fields

Account
 ├─ address      32-byte address
 ├─ owner        Program allowed to change data; ordinary wallets are owned by the system program
 ├─ data         Arbitrary bytes, interpreted by the program
 ├─ lamports     Balance; must also reach the rent-exemption threshold or the account is reclaimed
 └─ executable   Whether this is a program or data

Three account categories correspond to three roles:

Account Validation Checklist

This is the part of the chapter to print and post beside your monitor. For every supplied account, check:

1. Is the owner correct? Is this account owned by my program? If not, its data cannot be trusted.
2. Is the address correct? If it should be derived, repeat the derivation with the same labels and compare it to the supplied address.
3. Did it sign? Did an account whose authorization is needed actually sign this transaction? Checking its address without checking a signature is no check at all.
4. Is the type correct? Different structures can have the same byte length. You need a marker to distinguish them, or an attacker can pass type A as type B.
5. Are they distinct? When two different accounts are required, confirm their addresses differ. Many “transfer from yourself to yourself” bugs start here.
6. Is it writable? Did the caller mark an account that must change as writable?

Every omitted check corresponds to a real attack class. Points 3 and 1 have historically been exploited most often.

Derived Addresses and Cross-Program Calls

Derived addresses use a program ID and chosen labels to produce an address outside the elliptic curve. In other words, there is mathematically no corresponding private key. No human can sign for it, but the deriving program can “sign” on its behalf during a call.

This has two direct uses:

• Treat it as a mapping entry: [b"counter", user address] identifies that user’s counter.
• Treat it as a vault: assets sit in a derived account, and only program logic can move them out; there is no private key to steal.

Cross-program invocation lets one program call another during execution. It can include the labels of its own derived account so the callee knows “this program authorized it.” Token transfers, account creation, and calls to other protocols all use this path.

Turn Validation into Declarations

Writing all six checks by hand is long and easy to get wrong. A mainstream Rust framework turns them into declarative constraints on account structures:

use anchor_lang::prelude::*;

// Replace this with your real program ID from `anchor keys list` before deployment; do not copy it unchanged
declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");

#[program]
pub mod counter {
    use super::*;

    pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
        let counter = &mut ctx.accounts.counter;
        counter.authority = ctx.accounts.user.key();
        counter.count = 0;
        Ok(())
    }

    pub fn increment(ctx: Context<Increment>) -> Result<()> {
        let counter = &mut ctx.accounts.counter;
        // Production code should use checked_add and return an error on overflow, not wrap around
        counter.count = counter.count.checked_add(1).unwrap();
        Ok(())
    }
}

#[account]
pub struct Counter {
    pub authority: Pubkey,   // 32 bytes
    pub count: u64,          // 8 bytes
}

#[derive(Accounts)]
pub struct Initialize<'info> {
    // init        This program creates the account and becomes its owner
    // payer       Who pays the rent-exemption deposit
    // space       8-byte type marker + 32 + 8
    // seeds/bump  Address is derived from a fixed label and user; anyone can calculate it, only this program can write it
    #[account(
        init,
        payer = user,
        space = 8 + 32 + 8,
        seeds = [b"counter", user.key().as_ref()],
        bump
    )]
    pub counter: Account<'info, Counter>,

    #[account(mut)]
    pub user: Signer<'info>,          // The Signer type itself enforces a signature

    pub system_program: Program<'info, System>,
}

#[derive(Accounts)]
pub struct Increment<'info> {
    // seeds/bump  Derive the address again and compare it with the supplied one
    // has_one     The authority in account data must equal the authority account below
    #[account(
        mut,
        seeds = [b"counter", authority.key().as_ref()],
        bump,
        has_one = authority
    )]
    pub counter: Account<'info, Counter>,

    pub authority: Signer<'info>,
}

The framework handles five of the six checks here:

• The Account wrapper automatically checks that this program is the owner and the type marker matches (the extra eight bytes are that marker).
• seeds and bump automatically derive and compare the address.
• Signer automatically checks the signature.
• mut declares writability.
• has_one checks consistency between a field and an account.

The framework enforces the constraints you wrote, not the ones you forgot. If increment omits has_one and seeds, it will still compile, run, and pass every happy-path test, until someone uses it to change another person’s counter. The AI Lab will test this directly.

What It Is Called

Hands-on

solana --version
anchor --version
anchor init counter

anchor build
anchor keys list      # Prints this project's program ID

solana config set --url devnet
solana airdrop 2
anchor deploy

solana account <the account address you derived>

AI Lab

Step one:
For every instruction and every account in this Solana program, list what the account is
expected to be, which validations the code actually performs, and which are missing.
Use a table and do not suggest fixes yet.

Step two:
Choose the most serious suspected omission and describe a concrete attack:
which accounts the attacker supplies, which instructions they send and in what order,
and what they gain. Be specific about every account argument.

Step three:
Write a test in which the attack succeeds against the current code and fails after the fix.

Real-World Case

Change One Variable

Takeaway Questions

Chapter Check