Solana Dev

# Solana Development Skill

## What this Skill is for Use this Skill when the user asks for: - Solana dApp UI work (React / Next.js) - Wallet connection + signing flows - Transaction building / sending / confirmation UX - Transaction v1 / larger transactions (SIMD-0385) — the default format for new code; sending, reading, indexing - On-chain program development (Anchor or Pinocchio) - Program architecture — state layout, PDA seed conventions, naming, parallelization, cranks, vault topology - Client SDK generation (typed program clients) - Local testing (Surfpool, LiteSVM, Mollusk) and fuzz testing (Trident, cargo-fuzz) - Security hardening and audit-style reviews - Confidential transfers (Token-2022 ZK extension) - **Toolchain setup, version mismatches, GLIBC errors, dependency conflicts** - **Upgrading Anchor/Solana CLI versions, migration between versions** - **Migrating web3.js v1 code to web3.js v3 or Kit**

## Default stack decisions (opinionated)

1) **SDK: @solana/kit 8 plugin clients, transaction v1 by default** - Build clients with `createClient()` from `@solana/kit`, then `.use(...)` plugins. Pass `transactionConfig: { version: 1 }` to the RPC plugin so every transaction the client plans is v1: ```ts createClient() .use(signer(mySigner)) .use(solanaRpc({ rpcUrl, transactionConfig: { version: 1, priorityFeeLamports: lamports(5_000n) } })); // or solanaLocalRpc / solanaDevnetRpc / solanaMainnetRpc from @solana/kit-plugin-rpc ``` - **Transaction v1 is the default for new code**. Set `version: 1`; the planner otherwise defaults to v0. Plugin clients estimate compute and loaded-accounts-data limits by simulation. On manual pipelines, use Kit's resource-estimation helpers instead of guessing limits; use fixed values only for measured overrides or deliberate caps. See [transactions-v1.md](references/transactions-v1.md). - Manual `pipe()` + `createTransactionMessage({ version: 1 })` is the low-level alternative for when you need control over every step (custom lifetimes, offline signing, bespoke planners) — see [kit/advanced.md](references/kit/advanced.md). It is not the default path. - Default to `signer()` / `signerFromFile()` / `generatedSigner()` from `@solana/kit-plugin-signer` — they set both `payer` and `identity` to the same keypair (the common case). For fresh local/devnet signers, install the RPC/LiteSVM plugin after `generatedSigner()`, then fund with `airdropSigner(...)`. Reach for the role-specific variants (`payer()` + `identity()`) only when fees and authority must come from different keypairs. - Use `@solana-program/*` program plugins (e.g., `tokenProgram()`) for fluent instruction APIs. - Prefer Kit types (`Address`, `Signer`, transaction message APIs, codecs).

2) **UI: Kit plugin client + @solana/react** - Wallet connection via `walletSigner()` from `@solana/kit-plugin-wallet` (Wallet Standard discovery; the connected wallet fills the payer/identity roles), with React hooks from `@solana/kit-plugin-wallet/react`. - Before sending v1 from a wallet-backed client, check `connected.supportedTransactionVersions.has(1)` (from `client.wallet.getState()` or `useConnectedWallet`). Wallets that have not shipped v1 reject the signing request; fall back to a `version: 0` client for them — see [frontend.md](references/frontend.md#wallet-connection). - Client bindings via `@solana/react` 8 (`ClientProvider`, typed `useClient<AppClient>`, data hooks, SWR/TanStack adapters). Its legacy Wallet Standard hooks are being deprecated — don't use them. - Do **not** use `@solana/client` / `@solana/react-hooks` (framework-kit) or `@solana/wallet-adapter-*` for new work.

3) **Legacy compatibility: web3.js v3 (RC)** - web3.js v3 (`@solana/web3.js@rc`) is the classic class-based API rebuilt on Kit internals. It is still a release candidate — treat it as the migration target for v1 codebases, not a default recommendation for new work. - Migrating a v1 codebase: use the official migration skill from the solana-web3.js repo rather than hand-migrating — see [kit-web3-interop.md](references/kit-web3-interop.md) for routing. - Do not introduce `@solana/web3-compat` in new work — it is superseded. - Do not let legacy class types leak across the entire app; contain them to adapter modules.

4) **Programs** - Default: Anchor 1.1.x (fast iteration, IDL generation, mature tooling). - Performance/footprint: Pinocchio (0.11+) when you need CU optimization, minimal binary size, zero dependencies, or fine-grained control over parsing/allocations.

5) **Testing (Surfpool-centered)** - Unit tests: LiteSVM (in-process, Rust/TS) or Mollusk (Rust instruction harness). - Integration tests: **Surfpool** — mainnet forking with lazy account cloning, 26 `surfnet_*` cheatcodes (time travel, account/token state, oracle scenarios, CU profiling), embeddable in-process via the `@solana/surfpool` SDK, and the default `anchor test` runner in Anchor 1.0+. - In TypeScript, boot the surfnet through the Kit plugin: `await