Get your machine ready to ship a program.

When you finish this: your machine has the system libraries every later step depends on.

Everything after this checkpoint is identical on all three platforms. Do only the block that matches your machine, then rejoin at checkpoint 1.

Windows

Solana tooling does not run on Windows natively. WSL gives you a real Ubuntu inside Windows. Run this in PowerShell as administrator:

wsl --install

Reboot, then open the Ubuntu app from the Start menu and set a username and password.

From here on, "your terminal" means that Ubuntu window, never PowerShell. Run the Linux block below inside it.

Linux and WSL

Anchor compiles from source and needs a C toolchain plus a few libraries. Missing these is the most common install failure.

sudo apt-get update
sudo apt-get install -y \
    build-essential \
    pkg-config \
    libudev-dev llvm libclang-dev \
    protobuf-compiler libssl-dev

macOS

Install Apple's command line tools, which include the linker Rust calls.

xcode-select --install
xcode-select -p   # should print a path, not an error

If they were already installed, the first line says so and the second prints a path.

When you finish this: all five tools installed and printing versions.

One script installs the whole toolchain. Try it first. If it completes, skip checkpoint 2 entirely.

curl --proto '=https' --tlsv1.2 -sSfL https://solana-install.solana.workers.dev | bash

It finishes by printing what it installed:

Installed Versions:
Rust: rustc 1.91.1 (ed61e7d7e 2025-11-07)
Solana CLI: solana-cli 3.0.10 (src:96c3a851; feat:3604001754, client:Agave)
Anchor CLI: anchor-cli 0.32.1
Surfpool CLI: surfpool 0.12.0
Node.js: v24.10.0
Yarn: 1.22.1

Surfpool is a local validator. The installer bundles it, this guide does not use it, and it comes up in a later class. Ignore it for now.

Close your terminal and open a new one. The script edited your shell profile and the current session has not read it.

Now check all five tools:

rustc --version && solana --version && anchor --version && \
node --version && yarn --version

When you finish this: the tools checkpoint 1 missed, installed by hand.

Install one at a time, in this order, verifying each before moving on. Anchor depends on Rust and on the checkpoint 0 libraries, so order matters.

If only one tool is missing, jump straight to that block.

Rust

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
. "$HOME/.cargo/env"
rustc --version

Solana CLI

sh -c "$(curl -sSfL https://release.anza.xyz/stable/install)"
solana --version

echo $SHELL   # /bash → .bashrc,  /zsh → .zshrc

echo 'export PATH="$HOME/.local/share/solana/install/active_release/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

Node and Yarn

Anchor's test template is TypeScript, so anchor test needs both.

Install Node through nvm rather than your system package manager, so you can switch versions per project.

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
# restart your terminal, then:
nvm install --lts
npm install -g yarn
node --version && yarn --version

Anchor, through AVM

Install the version manager, not the framework directly. Anchor makes breaking changes between minor versions, and you will eventually need two versions for two projects.

curl -sSfL https://raw.githubusercontent.com/otter-sec/anchor/master/avm/install | sh
avm --version

avm install latest
avm use latest
anchor --version

When you finish this: your versions match the rest of the class.

Solana tooling moves fast enough that a three-month-old blog post is often wrong. When forty people debug together, mismatched versions waste more time than any real bug.

Get onto these versions. If you cannot, say so in the channel before you ask for help.

A patch-level difference is fine. A minor-version difference in Anchor is not.

0.31 and 0.32 generate different client code, and code from one will not compile against the other.

Network devnet

When you finish this: a wallet with about 5 devnet SOL in it, and a CLI pointed at devnet.

The CLI keeps one small config file. It decides which network your commands talk to and which keypair signs them.

Almost every "it worked yesterday" story is one of those two being different from what you assumed. Look at it first:

solana config get

You should see something like this:

Config File: /Users/you/.config/solana/cli/config.yml
RPC URL: https://api.mainnet.solana.com
WebSocket URL: wss://api.mainnet.solana.com/ (computed)
Keypair Path: /Users/you/.config/solana/id.json
Commitment: confirmed

Point at devnet

Switch the network your commands talk to:

solana config set --url devnet
solana config get   # confirm the RPC URL now says devnet

The RPC URL should now say devnet. Check it before you blame your code — this one line explains a lot of confusing errors.

Create a keypair

Write a new keypair to the default path:

solana-keygen new
solana address

It prints a public key and a twelve-word seed phrase. That public key is your address on every Solana network at once.

Get devnet SOL from the faucet

Do this now, at the start. Four steps:

1. Go to faucet.solana.com.
2. Sign in with GitHub. This unlocks the higher limit of 5 SOL. The faucet works signed out, but gives you less than the checkpoint 8 deploy needs.
3. Paste in the address that solana address printed.
4. Confirm it landed.

solana balance

You want to see roughly 5 SOL.

Network devnet

When you finish this: a confirmed transaction you can open in the explorer.

Send a transaction yourself, then read back what the network recorded.

This runs on devnet because you need a link other people can open. The whole thing costs 5000 lamports — essentially nothing.

Make somewhere to send it

Create a second keypair to receive the transfer:

solana-keygen new --no-bip39-passphrase --silent -o ~/throwaway.json
solana address -k ~/throwaway.json

It prints the throwaway address.

Send

Transfer 0.1 SOL to it:

solana transfer $(solana address -k ~/throwaway.json) 0.1 --allow-unfunded-recipient

You get back a signature — a long base58 string. Copy it.

That signature is the transaction's identity. It exists because your keypair signed the message; the network did not assign it.

Now ask the network what happened:

solana confirm -v <YOUR_SIGNATURE>

Read what you just did

Open the signature in the explorer. Keep the cluster parameter on the end.

https://explorer.solana.com/tx/<YOUR_SIGNATURE>?cluster=devnet

Match what you see on the page against the terms below:

solana config set --url <your-helius-devnet-url>

Network localnet — no SOL needed

When you finish this: a generated Anchor project that builds and passes its test.

Anchor generates a working program, a test, and the config that ties them together.

Everything here runs on your own machine. anchor test handles the network itself, so there is no faucet and no SOL involved.

Do this somewhere sensible — on WSL, inside your Linux home directory:

mkdir -p ~/solana && cd ~/solana
anchor init hello_solana
cd hello_solana

What it made

Open lib.rs and read it before building. It is about fifteen lines: a program ID, one instruction, one log.

The instruction takes a Context listing its accounts — the same up-front account declaration you saw in the explorer at checkpoint 5. Everything you write this term is a variation on that shape.

Build it

Compile the program to SBF bytecode:

anchor build

Expect no output for a long time. That is normal.

Building also generates a keypair for your program. Its public key is the program ID.

That ID appears in two text files as well, and they start out disagreeing with the keypair. Sync them:

anchor keys sync
anchor keys list

Both should now print the same program ID.

Test it

Build, deploy locally, and run the TypeScript tests:

anchor test

You should see one passing test and a transaction signature.

That single command started a disposable network on your machine, deployed to it, ran the tests, then tore the network down. You never start or stop anything yourself.

solana-test-validator          # leave this running
solana config set --url localhost
solana airdrop 100
solana balance

solana logs

solana config set --url devnet
pkill -f solana-test-validator

Network localnet — nothing to fund

When you finish this: a PDA you derived yourself, and proof that deriving is not creating.

A PDA is an address computed from a program ID plus some seeds. It has no private key, which is exactly why programs use it to own state.

Deriving one is pure local maths. No network, no SOL, nothing to fund.

In your hello_solana directory, create pda.js:

const { PublicKey } = require("@coral-xyz/anchor").web3;

const programId = new PublicKey(process.argv[2]);
const seed = process.argv[3] ?? "counter";

const [pda, bump] = PublicKey.findProgramAddressSync(
  [Buffer.from(seed)],
  programId
);

console.log("program", programId.toBase58());
console.log("seed   ", seed);
console.log("pda    ", pda.toBase58());
console.log("bump   ", bump);

Run it with your own program ID from anchor keys list:

node pda.js <YOUR_PROGRAM_ID> counter

Three things to try

1. Run it twice with the same seed. Same address, every time, on every machine. Nothing was stored anywhere — the address is computed.
2. Change the seed to vault. Completely different address, from the same program. This is how one program keeps thousands of separate accounts without tracking a single keypair.
3. Look up the address you derived. It does not exist:

solana account <THE_PDA>   # Error: AccountNotFound

Network devnet — this is the expensive step

When you finish this: your program live on devnet, visible in the explorer.

Same program as checkpoint 6, but a network you do not control. It costs real devnet SOL and takes a minute rather than a second.

Follow these six steps in order. Do not skip step 4.

1 · Check where you are and what you have

solana config get       # RPC URL must say devnet
solana balance          # need at least 3 SOL

Short on SOL? Go back to checkpoint 4 and use the faucet before you continue.

2 · Point Anchor at devnet

Edit Anchor.toml:

[provider]
cluster = "devnet"
wallet = "~/.config/solana/id.json"

3 · Build

anchor build

This should take seconds — you already built once.

4 · Preview the cost before you spend it

Ask what storing the compiled program will cost:

solana rent $(wc -c < target/deploy/hello_solana.so)

Expect a figure in the region of 2 to 3 SOL for a small Anchor program.

Two things make it that high. Solana allocates roughly double your binary size, leaving room to upgrade the program later.

The deploy also creates buffer accounts — temporary accounts that hold your program's bytes while they upload. They cost SOL too.

5 · Deploy

anchor deploy

It prints your program ID when it succeeds.

6 · If the deploy failed, run this before retrying

solana program close --buffers

See it on the network

Open your program ID in the explorer, keeping the cluster on the URL:

https://explorer.solana.com/address/<PROGRAM_ID>?cluster=devnet
solana program show <PROGRAM_ID>

Your program is now an account on a public network, owned by the BPF loader, holding your compiled bytecode. Same account model as everything else you have touched today.

Clean up when you are done

Close the program to reclaim most of the SOL:

solana program close <PROGRAM_ID> --bypass-warning
solana program close --buffers   # reclaims leftovers from failed deploys

Have a look at it in the explorer first — closing is irreversible.

solana config set --url <your-helius-devnet-url>

When you finish this: confidence that every piece actually works.

Run through these five yourself before you close the tab:

1. The verify script below runs clean.
2. Your anchor test run shows the test passing.
3. Your transfer signature from checkpoint 5 opens in the explorer.
4. Your devnet program ID opens in the explorer, with ?cluster=devnet.
5. You can say in a couple of sentences what broke and how you fixed it. If nothing broke, say why the PDA in checkpoint 7 had no account behind it.

Paste this into your terminal. It prints one line per tool, marking each present or missing, then shows your current cluster and wallet. Run it before asking for help, and paste the output with your question.

#!/usr/bin/env bash
# solana-doctor — checks the toolchain for Solana Fall School

for t in rustc cargo solana anchor avm node yarn; do
  if command -v "$t" >/dev/null 2>&1; then
    printf 'ok   %-7s %s\n' "$t" "$("$t" --version 2>/dev/null | head -1)"
  else
    printf 'MISS %-7s not on PATH\n' "$t"
  fi
done

echo
solana config get 2>/dev/null | grep -E 'RPC URL|Keypair Path'
echo "address: $(solana address 2>/dev/null || echo 'no keypair yet')"
echo "balance: $(solana balance 2>/dev/null || echo 'unreachable')"

Healthy output has seven ok lines, an RPC URL pointing at devnet, and a balance. Any MISS line names the tool to reinstall from checkpoint 2 — and only that tool.

mkdir -p ~/bin
# paste the script into ~/bin/solana-doctor, then:
chmod +x ~/bin/solana-doctor
echo 'export PATH="$HOME/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
solana-doctor

Ranked by how often it actually happens in a room of forty people.

solana program close --buffers
solana balance

solana config set --url <your-helius-devnet-url>

which rustc cargo solana anchor node yarn cargo-build-sbf

pkill -f solana-test-validator
anchor test

anchor keys sync
anchor build
anchor deploy

cp -r /mnt/c/Users/you/hello_solana ~/
cd ~/hello_solana && anchor build