Basic · LESSON 06 OF 08
6. Build and test a first local program
By the end, you can build a small solana program from the official starter and explain what a local litesvm test proves.
Look up Solana terms in the glossary
Optional reading history is saved only in this browser. It is not a scored checkpoint or exam result.
In this lesson9 field notes · practice · sources · checkpoint
Read a text version of this diagram
A developer reads the official Anchor starter and its tool requirements, builds the source into an SBF artifact, and loads that artifact in a local LiteSVM test. The test executes initialize and increment using ephemeral test accounts and checks state assertions. No RPC, public cluster, wallet connection, airdrop, transaction fee, or deployment is needed. Optional Devnet deployment is a separate signed and funded action.
- SOURCE + TOOLCHAIN
- ANCHOR BUILD
- SBF ARTIFACT
- LITESVM TEST
- ASSERTED STATE
Read a text version: Two safe ways to try a first Solana program
Both routes begin with the same Anchor counter learning goal. The browser route uses Solana's official Playground and an internet connection; its fresh test-only keypair stays in browser local storage. Verify Devnet before any optional signed action, and use faucet SOL only if needed. Never import an existing wallet or recovery phrase. The local route builds with Anchor and runs LiteSVM tests without RPC, wallet, faucet, or real SOL. Both routes end by reviewing the source, signer, account state, and test evidence; deployment is optional.
- Same Anchor counter learning goal
- Choose browser or local tools
- Official Playground in a fresh test wallet
- Verify Devnet; faucet SOL only if needed
- Local Anchor build and LiteSVM test
- Review source, signer, account, and test evidence
OPTIONAL NO-INSTALL BROWSER PATH
Try Solana Playground on Devnet
Use a fresh test-only Playground wallet, verify Devnet before any signed action, and use faucet SOL only if needed. Never import an existing wallet or recovery phrase into Playground or the course site. The local LiteSVM path remains available without RPC, wallet, faucet, or real SOL.
Open Solana's official Quick Start ↗ Review Solana clusters ↗A program is code; its state is in accounts
Solana programs are executable code that operate on accounts supplied to each instruction. A program account holds executable data, while a separate data account stores the counter in this example. Keep those roles separate: editing source code locally does not create an on-chain program account, and a local test does not publish anything to a cluster. This lesson uses the official Anchor counter starter because it gives a beginner a small, observable state change without asking them to invent account serialization first.
Choose the local path
Solana’s current automated installer supports macOS, Linux, and Windows through WSL and installs Rust, the Solana CLI, Anchor CLI, Surfpool, Node.js, and Yarn. Review the installer source before running it because it changes your machine, then record `rustc --version`, `solana --version`, and `anchor --version`. The documented Windows path is WSL; native Windows is not the stated path. This counter starter requires Anchor CLI 1.1.2 or newer. Its generated test is a Rust/LiteSVM template that runs `cargo test`, so this test path does not need a TypeScript runtime. TypeScript-based test templates require Node.js and a package manager. Inspect the generated `Anchor.toml` and test files before troubleshooting a missing tool. The course reading itself remains free and needs no account, wallet, recovery phrase, RPC key, or SOL.
Try the browser path (optional)
If you cannot install local tools, Solana’s official Quick Start also walks through a browser-based Solana Playground path. It uses an internet connection and a Playground keypair saved in that browser’s local storage. Create a fresh test-only Playground wallet for this exercise; never import an existing wallet or recovery phrase into Playground or the course site. Before any optional transaction, verify that the selected cluster is Devnet. Devnet tokens have no Mainnet value; request faucet SOL only if a specific Devnet action needs it. Playground can sign and submit test transactions, so read the wallet prompt and stop if the cluster or requested action is unexpected. You can complete the local LiteSVM route without RPC, wallet, faucet, or real SOL, and deploying remains optional.
Create the starter
Follow the official Build Your First Program guide and create the `my-program` starter with `anchor init my-program`. The starter is an Anchor workspace with an `initialize` instruction that creates counter state and an `increment` instruction that changes it. In the current template, the counter is a PDA derived from a seed; initialization requires a signer payer, and increment checks the stored authority and a maximum count. The example also makes a small System Program CPI transfer. Inspect the generated source, account type, instruction contexts, tests, and configuration before editing. This connects the pieces: a client requests an instruction, the program checks supplied accounts, and persistent state lives in an account owned by that program.
Build the program artifact
From the generated workspace, run `anchor build` as shown in the official guide. This compiles the program for Solana’s SBF runtime and writes an artifact under `target/deploy/`. A successful build establishes that the local toolchain compiled that source for the target; it does not prove the code is secure, correct for every input, deployed, or available on Mainnet. Review warnings and record the CLI and Anchor versions. If the build fails, capture the exact error and compare the environment with the official installation prerequisites rather than installing random binaries from an untrusted page.
Test with LiteSVM
Run `anchor test` in the official starter workspace. The guide’s generated configuration sets `skip_local_validator = true`; its test uses LiteSVM, an in-process Solana Virtual Machine, to load the built program bytes and execute instructions without starting a validator or contacting an RPC service. The test creates an ephemeral payer and gives it simulated funds inside LiteSVM, so it can exercise account creation and the sample transfer without a faucet or real SOL. The assertions check initialization and counter changes. `anchor test` also compiles the program, so the separate `anchor build` step is useful for inspecting the artifact but is not required before this test. Local simulation is not a wallet approval, public transaction, or credential mint.
Read the evidence
A green local test answers only the assertions it ran against the program artifact and the simulated inputs. Read the assertions: identify which account is created, which program owns it, which signer authorizes initialization, and what value changes after increment. Add a negative case, such as a missing required signer or an invalid account, only by following the starter’s actual account constraints; then verify the expected error. Distinguish build evidence, test evidence, and deployment evidence. An RPC signature and cluster inspection would be needed for a later Devnet deployment, and neither is part of this free local lesson.
Deployment is a separate, optional step
Deploying a program to Devnet is not required to complete this lesson. Deployment requires a cluster choice, a program keypair or deployment authority, a signed transaction, and SOL for network fees and program-account storage. It creates public on-chain state and is different from running LiteSVM locally. Do not use a valuable wallet or paste a recovery phrase into a course page. If you later choose deployment, use the official deploy guide, a dedicated test wallet, a current fee estimate, and the wallet’s transaction preview; stop before signing if the program ID, cluster, payer, or total cost is unexpected.
Carry the workflow forward
Use the same evidence habit in Intermediate: name the source revision, tool versions, build output, test assertions, and exact environment. A test suite is a set of checks, not a security audit or proof of production readiness. Before relying on a program, review account ownership and signer rules, test malformed inputs and failure paths, and compare the deployed program identity with the reviewed build. This first exercise gives you a safe local loop; later lessons add native Rust processors, PDAs, cross-program invocations, and adversarial tests.
A detail worth keeping.
The official Starter path is a versioned external example. Before following it, check the page’s current CLI requirements and generated workspace; commands and test configuration can evolve. Keep the exact source URL and tool versions with your notes so a later learner can reproduce the exercise.
Work through an example
A local program test can help you iterate without RPC credentials, network fees, or a wallet. It cannot establish cluster behavior, deployed-byte identity, upgrade authority, production observability, or economic safety. Those are separate review questions with separate evidence.
Open the official counter starter. Trace `initialize` from its client test to the program instruction and account state, then trace `increment`. Write down what `anchor build` produces and what the LiteSVM assertions prove. Explain why neither command creates a Devnet transaction.
GUIDED PRACTICE · BASIC
Do the work, one step at a time.
Use fictional addresses and disposable test data. Do not enter a recovery phrase or private key. Most exercises work on paper or with a local test; only a lesson that clearly says “read-only Devnet” makes a public network request.
- Read the official installation prerequisites; confirm your platform follows the documented path.
- Create the official Anchor counter starter and inspect its source, counter PDA, account type, test, and validator configuration.
- Build locally and record the generated SBF artifact path and tool versions.
- Run the starter test and identify how LiteSVM loads the artifact, simulates the payer balance, and checks counter state.
- Add or describe one negative case grounded in a real signer or account constraint; confirm that failure leaves the intended state unchanged.
- Write a short evidence note separating source, build, test, and optional deployment claims. Do not connect a wallet or request a faucet airdrop for this lesson.
Before you move on, check your reasoning
- Map the client instruction, program handler, required accounts, PDA seeds, stored authority check, and resulting account data for `initialize` and `increment`.
- Run the documented build and LiteSVM test; record tool versions and quote the assertions that passed.
- Propose one negative test from an actual account constraint, and state the expected error and state invariant.
- List the extra authorization, cost, and cluster evidence that would be needed before an optional Devnet deployment.
OPEN SELF-CHECK · UNGRADED
Pause and test your reasoning
Practice 1 of 3
What does a passing LiteSVM test of the Anchor starter establish?
Reveal the answer and explanation
One best answer: The tested assertions passed against the local program artifact and simulated inputs.
LiteSVM runs locally. A test proves only the assertions it executes for the artifact and inputs used; it does not deploy the program or establish comprehensive security. Inspect the generated test to match every claim to a real assertion.
Sources: Build Your First Program · Programs
Practice 2 of 3
Which action in the official local workflow creates the SBF program artifact?
Reveal the answer and explanation
One best answer: Running `anchor build` in the generated workspace.
The documented Anchor build compiles the program for Solana’s SBF runtime and writes a local artifact. It does not publish that artifact to a cluster. Deployment is a separate signed action with a selected cluster and payer.
Sources: Build Your First Program
Practice 3 of 3
What does a learner need to do for the free local program exercise?
Reveal the answer and explanation
One best answer: Use the local starter and test accounts; no wallet or faucet is needed.
The official Starter test uses local LiteSVM and an ephemeral test payer. Wallet connection, airdrop, RPC credentials, and deployment are outside this lesson. The core reading and local workflow do not ask learners to spend SOL.
Sources: Build Your First Program
This practice is not scored, saved, or part of a certificate. Account-based lesson checkpoints and level exams remain separate.
Never enter a recovery phrase or private key into a learning site or lesson exercise.
READ THE SOURCE
Go deeper in the official docs
Reviewed on 2026-10-03. Protocol documentation can change; check the linked page’s current version as you use this material.
YOUR PROGRESS, SAVED
Ready for the checkpoint?
Make a free account to save your progress and unlock the quizzes.
Create free account