Case Studies Blueprint

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.

Summary

• Treat every case study as a transferable loop: problem frame → account and instruction graph → client and inclusion path → ops and authority gates → measurement → lesson capture - then re-apply that loop to your product with your stack pins.
• Insight: Solana production failures rarely come from "not knowing Rust." They come from incomplete composition: missing signer checks, unmeasured CU, mint authority left live, public RPC on mint day, or lessons that never re-enter design review. Case studies encode those seams in a form you can audit.
• Key Concepts: reference build, before/after, retrospective, lessons catalog, problem frame, account graph, ops gates, measurable outcome, prevention control, stack pins.
• When to Use: Greenfield architecture, onboarding full-stack engineers, audit prep, launch checklists, post-incident design reviews, and choosing depth (reference vs optimization vs security).
• Limitations/Trade-offs: References are simplified; mainnet venues and tree depths change; metrics from one team are not your baselines; retros teach classes of bug, not step-by-step exploit recipes; over-fitting to a sample repo freezes product design.
• Related Topics: DeFi program + dApp, SPL token launch, cNFT mint at scale, CU and rent optimization, reliable landing, security retrospectives, lessons catalog.

Foundations

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:

  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 control

Reference 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.

Mechanics & Interactions

How to read a reference build

Work a reference page in four passes, not one skim.

1. Problem frame. What user intent is on-chain (deposit, mint, launch, inventory at scale)? What is deliberately out of scope (legal, securities, full venue risk)?
2. Account and instruction graph. Which program-owned accounts, mints, ATAs, PDAs, and external programs appear? What must be writable vs read-only?
3. Client path. How does @solana/kit (or CLI) build, simulate, sign, and confirm? Where do bigint amounts, cluster env, and IDL version show up?
4. Ops gates. Multisig upgrade authority, mint/freeze authority policy, RPC plan, explorer verification, release artifact hash.

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.

Reference surfaces in this section

Use each reference for a different composition skill:

• Reference: A DeFi Program + dApp - monorepo, Anchor, LiteSVM, Next.js + kit, pause and deploy authority; keep on-chain state and simulate/send aligned.
• Reference: An SPL Token Launch - mint, metadata, distribution math, authority revocation; irreversible ops gates marketing cannot override.
• Reference: A Compressed-NFT Mint at Scale - tree capacity, Bubblegum, DAS, batching and fees; cost and inventory trade-offs ordinary NFT accounts hide.

Do not merge these into one "template app." They share runtime rules, not product graphs.

How to read a before/after

Before/after pages train measurement discipline.

1. Capture a baseline under a named stack and workload (LiteSVM bench, p95 time-to-confirmed, land rate).
2. Change one subsystem at a time when possible (hot instruction rewrite, fee oracle, ALT, private RPC).
3. Re-measure with the same harness.
4. Keep a regression guard (bench in CI, landing dashboard alert).

• Before/After: Optimizing a Program for CU & Rent - profile first; zero-copy and lighter frameworks only where hot paths justify them.
• Before/After: Making Transactions Land Reliably - landing as a product metric; priority fees, ALTs, confirmation strategy, optional Jito.

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.

How to read security retrospectives

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 checkbox

Use 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.

How to use the lessons catalog

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:

• Open design review with "any catalog hits on this instruction surface?"
• After every audit or near-miss, add or update an ID before closing the ticket.
• Split program, client, and ops lessons so the right owner owns the control.
• Link prevention to a page and an automated check when possible (signer constraint test, IDL hash gate, fee floor on mint routes).

One learning pass across the whole section

A practical team loop for a new feature:

1. Pick the closest reference (DeFi shape, token ops, or scale mint).
2. Fill the four-pass worksheet (frame, accounts, client, ops).
3. Pull CU, rent, and landing expectations from the before/after pages into acceptance criteria.
4. Threat-model with retrospective classes; add failing tests for your paths.
5. Add or tick catalog entries; ship only when prevention controls exist.

That loop is the blueprint. The sibling articles are fuel for steps 1-4; the catalog is step 5's memory.

Advanced Considerations & Applications

Choosing depth by risk

Transfer checklist (use on every study)

Copy this into design reviews; fill it from the case study, not from memory.

• Stack pins: Agave/CLI, Anchor, Rust, kit, IDL hash.
• Account graph: owners, signers, PDAs, mints, external program ids.
• Failure modes: simulate fail, land fail, partial multi-tx, pause.
• Economics: rent, priority fees/tips, tree or account cost model.
• Authority: mint, freeze, upgrade, pause, metadata update.
• Proof: LiteSVM or integration test IDs; explorer or release hash for ops.
• Lesson IDs: new or existing catalog references.

Anti-patterns when using case studies

• Forking a reference monorepo and shipping without re-deriving constraints.
• Treating before/after percentages as SLAs without re-benchmarking.
• Studying exploits without adding a failing test that locks the fix.
• Catalog entries without owners or CI hooks (wiki rot).
• Optimizing CU before the instruction is correct and authorized.
• Planning a 100k mint on public RPC with zero priority fee policy because the happy-path recipe worked on devnet.

How case studies relate to the rest of the site

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.

Common Misconceptions

• "A reference build is a product I should ship." It is a teaching shape. Your market, custody, and compliance constraints still require a full design.
• "If I read every case study once, I am production-ready." Readiness is re-derived graphs, tests, metrics, and catalog controls on your instructions.
• "Before/after numbers transfer across programs." Workloads, account sizes, and congestion differ. Method transfers; raw percentages do not.
• "Security retros are only for auditors." Every engineer who writes an instruction that moves value owns the corresponding failure class.
• "The lessons catalog is optional documentation." Without it, the same missing Signer or stale blockhash retry returns under a new ticket title.
• "Landing and CU are infra topics, not case-study material." On Solana they are user-visible product quality and cost; the before/after pages exist for that reason.
• "cNFT and SPL token launches are the same ops problem." Shared themes (authority, fees, RPC) sit on different account and indexing models; use the matching reference.
• "Client code does not need lessons entries." Float amounts, wrong cluster, IDL drift, and zero priority fee are recurring client failures with the same severity tags as program bugs.

FAQs

Related

• Reference: A DeFi Program + dApp - Anchor program, tests, and kit client composition
• Reference: An SPL Token Launch - mint, metadata, distribution, authority revocation
• Reference: A Compressed-NFT Mint at Scale - trees, Bubblegum, DAS, cost at scale
• Before/After: Optimizing a Program for CU & Rent - measured hot-path and rent reduction
• Before/After: Making Transactions Land Reliably - fees, ALTs, confirmation, optional Jito
• Lessons-Learned Catalog - recurring pitfalls with prevention pointers

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.