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.
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
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.
- PIN SOURCE + TOOLCHAIN
- STATE INVARIANTS
- TEST COMPILED SBF
- MUTATE ONE CONTROL
- 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. 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.
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.
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
A pull request merges after tests pass, but no evidence shows that a mitigation blocks the documented attack path. What conclusion is justified?
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.
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-09-28. Protocol documentation can change; check the linked page’s current version as you use this material.
OPEN LEARNING
Keep learning at your own pace.
This lesson, its guided practice, and all six course lessons are open to everyone. Account-based checkpoints, exams, and saved progress will open when free accounts are ready.
Return to all six lessons ↗