Rust Ownership for Solana Developers (Simplified)

Rust ownership is the feature most Solana learners struggle with first. Unlike JavaScript or Python, Rust enforces memory safety at compile time through a strict ownership model. Once you understand three rules, most compiler errors become obvious. This guide walks through each rule with concrete Solana examples so the concepts move from abstract to practical.

If you are new to Rust on Solana, start with Rust data types for Solana first, then return here for the ownership model that governs how those types behave in memory.

Traditional languages solve memory management in one of two ways. Garbage collected languages like Python and JavaScript track references at runtime and pause the program periodically to reclaim unused memory. Systems languages like C give you manual malloc and free, which is fast but error prone.

Rust takes a third path. The compiler tracks ownership statically and inserts deallocation code automatically at the exact point where a value goes out of scope. There are no runtime pauses and no manual free calls.

The following code will not compile. After the assignment on line 2, name no longer owns the String. Attempting to print it on the commented line produces a compile error.

fn main() {
    let name = String::from("Alice");
    let name2 = name;  // ownership MOVES to name2
    // println!("{}", name);  // COMPILE ERROR: name was moved
    println!("{}", name2);    // OK
}

If you need both variables to remain valid, use .clone() to create a deep copy. This allocates new memory for the second value so both are independent.

let name = String::from("Alice");
let name2 = name.clone(); // deep copy — both are valid
println!("{} and {}", name, name2);

An immutable borrow passes a reference to a function. The function can read the data, but the original owner keeps ownership and the value remains valid after the function returns.

fn print_balance(balance: &u64) {
    println!("Balance: {}", balance);
    // balance is borrowed — original owner keeps it
}

fn main() {
    let balance: u64 = 1_000_000;
    print_balance(&balance);
    println!("Still accessible: {}", balance); // OK
}

A mutable borrow passes a reference that allows the function to modify the value. You must mark both the variable and the call site with mut.

fn add_lamports(balance: &mut u64, amount: u64) {
    *balance += amount;
}

fn main() {
    let mut balance: u64 = 1_000_000;
    add_lamports(&mut balance, 5_000);
    println!("New balance: {}", balance); // 1_005_000
}

Two rules govern borrows. First, you can have any number of immutable borrows OR exactly one mutable borrow at a time — never both simultaneously. Second, borrows must not outlive the owner.

Solana's AccountInfo struct stores account data as a RefCell<&mut [u8]>. RefCell moves the borrow check from compile time to runtime, allowing the Solana runtime to pass the same account to multiple instructions safely. The borrow rules still apply — they are just enforced at runtime with a panic instead of a compile error.

When using the Anchor framework, most account access happens through typed wrappers that handle the borrow for you. But in raw Solana programs, you interact with RefCell directly.

use solana_program::account_info::AccountInfo;

pub fn process(account: &AccountInfo) -> ProgramResult {
    // Read account data — immutable borrow
    let data = account.data.borrow();
    let first_byte = data[0];
    drop(data); // explicitly release the borrow

    // Write account data — mutable borrow
    let mut data = account.data.borrow_mut();
    data[0] = first_byte + 1;
    Ok(())
}

Once you are comfortable with ownership and borrowing, the next step is understanding Rust structs for Solana, which show how these rules apply to the account state types you will define in every program.