The Solana Mental-Model Ramp

New Solana developers learn faster with a fixed concept order: accounts before instructions, instructions before transactions, then PDAs, CPIs, and compute budgets on Agave 4.1.1. This page is the reading and exercise sequence before writing production Anchor 0.32.1 code.

Recipe

Quick-reference recipe card - copy-paste ready.

1. Accounts + owners
2. Programs (stateless executables)
3. Instructions + signers
4. Transactions + blockhashes
5. PDAs + seeds + bumps
6. CPIs + account validation
7. Compute units + priority fees
8. Clients (@solana/kit 7.0.0 / CLI)

When to reach for this:

First week onboarding before feature work.
EVM or Cosmos hires switching execution models.
Frontend engineers who will read program IDLs.
PMs who need accurate vocabulary for specs.

Working Example

# Exercise sequence on devnet (Solana CLI 3.0.10)
 
# 1) See an account
solana account 11111111111111111111111111111111
 
# 2) Transfer SOL (instruction + signer)
solana transfer <RECIPIENT> 0.01 --allow-unfunded-recipient
 
# 3) Inspect transaction instructions
solana confirm -v <SIGNATURE>
 
# 4) Find a PDA from your program's seeds (Anchor logs on devnet deploy)
anchor deploy && anchor run test

What this demonstrates:

CLI makes accounts and instructions tangible before Rust syntax.
Verbose confirm shows program IDs and account metas.
Anchor tests exercise PDAs and CPIs without manual packing.
Devnet mistakes are cheap - use them while learning.

Deep Dive

Stage 1 - Accounts & Ownership

Everything persistent is an account (lamports + bytes + owner).
Programs are executable accounts but keep minimal state in the program account itself.
Only the owner program may write an account's data (unless system-level exceptions).

Stage 2 - Instructions & Transactions

An instruction names a program, account list, and opaque data payload.
A transaction atomically runs one or more instructions with one recent blockhash.
Signers authorize fee payment and privileged account mutations.

Stage 3 - PDAs

Program Derived Addresses have no private key; programs sign via seeds + bump.
Seeds are domain-separated; collisions are infeasible with correct construction.
Store canonical bump on-chain to avoid runtime bump hunting (CU cost).

Stage 4 - CPIs

Cross-Program Invocation lets your program call SPL Token, System, or third-party programs.
You must pass every account the callee expects - the runtime does not infer.
Reentrancy and privilege escalation are review focus areas.

Stage 5 - Runtime Economics

Compute units (CU) meter execution; exceeding budget fails the transaction.
Priority fees influence scheduling during congestion.
Rent-exempt minimum balances determine account creation costs.

Learning Path Table

Day	Concept	Exercise	Doc link
1	Accounts	`solana account`	Solana Basics
2	Instructions	CLI transfer	Transactions Basics
3	Anchor accounts	`#[derive(Accounts)]`	Accounts struct
4	PDAs	`seeds` constraint	PDAs section
5	CPI	`anchor_spl::token`	CPI Anchor
6	CU/fees	simulate + budget ix	Priority fees
7	Client	kit read/write	kit Basics

Gotchas

Thinking contracts hold storage - EVM maps poorly. Fix: repeat "state lives in accounts."
Skipping signer rules - leads to mainnet exploits. Fix: diagram signers per instruction early.
PDA as person - PDAs are addresses, not wallets with keys. Fix: practice invoke_signed.
Ignoring CU until prod - surprises near launch. Fix: simulate CU in week 1 tests.
Learning clients before accounts - confusing errors. Fix: follow ramp order strictly.

Alternatives

Alternative	Use When	Don't Use When
Jump to Anchor tutorial	Impatient dev with buddy	Self-serve without review
EVM comparison doc only	Experienced Solidity	Primary learning path
Video-only course	Supplement	Sole onboarding material
Mainnet "learn by doing"	Never	Onboarding

FAQs

How long per stage?

Half day per row in the table for most engineers.

Anchor before native?

Yes for ramp - Anchor reveals PDAs/CPIs with guardrails.

Frontend dev depth?

Stages 1-2 and 5-6 deeply; 3-4 conceptually with IDL examples.

Quiz?

Buddy asks: who signs, who pays rent, where is state stored.

Alpenglow changes?

Mental model for accounts/programs stays; confirmation docs evolve separately.

Token focus?

Add SPL Token day after stage 2 if product is DeFi/NFT.

Local vs devnet?

Local for fast loops; devnet for realistic fees and RPC behavior.

LiteSVM role?

Reinforce stages 3-5 with unit tests in Rust.

Common blockers?

Borrow checker + account lifetimes - pair with Rust buddy hour.

After ramp?

Proceed to First Program & dApp guided project.

Onboarding Devs Checklist - full checklist
Solana Basics - fundamentals
The Solana Mental Model vs. EVM - comparison
Programs Basics - runtime

Stack versions: This page was written for Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0, and LiteSVM 0.6.x.

Recipe

Quick-reference recipe card - copy-paste ready.

1. Accounts + owners
2. Programs (stateless executables)
3. Instructions + signers
4. Transactions + blockhashes
5. PDAs + seeds + bumps
6. CPIs + account validation
7. Compute units + priority fees
8. Clients (@solana/kit 7.0.0 / CLI)

When to reach for this:

First week onboarding before feature work.
EVM or Cosmos hires switching execution models.
Frontend engineers who will read program IDLs.
PMs who need accurate vocabulary for specs.

Working Example

# Exercise sequence on devnet (Solana CLI 3.0.10)
 
# 1) See an account
solana account 11111111111111111111111111111111
 
# 2) Transfer SOL (instruction + signer)
solana transfer <RECIPIENT> 0.01 --allow-unfunded-recipient
 
# 3) Inspect transaction instructions
solana confirm -v <SIGNATURE>
 
# 4) Find a PDA from your program's seeds (Anchor logs on devnet deploy)
anchor deploy && anchor run test

What this demonstrates:

CLI makes accounts and instructions tangible before Rust syntax.
Verbose confirm shows program IDs and account metas.
Anchor tests exercise PDAs and CPIs without manual packing.
Devnet mistakes are cheap - use them while learning.

Deep Dive

Stage 1 - Accounts & Ownership

Everything persistent is an account (lamports + bytes + owner).
Programs are executable accounts but keep minimal state in the program account itself.
Only the owner program may write an account's data (unless system-level exceptions).

Stage 2 - Instructions & Transactions

An instruction names a program, account list, and opaque data payload.
A transaction atomically runs one or more instructions with one recent blockhash.
Signers authorize fee payment and privileged account mutations.

Stage 3 - PDAs

Program Derived Addresses have no private key; programs sign via seeds + bump.
Seeds are domain-separated; collisions are infeasible with correct construction.
Store canonical bump on-chain to avoid runtime bump hunting (CU cost).

Stage 4 - CPIs

Cross-Program Invocation lets your program call SPL Token, System, or third-party programs.
You must pass every account the callee expects - the runtime does not infer.
Reentrancy and privilege escalation are review focus areas.

Stage 5 - Runtime Economics

Compute units (CU) meter execution; exceeding budget fails the transaction.
Priority fees influence scheduling during congestion.
Rent-exempt minimum balances determine account creation costs.

Learning Path Table

Day	Concept	Exercise	Doc link
1	Accounts	`solana account`	Solana Basics
2	Instructions	CLI transfer	Transactions Basics
3	Anchor accounts	`#[derive(Accounts)]`	Accounts struct
4	PDAs	`seeds` constraint	PDAs section
5	CPI	`anchor_spl::token`	CPI Anchor
6	CU/fees	simulate + budget ix	Priority fees
7	Client	kit read/write	kit Basics

Gotchas

Thinking contracts hold storage - EVM maps poorly. Fix: repeat "state lives in accounts."
Skipping signer rules - leads to mainnet exploits. Fix: diagram signers per instruction early.
PDA as person - PDAs are addresses, not wallets with keys. Fix: practice invoke_signed.
Ignoring CU until prod - surprises near launch. Fix: simulate CU in week 1 tests.
Learning clients before accounts - confusing errors. Fix: follow ramp order strictly.

Alternatives

Alternative	Use When	Don't Use When
Jump to Anchor tutorial	Impatient dev with buddy	Self-serve without review
EVM comparison doc only	Experienced Solidity	Primary learning path
Video-only course	Supplement	Sole onboarding material
Mainnet "learn by doing"	Never	Onboarding

FAQs

How long per stage?

Half day per row in the table for most engineers.

Anchor before native?

Yes for ramp - Anchor reveals PDAs/CPIs with guardrails.

Frontend dev depth?

Stages 1-2 and 5-6 deeply; 3-4 conceptually with IDL examples.

Quiz?

Buddy asks: who signs, who pays rent, where is state stored.

Alpenglow changes?

Mental model for accounts/programs stays; confirmation docs evolve separately.

Token focus?

Add SPL Token day after stage 2 if product is DeFi/NFT.

Local vs devnet?

Local for fast loops; devnet for realistic fees and RPC behavior.

LiteSVM role?

Reinforce stages 3-5 with unit tests in Rust.

Common blockers?

Borrow checker + account lifetimes - pair with Rust buddy hour.

After ramp?

Proceed to First Program & dApp guided project.

Onboarding Devs Checklist - full checklist
Solana Basics - fundamentals
The Solana Mental Model vs. EVM - comparison
Programs Basics - runtime

Stack versions: This page was written for Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0, and LiteSVM 0.6.x.

The Solana Mental-Model Ramp

Search Documentation

The Solana Mental-Model Ramp