T2 · Solana / SVM Engineer
Write integrable programs on a chain that separates code from data entirely.
For Rust and high-performance-chain development.
“T2” here means this track. Linked “Chapter T10” means a course chapter; Chapter T2 covers cryptography fundamentals.
Who This Track Serves
You bring EVM assumptions to Solana. You search for contract storage and cannot explain the byte-level difference between a PDA and ordinary account.
You write Rust but lack safe account validation. Borrowing and macros are familiar, but instruction checks rely on attributes you do not understand or hand-written require checks whose omissions you cannot identify.
Devnet works while mainnet behaves unexpectedly. Sporadic failures, inadequate rent, duplicate requests, and insufficient account space never appeared locally.
Your program is not usable by others. Integration requires reading Rust to guess account order because only a test script exists, with no client SDK.
The dividing line: deliver a program callable correctly without reading its source.
Prerequisites
All Part B chapters are ideal. The Knowledge Graph's shortest starting path is:
- Chapters T1–T3
- Chapter T4
- Chapter T5
- Chapter T6
- Chapter T10
- Chapter T11
| Required reading | Graph rationale |
|---|---|
| Chapter T1 through Chapter T3 | Chain-independent state, signatures, lifecycle |
| Chapter T4 · RPC | T5 prerequisite; throughput amplifies rate limits and completeness issues |
| Chapter T5 · EVM Account Model | Direct T6 prerequisite—not a typo. Establish an account/state reference before examining separation |
| Chapter T6 · Solana Account Model | Programs do not store data; transactions declare touched accounts |
| Chapter T10 · Solana Program | Depends on T6; implement PDA and CPI |
| Chapter T11 · Token Program | Depends on T10; shared code and separate accounts enable composition |
| Chapter T13 → Chapter T17 | Needed only for indexing; its dependency chain returns to T9 |
What You Will Learn
- Rust
- Anchor
- PDA
- CPI
- Token-2022
- Indexer
- DeFi
Seven topics form four groups.
1. Rust and Frameworks: Account Validation Is the Hard Part
Focus on understanding checks generated by attribute macros: signer, writable status, expected owner, PDA seeds, and account space.
Missing generated checks become your responsibility. For every instruction, count checks, explain their protection, and demonstrate exploitation if omitted.
Implement an instruction entry without a framework once. This inexpensive exercise removes the macro black box.
2. PDA and CPI: Address Space and External Calls
Understand seed design and preemption, canonical bumps, and program signing authority. Serious failures often trace to assuming only your program could write an account.
For outgoing CPI, verify the target program; for incoming calls, prevent unintended authority propagation. Design for call-depth and account-passing limits before implementation stalls.
3. Token-2022 and Integration: Coexisting with Extensions
Extensions invalidate assumptions: transfers may invoke hooks, collect fees, freeze, or store metadata in mint accounts. Simple balance-addition assumptions misaccount extended tokens.
List every implicit token assumption and identify extensions that invalidate it.
4. Indexers and DeFi: Queryable Chain Activity
Solana differs from EVM logs; reconstruct meaning through instructions, inner instructions, and account changes. Chapter T17's reorganizations, resumability, and idempotency still apply.
Building a protocol belongs to Track T4; here DeFi focuses on correct integration: understand account layouts, calculate swap outputs, and handle execution failure.
Final Deliverable
A mainnet Anchor program with client SDK.
The Capstone Project covers a whole system; this requires one program others can use correctly. The SDK turns finished code into usable work.
Others can run it. One command installs dependencies; another runs local-validator tests. Specify toolchain versions because version sensitivity otherwise prevents reproduction.
Include a primary SDK-call example of no more than twenty lines.
The SDK hides account ordering. Users supply business parameters; it derives PDAs, assembles accounts, handles existing associated accounts, and estimates rent.
An unfamiliar developer must succeed from SDK types alone. Asking what account three means fails this criterion.
Every validation has a deliberate failure test. List checks and supply incorrect accounts that must cause failure.
Happy-path-only tests prove no safety properties.
Design failures and retries deliberately. Cover existing accounts, insufficient rent, insufficient space, duplicate requests, and expired transactions.
For each, define retry, error, or idempotent success on the SDK side.
Use small mainnet amounts and explain upgrades and shutdown. Use affordable personal funds. Specify upgrade authority, intended transfer or destruction, and stopping procedures.
Devnet delivery with reasons to defer mainnet is equally acceptable.
Assess Your Readiness
The runtime identifies conflicts before executing and parallelizes disjoint read/write sets.
Clients must derive all accounts, including PDAs and associated accounts. That makes the client SDK mandatory: account derivation is part of the program, running offchain.
Derived from program ID and seeds, it is deliberately off the elliptic curve, with no corresponding private key.
Derivation tries decreasing bump values until finding an off-curve address. The runtime permits the deriving program to supply seeds and bump during CPI and sign as that address.
Seeds determine control, and canonical bumps prevent one seed set mapping to multiple accepted addresses.
Missing owner checks accept attacker-created accounts with matching layouts and forged values.
Missing signer checks let others act on a user's account.
Missing relationship checks accept individually valid position and vault accounts from different markets, settling market A's position in market B.
The third is hardest to detect. Encode relationships into PDA seeds.
Transfer fees mean sending 100 delivers less, with the remainder withheld as fees; requested-amount accounting fails.
Hooks invoke another program, potentially failing or changing unexpected state and introducing ordering risks.
Freeze authority and default-frozen states can reject valid transfers; workflows must tolerate them.
Use actual before-and-after balances rather than requested amounts, as on EVM.
Check:
- Are account order, seed rules, and errors encoded in SDK types rather than comments or memory?
- Can failure causes be found without reading source?
- Could upgrades silently replace logic for integrators? An unclear answer means authority is not managed as an asset.
Common Mistakes
“Working on Devnet Means Mainnet-Ready”
Congestion, RPC behavior, and rent differ. Mainnet transactions may expire, wait with inadequate priority fees, or report unexpected confirmation status.
Assume confirmation may never happen. Design explicit polling and resending rather than treating broadcast as success.
“Frameworks Handle All Validation”
They generate declared checks rather than needed checks. Missing attributes do not trigger compiler warnings.
Maintain an independent list, verify implementation, and add wrong-account tests as its executable form.
“Any PDA Seeds Will Do”
Seeds define authority. Missing dimensions merge objects that should be isolated; unconstrained user inputs permit preemption.
Define the represented object and who can create it, then derive seeds, including ownership relationships that prevent wrong-account derivation.
“No Solana Reentrancy Means Order Is Irrelevant”
Absence of EVM-style callbacks does not eliminate ordering risks. CPI and hooks hand execution to others while accounts may be intermediate.
Apply Chapter T28: finish your accounting before interacting externally. The chain changes; the rule remains.
Next Steps
- Reread with your program: Chapter T6, Chapter T10, Chapter T11.
- For indexing, complete Chapter T16 and Chapter T17, then Track T3 · Onchain Data Engineer.
- Combine Track T4 · DeFi Engineer for trading programs and Track T5 · Security Engineer for professional validation.
- Cross into Track N4 · Crypto BD & Ecosystem. SDKs solve the technical half of integration; the other half lives there.
- Expand to a complete system through the Capstone Project.