Directory of the currently-maintained Solana SDK small crates — tells developers which crate to reach for by capability (accounts, crypto, sysvars, serialization, CPI, staking, etc.) and which crates / umbrella patterns to avoid. Use when a user asks "which solana crate do I need for X", "what replaces solana_sdk / solana_program", "is `solana-<foo>` still used", "how do I slim my Cargo.toml", or when reviewing a Cargo.toml that pulls `solana-sdk` / `solana-program` wholesale. Always resolve versions live via `cargo add` rather than hardcoding — this skill is version-free on purpose.
In 2024–2025 the Solana SDK was split from two mega-crates (solana-sdk, solana-program) into ~100 focused, single-purpose crates. Heavy dependencies (serde, borsh, bincode, blake3) became opt-in feature flags. Pulling only what you need slashes compile time and avoids dependency hell.
This skill is a curated directory: which crates to use today, and which to avoid.
Pubkey / Signature / Keypair / Instruction / AccountInfo?"solana-sdk from my Cargo.toml?"solana_program::<foo> still the right import?"Cargo.toml that has solana-sdk = "..." or solana-program = "..." as a top-level dep.Use the narrowest crate that does the job. Avoid the umbrella crates (
solana-sdk,solana-program) in new code — they still build, but they pull everything and defeat the point of the split.
The new crates are thin, feature-gated, and each one compiles independently. A Solana program that only needs AccountInfo, Pubkey, and entrypoint! should depend on three small crates, not on solana-program as a whole.
Route in five seconds by answering three questions.
Q1. On-chain program, or off-chain client / indexer / CLI?
├─ PROGRAM ──────────────────────────┐
│ Q2. Which framework? │
│ ├─ Anchor → frameworks.md §Anchor (production default, largest ecosystem)
│ ├─ Quasar (beta) → frameworks.md §Quasar (Anchor-style macros + near-hand-written CU; unaudited)
│ ├─ Pinocchio → frameworks.md §Pinocchio (CU-sensitive, minimal deps)
│ └─ Native (raw) → frameworks.md §Native + recipes.md "native program"
│ Q3. Need SPL / Token-2022 / ATAs?
│ └─ Yes → spl.md
│
└─ CLIENT / INDEXER / CLI ───────────┐
Q2. What are you doing?
├─ Sign & send txs → recipes.md "client signer"
├─ Read chain state via RPC → catalog.md §Client, RPC & Commitment
├─ Subscribe to live data → catalog.md §Client (solana-pubsub-client / geyser)
├─ Parse transaction / account → catalog.md §Accounts & Keys, §Instructions
└─ Just need one type (Pubkey…) → recipes.md "just parsing"
Q4 (any path). Testing?
└─ LiteSVM / Mollusk / Surfpool / program-test → testing.md
If none of the above match, start at catalog.md and search by capability.
| You want to… | Read |
|---|---|
| Route to the right section fast | the decision flowchart above |
| Pick a crate by capability (accounts, crypto, sysvars, serialization, CPI, staking, RPC, ZK, …) | references/catalog.md |
| Pick an SPL / Token-2022 / ATA / transfer-hook crate | references/spl.md |
| Choose between Anchor / Quasar / Pinocchio / native and see which crates each replaces | references/frameworks.md |
Share zero-copy pod types (PodU64, PodBool, PodVec …) across any framework | references/catalog.md §Framework-agnostic zero-copy utilities |
Choose a testing harness (LiteSVM / Mollusk / Surfpool / solana-program-test) | references/testing.md |
| Know what NOT to depend on and why | references/avoid.md |
See a minimal Cargo.toml for a common scenario | references/recipes.md |
Get a full canonical Cargo.toml template to copy-paste | assets/ |
| Figure out which feature flags to enable | references/feature-flags.md |
Audit an existing Cargo.toml for umbrella / wrong-prefix crates | scripts/audit-cargo.sh <path> |
| Verify a crate name exists on crates.io before recommending | scripts/check-crate.sh <crate> |
This skill is deliberately version-free. Solana crates ship frequently and pinned versions go stale. Every install instruction uses cargo add, which fetches the current version from crates.io:
cargo add solana-pubkey
cargo add solana-clock --features sysvar
cargo add solana-keypair --features seed-derivable
If a user asks for a specific version, point them at cargo search <crate> or <https://crates.io/crates/<crate>>. Do not guess version numbers — they age within weeks.
agave- over solana- for two crates)Two commonly-needed crates exist under both prefixes, but the solana-* versions went stale in mid-2025 while the agave-* versions keep shipping with the Agave validator. Always pick the agave-* one:
agave-feature-set (not solana-feature-set — stale since May 2025)agave-reserved-account-keys (not solana-reserved-account-keys — stale since May 2025)If a user adds solana-feature-set, they'll get an old 2.x that doesn't know about newer feature gates. Redirect them to agave-feature-set. (Run scripts/check-crate.sh on both names to see the date drift for yourself.)
sysvar feature. solana-clock, solana-rent, solana-epoch-schedule, solana-epoch-rewards, solana-slot-hashes, solana-slot-history, solana-last-restart-slot all ship as plain structs by default — you only get the Sysvar trait impl (i.e., the ability to load from inside a program) when you enable features = ["sysvar"].solana-hash. solana-hash only exports the Hash type. The hash, hashv, Hasher, extend_and_hash functions live in solana-sha256-hasher. For blake3 / keccak use solana-blake3-hasher / solana-keccak-hasher.solana-signature does not re-export keypair helpers. The old solana_sdk::signature module re-exported a pile of Keypair-related items. The split removed those. If a user is signing (not just parsing signatures), they almost certainly also need solana-keypair and solana-signer.Run this from the skill root to re-verify every crate name against crates.io and flag any that have gone stale:
find . -type f \( -name '*.md' -o -name '*.toml' \) -print0 \
| xargs -0 cat \
| grep -oE '\b(solana|agave|spl|pinocchio|anchor|mollusk|litesvm|quasar|zeropod)(-[a-z0-9]+)+' \
| sort -u \
| tr '\n' ' ' \
| xargs ./scripts/check-crate.sh \
| grep -E '^(✗|✓)' \
| awk '$1=="✗" || $NF < "updated=2025-04-18"'
Any row in the output is a crate worth investigating: missing (✗) or last updated > 12 months ago. Most Solana-ecosystem crates ship every 1–3 months; a handful (bs58, spl-memo, spl-math, solana-rent-debits) are legitimately stable and rarely updated — don't panic when those appear.
Last full audit: 2026-04-18 — 160/162 recommended crates existed on crates.io. The two exceptions (quasar-metadata, quasar-schema) are unpublished Quasar workspace members mentioned in frameworks.md with that caveat. 98 shipped within the prior week, 52 within the prior year, 3 are legit-stable (>12 mo). zeropod and zeropod-derive shipped v0.1.0 on 2026-04-18 — the day they were decoupled from Quasar for cross-framework reuse.
solana-sdk / solana-program as top-level deps in new code. They still work but pull everything — always propose a focused alternative from catalog.md.catalog.md, run cargo search solana-<term> before recommending. Do not invent names.cargo add so the user gets what's currently published.solana_borsh::deprecated, the v0_10 borsh module) unless the user is explicitly maintaining legacy code that needs them.