Search across all documentation pages
Case studies and reference builds on Solana are structured learning artifacts: a known problem shape, a concrete account and instruction graph, operational gates, and measurable outcomes. Use them to transfer patterns into your program, client, and launch runbook - not as products to fork blindly.
This section holds three artifact types: reference builds (DeFi program + dApp, SPL token launch, cNFT mint), before/after studies (CU/rent and landing), and failure knowledge (security retrospectives plus a lessons catalog). This page maps how to use those artifacts as one learning system - not a recap of each sibling.
A Solana case study is valuable only when it makes constraints explicit. The chain does not care that your product is a marketplace or a game. It cares about accounts you pass, programs you CPI into, who signs, how much compute you consume, whether rent is paid, and whether the leader includes your transaction under contention.
Sibling pages in this section answer different questions:
| Artifact type | Primary question | Example in this section |
|---|---|---|
| Reference build | What does a complete path look like? | DeFi program + dApp, SPL token launch, cNFT mint |
| Before/after | What changed, and by how much? | CU/rent optimization, transaction landing |
| Retrospective | How did this class of failure work? | Security incident retrospectives |
| Catalog | What repeats, and what control stops it? | Lessons-learned catalog |
Problem frame (intent + risk)
|
v
+---------------------------+
| Reference shape | accounts, ix, client, tests
+-------------+-------------+
|
v
+---------------------------+
| Measurement | CU, rent, land rate, cost
+-------------+-------------+
|
v
+---------------------------+
| Hardening | security class + ops gates
+-------------+-------------+
|
v
Lessons catalog entry + CI controlReference builds teach composition (layout, PDAs, kit client, simulate-then-send, authority). Before/after studies teach evidence (baseline, change, re-measure). Retrospectives teach threat models. The catalog is long-term memory so pitfalls do not return as one-off Slack stories.
The rule: extract principles, re-derive for your constraints, prove with tests and metrics. Copying monorepo folders without re-deriving account checks, fees, and authority is cargo-culting.
Work a reference page in four passes, not one skim.
@solana/kit (or CLI) build, simulate, sign, and confirm? Where do bigint amounts, cluster env, and IDL version show up?Only after those four passes should you open the sibling deep-dive for line-level detail. The reference is the map; other sections own the theory.
Use each reference for a different composition skill:
Do not merge these into one "template app." They share runtime rules, not product graphs.
Before/after pages train measurement discipline.
Numbers illustrate method, not your guarantees. Re-run baselines on your pins (site default: Agave 4.1.1, Anchor 0.32.1, Rust 1.91.1, @solana/kit 7.0.0) before claiming a win.
Retrospectives map exploit classes to Sealevel mechanics: missing signer or owner checks, account substitution, CPI ordering, oracle freshness, privilege concentration. Read them as threat-model prompts:
Public incident class
|
v
Which check was absent or order-wrong?
|
v
Which of our instructions share that shape?
|
v
LiteSVM (or bankrun) test that fails without the fix
|
v
Catalog ID + design-review checkboxUse Security Incident Retrospectives for anatomy and response patterns (pause, snapshot, patch, verify, communicate). Do not treat them as attack tutorials; prevention and regression tests are the product.
The Lessons-Learned Catalog is the index, not a narrative. Each entry should carry severity, area (program / client / ops), a one-line pitfall, a prevention pointer (doc + CI), and a source (incident, audit, date).
Operational habits that make the catalog real:
A practical team loop for a new feature:
That loop is the blueprint. The sibling articles are fuel for steps 1-4; the catalog is step 5's memory.
| Situation | Start with | Then deepen |
|---|---|---|
| New full-stack feature | DeFi program + dApp reference | CU/rent and landing before mainnet load |
| Token or points launch | SPL token launch reference | Authority and ops lessons in catalog |
| Large drop or game inventory | cNFT mint reference | Landing before/after + DAS ops |
ComputationalBudgetExceeded | CU/rent before/after | Hot-path security review after rewrite |
| "Pending forever" support load | Landing before/after | RPC and fee catalog entries |
| Audit or incident | Retrospectives + catalog | Reference re-check of authority and CPI |
Copy this into design reviews; fill it from the case study, not from memory.
Theory sections (accounts, PDAs, security, production troubleshooting, DeFi integrations) own mechanisms. This section owns worked compositions and feedback loops. When a reference mentions pause, ALTs, or mint revoke, follow the linked deep dive for the rule; keep the case study as the end-to-end narrative and measurement story.
Signer or stale blockhash retry returns under a new ticket title.A tutorial teaches a single skill in isolation. A reference build shows a composed path (program, tests, client, ops gates) so you can see where skills meet and which gates are irreversible.
Start here for the learning pattern, then the reference closest to your product (DeFi dApp, token launch, or cNFT). Add before/after and security material before mainnet load or audit.
Keep the account graph, authority policy, and test cases; change only the implementation layer. The CU/rent before/after is the companion for hot-path extraction, not a reason to skip correctness tests.
Land rate to your target commitment, p95 time-to-confirmed per critical route, fee and tip spend, and simulation-pass vs inclusion-fail ratio under peak load.
CU per hot instruction, transaction size, account rent for core PDAs, and regression benches in CI so a later feature does not erase the win.
At least at design-review kickoff for new instruction surfaces, after every incident or audit cycle, and on a quarterly cleanup so severity and owners stay accurate.
No. They improve internal threat modeling and regression coverage. High TVL or custody still needs independent review; catalog entries track remediation from that review.
Solana toolchains and client kits move. A recipe that worked on an older Anchor or kit release can mislead. Re-validate on your pins (this site targets Agave 4.1.1, CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1, @solana/kit 7.0.0).
One reference build end-to-end on devnet or localnet, one before/after method read with a tiny bench, and a walkthrough of five catalog entries tied to signer, CPI, and landing failures.
Timeline, root cause class, blast radius, fix, verification (test id or on-chain proof), and a catalog ID with a prevention control owned by a team.
You can start on cNFT or token launch, but still read landing and security material. Inventory products fail on inclusion, authority, and account checks as often as DeFi does.
They are inclusion tools, not product features. Study them in the landing before/after when land rate or atomic multi-ix flow is part of acceptance criteria.
A concrete guard: Anchor constraint, unit test, CI hash gate, fee floor, multisig policy, or runbook step that would have blocked the pitfall.
You can name your account graph, authority policy, client simulate/send path, CU and landing budgets, security tests for relevant classes, and catalog IDs for residual risks - without referring to the sample product name.
Stack versions: This page was written for Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1, and @solana/kit 7.0.0.
Reviewed by Chris St. John·Last updated Jul 19, 2026