solana-dev

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

cluster = "http://127.0.0.1:8899"

// Local — defaults to http://127.0.0.1:8899, includes airdrop

.use(solanaRpcConnection({ rpcUrl: 'http://127.0.0.1:8899' }))

All 28 `surfnet_*` JSON-RPC methods available on the surfnet RPC endpoint (default `http://127.0.0.1:8899`), as of Surfpool v1.6.1. v1.6.0 added the two confidential-balance methods; nothing was remov

curl -X POST http://127.0.0.1:8899 -H "Content-Type: application/json" \

2. Add to PATH: `export PATH="$HOME/.local/share/solana/install/active_release/bin:$PATH"`

run: curl -sL https://run.surfpool.run/ | bash

curl -sL https://run.surfpool.run/ | bash

curl -sL https://run.surfpool.run/ | bash

curl -sL https://run.surfpool.run/ | bash

#       run: curl -sL https://run.surfpool.run/ | bash

Audit 0.4.1 · source sha ed1294b2cb8a · 20 Oct 2026Report an issue or request a re-scan

• Publishersolana-foundation GitHub organizationOwner of the repository this skill is read from
• Source foldersolana-foundation/solana-dev-skill/skills/solana-devThe exact folder we audited
• LicenceMITAs the repository states it
• Commit pinned for this verdicted1294b2cb8aA new audit runs when the source changes
• Repository statusNot archivedLast push 3 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its 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…

---
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, reducing compute units, throughput bottlenecks, instruction naming — and quick on-chain lookups via public RPC + curl (balance, transaction, token account). End-to-end playbook: wallet connection, Anchor/Pinocchio programs, Codama clients, Surfpool/LiteSVM/Mollusk testing, security review, and the v1 transaction format (SIMD-0385, 4096-byte transactions). Prefers @solana/kit 8 plugin clients (createClient + .use()) 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.7.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)
- **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**
- web3.js v3 (`@solana/web3.js@3`, 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. Until npm moves `latest` to 3.x (scheduled for 2026-10-19), a bare `@solana/web3.js` install still resolves to 1.99.0 — pin `@3` explicitly.
- 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.2.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: **Surfpo

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

1. 2026-10-20
   ✓SAFE B 89 / 100

   first audit · source ed1294b2cb8a

Questions about solana-dev

• github.com/solana-foundation/solana-dev-skill/tree/main/skills/s — the audited source at commit ed1294b2cb8a and every finding aboveObserved · 20 Oct 2026

Spotted something wrong? Report a correction · Methodology