✳ SOLANA ACADEMYCourse overviewGlossary

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.

A security claim is traced from program invariants through account design and tests to the evidence needed for expert review.
7. Expert capstone: design a Solana application workflow. A security claim is traced from program invariants through account design and tests to the evidence needed for expert review.
A concrete engineering claim is connected in sequence to code that enforces the invariant, positive and adversarial execution tests in a named harness, and provenance for the source revision and program artifact. Local test results do not establish deployed bytecode, and exam completion does not equal independent project review.
Expert Solana capstone claim-to-evidence map. A concrete engineering claim is connected in sequence to code that enforces the invariant, positive and adversarial execution tests in a named harness, and provenance for the source revision and program artifact. Local test results do not establish deployed bytecode, and exam completion does not equal independent project review.
A learner submits a public project and exact commit. A reviewer evaluates eight published criteria. The result is either a revision request that returns to the learner or a review that meets the published standard. Earlier decisions stay in the learner's private account history.
Expert project review workflow. A learner submits a public project and exact commit. A reviewer evaluates eight published criteria. The result is either a revision request that returns to the learner or a review that meets the published standard. Earlier decisions stay in the learner's private account history.
The Expert review pins source and toolchain, states invariants, selects a harness that observes the claim, tests compiled SBF, mutates and replays one control, then reports evidence and limits.
Expert protocol review evidence workflow. The Expert review pins source and toolchain, states invariants, selects a harness that observes the claim, tests compiled SBF, mutates and replays one control, then reports evidence and limits.

Read the workflow

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.

  1. DEFINE INVARIANTS
  2. MAP ACCOUNTS
  3. BUILD + TEST
  4. 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.

  1. PIN SOURCE + TOOLCHAIN
  2. STATE INVARIANTS
  3. CHOOSE THE HARNESS
  4. TEST COMPILED SBF
  5. MUTATE + REPLAY
  6. REPORT EVIDENCE + LIMITS

FIELD NOTE 01

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.

FIELD NOTE 02

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.

FIELD NOTE 03

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.

FIELD NOTE 04

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.

FIELD NOTE 05

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.

FIELD NOTE 06

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.

FIELD NOTE 07

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.

MAKE THE CONNECTION

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. Unless a lesson explicitly says “read-only Devnet,” use paper or a local test and do not connect to a public network.

  1. 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.
  2. Build the escrow program as SBF with the lab’s pinned toolchain and run its LiteSVM suite; record actual tool versions and baseline results.
  3. 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.
  4. Add a negative regression test for a caller-controlled signer or account substitution and assert the expected rejection plus unchanged balances and escrow state.
  5. 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?

  1. Only that the tested checks passed; add a targeted regression or reproducible proof for the attack invariant before claiming the path is blocked.
  2. The system is secure because the code was reviewed and merged.
  3. The mitigation is proven because every test suite completed successfully.
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?

  1. A green suite pass count alone identifies the invariant, enforcement boundary, and exact tested artifact.
  2. Name the invariant, test, harness, revision, and artifact.
  3. A full green suite alone proves which security boundary rejected the attack and which artifact was tested.
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?

  1. The latest branch is deployed.
  2. Tests on a local binary prove that the same reviewed bytes and control authority are active in the on-chain program.
  3. Compare reproducible build output with deployed bytes and authority.
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.

Scored checkpoints and level exams are available online through a free account. They are not included in this pack.

Optional lab files

These files are included with the pack. Follow the safety and toolchain notes in the lesson before running a lab; a Devnet read requires an internet connection.

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 when you reconnect.