/solana-dev

name: solana-dev
description: 'Use when user asks to "build a Solana dapp", "write an Anchor program", "create a token", "debug Solana errors", "set up wallet connection", "test my Solana program", "fuzz my Solana program", "deploy to devnet", "send a v1 transaction", "support larger transactions", "fix maxSupportedTransactionVersion", or "explain Solana concepts" (rent, accounts, PDAs, CPIs). Also for program architecture (state layout, compute units, throughput, naming), quick on-chain lookups via public RPC + curl, gasless or sponsored-fee transactions (Kora), server-side signing with KMS/Turnkey/Privy/Fireblocks (Solana Keychain), and issuing stablecoins or allowlisted tokens (Mosaic). Covers wallets, Anchor/Pinocchio, Codama clients, Surfpool/LiteSVM/Mollusk testing, security review, and v1 transactions (SIMD-0385). Prefers @solana/kit 8 plugin clients building transaction v1 by default, @solana/kit-plugin-wallet + @solana/react for wallets, web3.js v3 as the legacy migration target, and Surfpool for local networks.'
license: MIT
compatibility: Requires Node.js 20.18+, Rust toolchain, Solana CLI, Anchor CLI
metadata:
  author: Solana Foundation
  version: "2.8.0"

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)
• Gasless / sponsored-fee transactions (Kora), server-side signing with KMS / MPC / managed wallets (Solana Keychain), regulated token issuance (Mosaic)
• **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:

  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.

• Server-side signers (backends, bots, agents, treasuries) come from Solana Keychain, not keypair

files: `keychainSigner({ backend: 'aws-kms', ... })` from `@solana/keychain-kit-plugin` in place of `signer()`. See [keychain.md](references/keychain.md).

• 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**

• web3.js v3 (`@solana/web3.js`, 3.0.0 released 2026-10-01) is the classic class-based API rebuilt on Kit internals. Treat it as the migration target for v1 codebases, not a default recommendation for new work. 3.x is now npm `latest`, so a bare `@solana/web3.js` install resolves to it; a codebase that has to stay on 1.x pins `@solana/web3.js@1`.
• 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 m