Expert · LESSON 07 OF 07
7. Expert capstone: design a Solana application
By the end, you can produce a reviewable solana application architecture, implementation plan, tests, and evidence-based risk report.
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 lesson7 field notes · practice · sources · checkpoint
Read a text version of this diagram
The learner states concrete invariants, maps them to accounts and authorization checks, and supplies reproducible builds and tests for both allowed and rejected paths. Reviewers trace each claim to a named artifact, exact commit, and evidence source, then record a decision against the published rubric. This project review is not a protocol audit or production approval.
- DEFINE INVARIANTS
- MAP ACCOUNTS
- BUILD + TEST
- REVIEW EVIDENCE
Read a text version: Expert protocol review evidence workflow
Six steps bind the review to exact source and tool versions; state each protocol invariant; select a unit, in-process SVM, local cluster, mocked RPC, or fuzz harness that can observe the claim; compile and test the Solana program; mutate one control only in a disposable copy and replay the regression; then report observed outputs, pre-state/post-state comparisons, and limits. A LiteSVM result alone does not prove RPC or validator behavior, deployed code identity, safe authorities, or production security.
- PIN SOURCE + TOOLCHAIN
- STATE INVARIANTS
- CHOOSE THE HARNESS
- TEST COMPILED SBF
- MUTATE + REPLAY
- REPORT EVIDENCE + LIMITS
Choose a problem with a testable boundary
Select a small application such as escrow, staking, ticketing, a token-gated membership, or a learning credential. State the user need, assets at risk, supported operations, and explicit non-goals. Keep the first version small enough to test. Do not begin with a feature list: define the invariants that must remain true if a caller is malicious, an RPC response is delayed, or a transaction fails. Use synthetic identities and valueless assets in local development.
Design accounts and authorities before instructions
Draw every program, state account, token mint, token account, user signer, PDA, and external dependency. For each account, record its owner program, data layout, derivation seeds, mutability, and authority. Explain which party pays for account creation and transaction fees. Define upgrade authority and pause capability. This map helps expose confused ownership and authority relationships before implementation; a diagram should reflect actual account constraints rather than merely resemble the product architecture.
Specify instruction invariants and transitions
For every instruction, list required signers, expected program IDs, account relationships, input bounds, state changes, emitted events, and failure behavior. Include a transition table showing allowed states and who can move between them. Derive canonical addresses and validate token program, mint, owner, and destination when assets are involved. Use explicit arithmetic bounds and reject duplicate or stale operations. If a feature relies on an off-chain service, state what the on-chain program can verify independently.
Build a client that respects transaction evidence
The client should select a known cluster, build and simulate a transaction, show the user the exact operation and fee payer, and ask the wallet to sign the intended message. Track the returned signature and confirmation state without treating submission as success. Handle blockhash expiration, RPC timeouts, rejected wallet prompts, rate limits, and stale responses. A read-only view should remain useful without a wallet. Never request a seed phrase or private key, and keep any optional wallet connection separate from account sign-in.
Compose programs and assets deliberately
If the application uses a CPI, document the callee program ID and privileges forwarded to it. If it uses SPL or Token-2022, list enabled extensions and their authorities. If it uses an oracle, indexer, or metadata service, define what happens when that dependency is stale or unavailable. Avoid adding a feature merely because a standard supports it; extensions can introduce authority and compatibility constraints. Keep one end-to-end workflow that a reviewer can reproduce on a local validator before considering a Devnet demonstration.
Test the invariant, including failure paths
Create positive tests for the intended flow and negative tests for wrong signers, substituted accounts, wrong mint, invalid PDA seeds, duplicate requests, boundary values, stale state, and malicious CPI inputs. Assert both the expected error and unchanged protected state. A worked release trace makes the evidence concrete: the Token Escrow Lab binds the signing beneficiary to the address stored in escrow, re-derives the escrow PDA from maker and ID, checks the vault mint and PDA authority, and binds the destination token account to the same mint and beneficiary. The handler accepts only Funded state and enough vault balance, transfers the recorded amount with the PDA signer, and then marks the escrow Released. Beneficiary release is allowed after funding; the maker's refund has a separate Clock deadline. First record the allowed release's balances and state. Then substitute an attacker signer and, separately, an attacker-owned destination; expect rejection, reload the accounts, and show that vault amount and Funded status are unchanged and the attacker received nothing. A second release must not transfer the amount again. In a disposable copy, remove one binding control; the regression test should now fail. If it still passes, the test did not observe that control.
Choose the harness that can actually observe the claim. Pure unit tests cover deterministic helpers. LiteSVM executes an in-process SVM and compiled program bytes, but it is not an RPC node; it also lets tests write arbitrary account data, including states that could not exist on a valid ledger, so label those fixtures as fault injection. A local cluster is needed when the claim depends on RPC methods or validator behavior. Anchor's current CLI starts Surfpool by default for localnet `anchor test`; `anchor test --validator legacy` selects `solana-test-validator`. Record which backend ran. For an SBF v3 program, current Anchor guidance requires a compatible validator (Solana/Agave 4.0 or newer); verify the current compatibility matrix instead of assuming defaults stay fixed. Mock RPC separately to test client timeouts and malformed responses. Coverage-guided fuzzing explores stateful action sequences and checks invariants after each action; minimize every failure, preserve its reproducing sequence, and add it as a regression. No one harness proves behavior outside what its fixture and runtime actually observed.
Present evidence and limits honestly
Submit an architecture diagram, account and authority table, instruction specification, threat model, test report, client workflow, deployment plan, and residual-risk register. Make each claim a row in an evidence map: name the invariant, its enforcing source location, the positive and adversarial tests, the harness/backend, the observed pre-state and post-state, the artifact revision, and the remaining limit. For an escrow release, “the beneficiary receives the agreed amount” is supported by the successful transfer and status transition; “an attacker cannot redirect it” needs a rejected substituted-destination test plus unchanged vault/status and zero attacker credit. A test name or error log by itself is not evidence of an unchanged account.
Bind the package to the exact source commit and clean/dirty state, `Cargo.lock`, `Anchor.toml`, Rust, Anchor CLI, Solana/Agave and platform-tools versions, selected SBF architecture, exact commands, harness backend, test output, and program artifact hash. `anchor build --verifiable` uses a Docker build with pinned dependencies and relies on a lockfile for reproducibility; verification can support a source-to-binary provenance claim, but it does not prove correctness, security, or safe live authorities. A multiple-choice course exam establishes performance on its question set; it does not establish that a project was reviewed. Learners who complete the course may separately submit a public repository and exact commit for optional staff review against the published rubric. That review is tied to the submitted evidence and remains separate from the exam certificate. Neither outcome is a formal security audit, accreditation, or proof of production experience.
A detail worth keeping.
Use a small escrow as the worked system. Model create, deposit, release, refund, and close as explicit transitions; verify the vault mint and authority; then test recipient substitution, duplicate release, and a failed CPI without changing protected state.
Work through an example
Build from a clean checkout using pinned tool versions. A reviewer should reproduce the tests and understand which results are local-only, which were observed on Devnet, and which remain assumptions. Do not put a mainnet deployment or real-value transfer in the required student workflow.
Use Expert Protocol Review Kit 01 with a fresh copy of Token Escrow Lab 01. Reproduce the pinned SBF build and LiteSVM baseline, map the stored-beneficiary, mint/vault, deadline, one-time transition, monotonic-ID, and surplus invariants to their account constraints and tests, then add one negative regression case that checks both the expected rejection and unchanged protected state. Run the kit’s controlled mutations only on a disposable local copy, report any surviving mutation as a test gap, and submit the source and artifact hashes, test environment, findings, and a remaining-risk register that records residual risks. For your own application, include the same evidence package and distinguish self-review from optional staff review. This is an educational code specimen, not an audit or production template.
GUIDED PRACTICE · EXPERT
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.
- Download Expert Protocol Review Kit 01 and Token Escrow Lab 01, extract them into a fresh workspace, and record the source, test, lockfile, and artifact hashes.
- Build the escrow program as SBF with the lab’s pinned toolchain and run its LiteSVM suite; record actual tool versions and baseline results.
- Trace each attack-matrix invariant through the account constraints, instruction checks, CPI, and post-state assertions; record where evidence is source-only or test-executed.
- Add a negative regression test for a caller-controlled signer or account substitution and assert the expected rejection plus unchanged balances and escrow state.
- Run each mutation only in a disposable copy, complete the workpaper, and state exactly what local SBF/LiteSVM evidence does not prove about a deployed program.
Before you move on, check your reasoning
- Publish the problem, invariants, and project scope.
- Implement the account model and one complete workflow.
- Present tests, review feedback, and unresolved risks.
OPEN SELF-CHECK · UNGRADED
Pause and test your reasoning
Practice 1 of 3
A pull request merges after tests pass, but no evidence shows that a mitigation blocks the documented attack path. What conclusion is justified?
Reveal the answer and explanation
One best answer: Only that the tested checks passed; add a targeted regression or reproducible proof for the attack invariant before claiming the path is blocked.
A passing suite supports only its recorded assertions. Tie the threat, invariant, mitigation, artifact revision, and test evidence together; then preserve the exploit as a regression case and review the actual enforcing boundary.
Sources: Fuzz Testing · Sealevel Attacks
Practice 2 of 3
A local regression demonstrates an attack is rejected. What should the capstone evidence bundle identify?
Reveal the answer and explanation
One best answer: Name the invariant, test, harness, revision, and artifact.
A reviewable claim links what should be true to where it is enforced and how the evidence was produced. A pass count without provenance cannot be tied to a particular mitigation or artifact.
Sources: LiteSVM · Sealevel Attacks · Verifiable Builds
Practice 3 of 3
A program was built locally and its tests pass. What proves the deployed bytes match the reviewed build?
Reveal the answer and explanation
One best answer: Compare reproducible build output with deployed bytes and authority.
Local test results apply to a specific build. A verifiable-build procedure connects source and toolchain to binary bytes, while on-chain inspection identifies the deployed program and its control authority.
Sources: Verifiable Builds · Deploying Programs
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.
DOWNLOADABLE EXPERT SECURITY REVIEW · LOCAL ONLY
Reproduce a protocol review with test evidence.
Start with a fresh copy of both archives. Build the escrow sample as SBF, run its LiteSVM integration suite, trace invariants to account constraints and unchanged-state assertions, then add a negative regression case and complete the evidence workpaper. The mutation drills are for a disposable local copy only.
Download Expert Protocol Review Kit 01 Download Token Escrow Lab 01These exercises use synthetic accounts and a local test runtime. They do not connect a wallet, call an RPC endpoint, spend real SOL, deploy code, or constitute an audit.
OPTIONAL EXPERT PORTFOLIO REVIEW · FREE
Get feedback on a real project.
Your Expert exam certificate records the exam result. A separate human review can assess a public project against eight published engineering criteria, request a revision, and preserve feedback for each exact source commit. The review is not a security audit or accreditation.
READ THE SOURCE
Go deeper in the official docs
Reviewed on 2026-10-02. 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