Team Onboarding Key Points
Hiring or rotating engineers onto a Solana product fails most often from a scrambled ramp: keys before concepts, clients before accounts, or mainnet before a security review habit. A good path is ordered, version-pinned, and gated. New teammates learn how the chain works, prove a full loop on local and devnet tooling, then adopt review and release rules before production authorities.
This page is the conceptual map for Team Onboarding - ramping Solana developers, fitting environment setup and the Solana Mental Model Ramp into the first weeks, proving readiness with a first program and dApp, setting the bar with code review guidelines, and using checklist concepts so the path is repeatable on Agave 4.1.1 with Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1, and @solana/kit 7.0.0.
Summary
- Solana team onboarding is a staged ramp: grant safe access, pin the toolchain, teach the account-first execution model, ship a tiny program-plus-client on devnet, then practice security-first code review and team release habits before mainnet keys or upgrade authority work.
- Insight: Solana mistakes are asymmetric. A missing signer or owner check can drain funds; toolchain drift burns weeks; starting from EVM or pure frontend habits without a concept order produces false confidence. Structured onboarding is risk control, not HR ceremony.
- Key Concepts: buddy and access stages, version pins, Environment Setup Checklist, Solana Mental Model Ramp, First Program & dApp, Code Review Guidelines, Onboarding Devs Checklist, devnet and local only, LiteSVM / Surfpool, mainnet key gates.
- When to Use This Model: First two weeks for Solana hires, contractors, frontend engineers joining a program team, Rust engineers new to Sealevel, or re-onboarding after leave when CLI and Anchor have moved.
- Limitations/Trade-offs: Fixed order is slower than "clone and hotfix" on day one. That trade-off is intentional: speed without account-validation literacy and review culture is expensive later. Role shortcuts exist, but security and cluster discipline still apply.
- Related Topics: Onboarding Devs Checklist, Environment Setup Checklist, The Solana Mental-Model Ramp, First Program & dApp, Code Review Guidelines.
Foundations
Onboarding Solana developers is not "install Rust and open the monorepo." It builds three competencies together:
- Runtime literacy - accounts hold state, programs are executables, transactions declare account metas, PDAs and CPIs compose systems, compute units and fees meter and schedule work.
- Toolchain fluency - the same Agave tools, Anchor version, and client SDK that CI uses, plus a local validator or LiteSVM path for fast feedback.
- Team safety - how this org reviews PRs, stores keys, names program IDs, regenerates IDLs, and promotes from devnet to mainnet.
Without (1), constraints look right and fail under adversarial accounts. Without (2), "works on my machine" fights CI. Without (3), strong individuals still ship the wrong cluster config or skip negative tests.
Sibling pages split the work:
| Sibling page | Job in the ramp | Typical timing |
|---|---|---|
| Environment Setup Checklist | Verify Rust, Agave/CLI, Anchor, Node, local validator | Days 1-2 |
| The Solana Mental-Model Ramp | Ordered concepts and exercises before production code | Days 2-5 |
| First Program & dApp | Capstone: Anchor program + @solana/kit client on devnet | Days 5-10 |
| Code Review Guidelines | What "merge-ready" means for program and client PRs | Week 1 PR + week 2 shadow |
| Onboarding Devs Checklist | Two-week orchestration and buddy gates | Whole ramp |
Access before authority. Week 0 includes git, CI logs, docs, a vault for dev secrets, and devnet RPC. It excludes mainnet deploy keys, upgrade authorities, and shared production wallets.
Version pins are onboarding. Match Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1 (anchor-lang 0.32.1), Rust 1.91.1, @solana/kit 7.0.0, plus Surfpool 0.12.0 and LiteSVM 0.6.x for local realism and unit tests. Align with rust-toolchain.toml, Anchor.toml, and CI so build failures are real bugs, not version puzzles.
Buddy model. Assign a buddy for the first five working days for PATH issues, first PR feedback, and two sign-offs: end of week 1 (small program PR) and end of week 2 (capstone demo plus review shadow). Async teams replace hallway questions with written checklists and a recorded First Program & dApp walkthrough.
Mechanics & Interactions
Onboarding is a pipeline. Each stage has an exit condition before broader write access.
Week 0 Access & orientation
| git, CI read, docs, devnet faucet, no mainnet keys
v
Week 1 Toolchain + concepts + tiny program change
| env green -> concept ramp -> LiteSVM tests -> first PR
v
Week 2 Client, capstone, review culture, team practices
| kit client -> verifiable build awareness -> shadow review -> demo
v
Gate Buddy sign-off (checklist + security habits)
v
Eligible for broader write / mainnet-adjacent work (org policy)Environment setup
The Environment Setup Checklist proves a laptop can build what CI builds:
- Rust 1.91.1;
cargo build-sbf, fmt, and clippy available. - Solana CLI 3.0.10 on Agave 4.1.1; default cluster devnet.
- Anchor via
avmat 0.32.1, matching templateanchor-lang. - Node/TypeScript path for @solana/kit 7.0.0 clients.
- Local validator or team Surfpool/LiteSVM path; devnet airdrop and balance.
- Editor types (rust-analyzer) so constraints are readable in context.
Exit: versions print correctly, template anchor build succeeds, repo tests green. Record shell and Apple Silicon quirks in the team runbook.
Concept order
Before feature work on shared programs, walk the Solana Mental Model Ramp: accounts and ownership, programs as executables, instructions and signers, transactions and blockhashes, PDAs (seeds and bumps), CPIs and validation, compute units and priority fees, then clients (@solana/kit / CLI).
Later topics assume earlier ones. Wallet UI or IDL codegen first produces engineers who send transactions they cannot explain. Pair CLI exercises (solana account, transfer, solana confirm -v) with Anchor account structs.
Exit: buddy can ask who signs, who pays rent, where state lives, and why an account is writable, and get accurate answers for a simple instruction.
First program and dApp
The First Program & dApp path is integration proof: team template or anchor init, build and test, deploy to devnet, then a minimal @solana/kit 7.0.0 client that reads and writes state. Expect one to two focused days after the concept ramp.
This stage forces IDL/client sync, program IDs and cluster URLs in env tables, normal use of simulation and logs, and the same deploy path used later without mainnet blast radius.
Exit: devnet program id in the team registry, tests for a happy path and at least one negative case, short demo of the PDA or account layout.
Code review guidelines
From the first PR, Solana review order differs from general web review. Style later; first pass:
- Account list and constraints (or manual equivalents).
- Signer and writable flags.
- Owner and program id checks.
- PDA seeds and canonical bumps.
- Arithmetic and token amounts.
- CPI targets and privilege escalation.
- Compute unit and log noise.
- Tests (LiteSVM 0.6.x plus negatives).
- IDL and client impact.
Onboarding includes a small instruction change and shadowing a security-sensitive review. Engineers learn blockers: missing vault authority seeds, mint mismatches, unchecked remaining accounts, silent IDL drift.
Checklist concepts
The Onboarding Devs Checklist turns the path into numbered week buckets:
- Week 0 - access, basics reading, dev vault and RPC, clone, green tests.
- Week 1 - env checklist, no mainnet, template program, concept ramp, tiny change + PR, log debugging.
- Week 2 - kit or AnchorPy client, First Program & dApp, verifiable build once, program id registry, review shadow, team practices, Surfpool/test-validator habit, PDA demo.
Concepts managers and buddies enforce:
- Chronological order - do not skip security and testing to catch up on features.
- Cluster discipline - local and devnet until buddy sign-off.
- Evidence - version output, green tests, PR links, and a demo beat verbal "I'm good."
- Role variants - frontend hires still complete concept and client sections; deepen program items less. Contractors get time-boxed access and key revocation after the demo.
- Re-onboarding - after leave, re-run toolchain, a small tested change, client codegen, and verifiable build because toolchains drift.
Advanced Considerations & Applications
Role-shaped ramps
| Role | Emphasize | Lighten (do not delete) | Gate still required |
|---|---|---|---|
| On-chain / full-stack | Full concept ramp, Anchor, LiteSVM negatives, review order | Deep frontend design systems | Through security review shadow |
| Frontend / product UI | Accounts, txs, wallets, kit signing, cluster match | Native entrypoint internals | Concept stages for accounts/signers + client capstone |
| Backend / indexers | Accounts, events/IDL, RPC correctness | Priority-fee micro-tuning | No mainnet keys until data path validated |
| Contractor | Scoped repo, revocable keys, checklist subset | Long-term ownership docs | Demo + revoke schedule |
| Experienced Rust, new to Solana | Concept ramp + validation culture | Basic Rust drills | No mainnet until review habits shown |
Org size and readiness signals
Small teams still need version pins, a review order, and a mainnet key gate; they can collapse ceremony to one buddy, one checklist, one starter template. Larger teams add CODEOWNERS per program, a security lane for token-moving changes, and a written upgrade-authority runbook. Agencies should split ownership early: agency owns toolchain and templates; client owns production keys, program id registry, and mainnet promotion.
Objective readiness signals:
- Toolchain versions match CI pins.
- Can explain ownership and a PDA used in the first program.
- Can land a small program PR with negative tests.
- Can read a failed simulation or
solana confirm -vlog with a peer. - Has shadowed a review focused on signers, owners, and CPI.
- Capstone client talks to the hire's own devnet program id.
Failure criteria to extend week 1: cannot explain where state lives, or cannot deploy and call a simple program on devnet. Do not paper over that with more UI tickets.
After the two-week ramp, standing team practices take over: CI build and test on every PR, no silent IDL drift, separate keys per environment, verifiable builds and soak before mainnet. Teach when LiteSVM 0.6.x (fast units) versus Surfpool 0.12.0 or fork tests (mainnet-like state) apply so later incidents do not invent process from scratch.
Common Misconceptions
- "Strong generalists do not need a Solana-specific ramp." Account locks, PDAs, and owner checks are not portable from typical CRUD backends.
- "Day-one mainnet access proves trust." Trust is green tests, good reviews, and cluster discipline. Mainnet keys are a privilege after gates.
- "Environment setup is optional if Docker worked once." Local version drift still breaks
anchor build, sBPF targets, and client codegen. - "The concept ramp is only for juniors." Senior EVM or backend hires often need it most because prior models mislead (contracts as storage, implicit account discovery).
- "First Program & dApp is busywork if a monorepo exists." The capstone proves this hire can deploy, register a program id, and wire kit under your CI and secrets layout.
- "Code review is style and coverage percentage." For programs, missing constraints and bad CPI authority dominate risk.
- "Checklists are compliance theater." A chronological checklist with buddy sign-off enforces order and mainnet gates under product pressure.
- "Frontend hires can skip accounts." They still choose writable accounts, fee payers, and clusters.
- "Matching Anchor major version is enough." Patch pins (0.32.1 vs older lines) and kit majors matter for IDL shape and APIs.
- "Once onboarded, never re-run setup." After OS upgrades, leave, or toolchain bumps, re-verify versions and rebuild.
FAQs
How long should full Solana onboarding take?
About two weeks with buddy support. Experienced Rust engineers often reach the client capstone in 5-7 days but should still finish security review items before mainnet eligibility.
What is the highest-leverage first week activity?
Environment setup against pinned versions, then the Solana Mental Model Ramp with CLI exercises before large feature PRs. Toolchain plus account literacy unblock everything else.
When may a new hire touch mainnet keys?
After buddy sign-off on checklist items through security and team practices (typically end of week 2), plus any org security training. Until then: local and devnet only.
How should frontend-only hires use this section?
Keep access, client-focused env, concept stages for accounts/transactions/signers, kit client work, and review habits for client PRs. Lighten deep native program items; never skip cluster discipline or signing safety.
Why require First Program & dApp if the product already exists?
It proves the full safe-cluster loop: build, test, deploy, client read/write, program id registry, and log debugging. A monorepo tour alone does not prove deploy and IDL fluency.
What does a good first PR look like?
A small instruction or account-field change with LiteSVM or anchor test coverage, including at least one negative case, reviewed under Code Review Guidelines with security checks before style.
How do we handle contractors?
Time-box repo and vault access, keep them on devnet keys, apply the same review bar for program code, and revoke credentials after the week-2 demo or engagement end.
Which local testing tools should onboarding introduce?
LiteSVM 0.6.x for fast unit tests, anchor test / test-validator for integration, and Surfpool 0.12.0 when mainnet-like account state matters. Document the pyramid in the repo README.
How do version pins interact with personal laptop setups?
Personal tools may exist, but project work follows rust-toolchain.toml, Anchor 0.32.1 via avm, CLI 3.0.10, and the repo kit version. CI wins when versions disagree.
What manager checkpoints matter?
End of week 1: first PR ready, env and concept ramp done. End of week 2: capstone demo, review shadow, checklist sign-off. Escalate early if exit conditions slip.
Is an official Solana certification required?
No. Buddy sign-off on the Onboarding Devs Checklist plus demonstrated review habits is the practical standard for most teams.
What should we update when stack versions change?
Bump pins in toolchain files and CI, refresh Environment Setup Checklist commands, re-run smoke anchor build and kit typecheck, and require engineers to re-verify versions on next onboarding or quarterly hygiene.
Related
- Onboarding Devs Checklist - chronological two-week ramp and buddy gates
- Environment Setup Checklist - Rust, Agave/CLI, Anchor, and local validator install
- The Solana Mental-Model Ramp - concept order before production program work
- First Program & dApp - guided Anchor program plus kit client on devnet
- Code Review Guidelines - security-first PR review order for Solana code
Stack versions: This page was written for Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0, and LiteSVM 0.6.x.