✳ SOLANA ACADEMYCourse overview

Expert · LESSON 06 OF 06

6. 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.
6. 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 begins with a pinned source and toolchain, states invariants, tests the compiled SBF in LiteSVM, mutates one control only in a disposable copy, and reports evidence with its limits.
Expert protocol review evidence workflow. The Expert review begins with a pinned source and toolchain, states invariants, tests the compiled SBF in LiteSVM, mutates one control only in a disposable copy, and reports evidence with its 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

Five steps bind the review to exact source files and tool versions; state each protocol invariant; compile the Solana program to SBF and execute its integration tests in LiteSVM; test one deliberate mutation in a fresh disposable local copy; then report observed outputs, state comparisons, and remaining limitations. Passing a local test suite does not prove deployed code identity, safe authorities, RPC behavior, or production security.

  1. PIN SOURCE + TOOLCHAIN
  2. STATE INVARIANTS
  3. TEST COMPILED SBF
  4. MUTATE ONE CONTROL
  5. 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. Use a local in-process program harness for fast, repeatable execution; for example, LiteSVM can execute compiled program bytes but is not a full validator or RPC service. Add local-validator integration coverage when a claim depends on RPC methods, subscriptions, or validator behavior. Mock RPC separately for client failures. Coverage-guided fuzzing can explore action sequences and check invariants after each action; minimize any failure, keep its reproducing sequence, and add it as a regression test. Name the exact harness and environment because each supports different claims.

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. Bind evidence to the exact source commit, toolchain, and tested program artifact. If the project uses Anchor and makes a claim about deployed code, record the verifiable-build result for the specific program ID; matching source and binary evidence supports provenance, but does not prove the program is secure or that its live authorities are safe. 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

A pull request merges after tests pass, but no evidence shows that a mitigation blocks the documented attack path. What conclusion is justified?

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

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 online and require 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-09-28. Protocol documentation can change; check the linked page’s current version when you reconnect.