Capstok — learn by doing

Why this matters

Solana's defining design choice: every piece of state is an account. A wallet is an account; a token's metadata is an account; a program is an account whose executable: true. Unlike Ethereum where contracts own storage slots, on Solana the program is stateless code and the data it operates on is passed in as accounts. Internalizing this is the cognitive shift required for everything that follows.

Demo

Inspect a token mint account vs a token account.

Try it yourself

Use solana account <pubkey> against a known USDC token account and observe the lamports, data length, and owner program.
Compute the rent-exempt minimum for an account of size 1000 bytes — formula is (128 + size_bytes) * lamports_per_byte_year * 2.
Identify three different programs that own different account types: System Program (wallets), Token Program (tokens), BPF Loader (programs).

Prompt your AI

Use these three in order. Each builds on the one before.

1. Basics & terminology

In one paragraph, explain Solana's account model and how it differs from Ethereum's contract-storage model.

2. Why it works (the mechanism)

Walk me through what `owner` means on an account — who can write to it and how.

3. Advanced — application & what's next

Given a contract that needs to store a million records, explain how Solana's account-per-record model compares (cost, parallelism, complexity) to Ethereum's single-mapping model.

References

// Every account on Solana has this shape:
pub struct Account {
    pub lamports: u64,            // SOL balance (1 SOL = 1e9 lamports)
    pub data: Vec<u8>,            // arbitrary binary data
    pub owner: Pubkey,            // the program that may modify this account
    pub executable: bool,         // true for programs, false for data
    pub rent_epoch: Epoch,        // legacy; mostly unused post-rent-exemption
}

// Example: a USDC SPL Token mint account
//   lamports:   ~1.46e6 (rent-exempt minimum for size=82 bytes)
//   data:       82 bytes = [supply: u64, mint_authority, decimals, ...]
//   owner:      TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA (SPL Token program)
//   executable: false

// Example: a user's USDC token account
//   lamports:   ~2.04e6 (rent-exempt for size=165 bytes)
//   data:       165 bytes = [mint, owner, amount, delegate, state, ...]
//   owner:      TokenkegQ... (the program "owns" the data layout)
//   executable: false

// Note: every account's data is interpreted by its owner program. A user
// can't write to an account they don't own unless the owner allows it via
// CPI (Cross-Program Invocation).

The Account Model