If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/solana-labs/solana-program-library shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• 12 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 1y ago
• ⚠ Concentrated ownership — top contributor handles 63% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live solana-labs/solana-program-library repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/solana-labs/solana-program-library.

What it runs against: a local clone of solana-labs/solana-program-library — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in solana-labs/solana-program-library | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 453 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of solana-labs/solana-program-library. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/solana-labs/solana-program-library.git
#   cd solana-program-library
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of solana-labs/solana-program-library and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "solana-labs/solana-program-library(\\.git)?\\b" \\
  && ok "origin remote is solana-labs/solana-program-library" \\
  || miss "origin remote is not solana-labs/solana-program-library (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "account-compression/programs/account-compression/src/lib.rs" \\
  && ok "account-compression/programs/account-compression/src/lib.rs" \\
  || miss "missing critical file: account-compression/programs/account-compression/src/lib.rs"
test -f "account-compression/programs/account-compression/src/state/concurrent_merkle_tree_header.rs" \\
  && ok "account-compression/programs/account-compression/src/state/concurrent_merkle_tree_header.rs" \\
  || miss "missing critical file: account-compression/programs/account-compression/src/state/concurrent_merkle_tree_header.rs"
test -f "account-compression/sdk/src/index.ts" \\
  && ok "account-compression/sdk/src/index.ts" \\
  || miss "missing critical file: account-compression/sdk/src/index.ts"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 453 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~423d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/solana-labs/solana-program-library"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

The Solana Program Library (SPL) is a monorepo of on-chain Solana programs and their TypeScript/Rust clients, targeting the Sealevel parallel runtime. It includes programs for token operations, governance, token lending/swapping, and account compression—key primitives deployed to Solana Mainnet Beta. Most programs have migrated to separate repos under solana-program organization, but this archive maintains reference implementations and hosts active programs like governance, token-lending, token-swap, and account-compression. Multi-program monorepo: top-level Cargo.toml workspace includes ~15 programs (governance/program, token-lending/program, token-swap/program, account-compression/programs/account-compression, etc.), each with its own Cargo.toml. TypeScript clients live alongside programs (e.g., token-lending/cli). Examples in examples/rust/ show cross-program invocation patterns. Libraries in libraries/ (concurrent-merkle-tree, math) are shared dependencies.

Solana smart contract developers and protocol engineers building financial primitives (DEXes, lending protocols, governance DAOs) who need battle-tested, audited on-chain program implementations and their JS/Rust client libraries. Also used by Solana Labs maintainers and community contributors extending the SPL ecosystem.

Actively maintained but in transition: the repo is archived as a reference, with core programs migrated to dedicated repos (token, token-2022, stake-pool moved to solana-program org). Remaining programs like account-compression, governance, and token-lending show recent CI workflows and test coverage. Production-ready for governance and account-compression; legacy status for programs awaiting full migration.

Migration risk: the monorepo structure is being dismantled, so contributing here requires checking if your target program has already moved to solana-program/. Dependency complexity is high (Cargo.lock, curve25519-dalek pinning with opt-level=3 workaround suggests perf-sensitive crypto). CI is fragmented across 20+ workflow files (pull-request-governance.yml, pull-request-token-lending.yml, etc.), increasing risk of skipped tests if you modify cross-cutting code.

Active work on account-compression (concurrent merkle tree implementation with canopy.rs, concurrent_tree_wrapper.rs), governance programs, and token-lending. Dependabot is configured (.github/dependabot.yml) and nightly fuzzing runs (fuzz-nightly.yml). Program-specific PR workflows trigger based on changed paths, indicating maintenance mode with isolated updates per program.

git clone https://github.com/solana-labs/solana-program-library && cd solana-program-library && cargo build --workspace (builds all programs). For a specific program like token-lending: cd token-lending/program && cargo build. Install Solana CLI (solana-labs/solana) and Anchor (coral-xyz/anchor) as prereqs.

Daily commands: No dev server—this is on-chain code. For local testing: solana-test-validator (runs local cluster), then cargo test --lib to run unit tests per program. Example: cd account-compression/programs/account-compression && cargo test. TypeScript tests: npm install && npm test (see .npmrc for registry config).

• Cargo.toml — Root workspace manifest defining all member packages and shared dependencies across the entire SPL repository
• account-compression/programs/account-compression/src/lib.rs — Entry point for the account compression program, the primary maintained implementation in this archived repo
• account-compression/programs/account-compression/src/state/concurrent_merkle_tree_header.rs — Core state structure for concurrent merkle tree accounts, fundamental to the compression program's data model
• account-compression/sdk/src/index.ts — TypeScript SDK export point providing client-side interfaces for interacting with the compression program
• README.md — Documents the archived status of the repo and lists all migrated packages, essential context for understanding the codebase scope
• .github/workflows/pull-request.yml — Primary CI/CD pipeline defining test and build requirements for all contributions
• account-compression/programs/account-compression/src/concurrent_tree_wrapper.rs — Wrapper abstraction around concurrent merkle tree operations, critical for understanding tree mutation safety

• Concurrent Merkle Tree Program — Maintains tree state on-chain, validates proofs, applies leaf mutations, ensures changelog

Add a new instruction to the account compression program

1. Define the instruction enum variant and context struct in the program (account-compression/programs/account-compression/src/lib.rs)
2. Implement the instruction logic handler, updating program state and emitting events (account-compression/programs/account-compression/src/lib.rs)
3. Generate TypeScript instruction builder by running anchor build or idl-generation in the SDK (account-compression/sdk/src/generated/instructions/index.ts)
4. Export the new instruction from the SDK index (account-compression/sdk/src/index.ts)
5. Add tests in the program's integration test suite (account-compression/programs/account-compression/src/lib.rs)

Add a new event type to track state changes

1. Define the event struct with proper attributes in the events module (account-compression/programs/account-compression/src/events/mod.rs)
2. Emit the event in the relevant instruction handler using emit!() macro (account-compression/programs/account-compression/src/lib.rs)
3. Generate TypeScript event type definitions via Anchor IDL (account-compression/sdk/src/generated/types/index.ts)
4. Add event parsing logic in the SDK (account-compression/sdk/src/events/index.ts)

Modify merkle tree state structure

1. Update the account state struct in the state module (account-compression/programs/account-compression/src/state/concurrent_merkle_tree_header.rs)
2. Update the concurrent tree wrapper if mutation logic needs changes (account-compression/programs/account-compression/src/concurrent_tree_wrapper.rs)
3. Regenerate TypeScript types from the Anchor IDL (account-compression/sdk/src/generated/types/ConcurrentMerkleTreeHeader.ts)
4. Update the SDK account decoder to reflect new fields (account-compression/sdk/src/accounts/ConcurrentMerkleTreeAccount.ts)
5. Add migration logic or document breaking changes (account-compression/programs/account-compression/README.md)

• Solana Program (Rust) — On-chain program execution for merkle tree operations with Anchor framework for instruction handling and state management
• Anchor Framework — Abstracts Solana program boilerplate, provides IDL generation for TypeScript SDK, and manages account serialization
• TypeScript SDK — Enables client-side transaction building, account decoding, and off-chain merkle tree utilities for proof generation
• Concurrent Merkle Tree — Allows safe parallel transactions against the tree with changelog-based rollback semantics for atomicity
• Canopy Caching — Reduces on-chain proof verification costs by storing intermediate tree nodes as account data

• Archive existing implementations and move to per-package repositories

  • Why: Reduce monorepo complexity, enable independent versioning and release cycles for each program
  • Consequence: Developers must now navigate multiple repositories; this repo serves only as historical reference for account-compression and noop programs

• Use zero-copy deserialization for state structs

  • Why: Minimize memory allocation and improve performance in constrained Solana compute budgets
  • Consequence: State mutations require careful coordination and cannot use standard Rust borrowing patterns; requires unsafe code in the concurrent wrapper

• Emit events rather than store full history on-chain

  • Why: Reduce account size and operational cost while maintaining auditability via blockchain indexers
  • Consequence: Requires off-chain event parsing infrastructure; not suitable for purely on-chain history queries

• Does not provide authentication or authorization beyond Solana's account ownership model
• Does not handle token swaps, lending, governance, or other financial primitives (those were moved to separate repos)
• Does not support real-time state queries; queries happen via RPC or off-chain indexing
• Not a production token implementation; account-compression is experimental and designed for reference

curve25519-dalek slow SIMD backend: dev/test builds force opt-level=3 in Cargo.toml to avoid 400ms+ slowdown in solana-test-validator ZK proof verification. Program-specific CI: each program has its own workflow (pull-request-token-lending.yml, etc.), so changes to shared libraries may not trigger all tests—manually run cargo test --workspace. Anchor.toml present at root and in account-compression/, suggesting mixed Anchor+native programs; Anchor IDLs may not auto-generate for non-Anchor programs. No .env.example; check individual program READMEs for config (e.g., RPC endpoints for CLI tools).

• Program Derived Addresses (PDA) — PDAs are used throughout SPL programs (governance, token-lending) to derive deterministic account addresses from program seeds, enabling secure cross-program invocation and account ownership guarantees without private keys.
• Concurrent Merkle Tree with Canopy — The account-compression program uses concurrent merkle trees with a canopy cache layer to enable O(log n) state compression and parallel updates; critical for scaling NFT collections and on-chain proofs.
• Cross-Program Invocation (CPI) — SPL programs use CPI extensively (token-lending calls token program, governance calls voting program) to compose on-chain logic; essential pattern for understanding program dependencies.
• Sealevel Parallel Runtime — SPL programs are designed for Sealevel, which enables parallel transaction processing via read/write set analysis; affects account access patterns and concurrency design in programs like concurrent merkle tree.
• Interest Accrual and Reserve Accounts — The token-lending program demonstrates how on-chain interest is calculated and accrued without callbacks; important for understanding financial protocol implementation constraints on Solana.
• Account Versioning and State Layout — SPL uses account versioning (see governance/program state structures) to handle upgrades safely; critical for avoiding deserialization errors when account schemas change.
• Zero-Knowledge Proof Integration — The curve25519-dalek SIMD backend optimization in Cargo.toml hints at ZK proof verification in solana-test-validator; used by governance for vote anonymity and account-compression for proof validation.

• solana-program/token — The Token program (SPL token standard) migrated here; essential for understanding how token mints and accounts are managed in Solana.
• solana-program/token-2022 — Enhanced token standard with transfer hooks and extensions; shows evolution of on-chain token logic from SPL Token v3.
• solana-labs/solana — Core Solana runtime (Sealevel) and solana-program crate dependency; programs here target this runtime and use its syscalls.
• coral-xyz/anchor — Framework used by governance and other programs in this repo for ergonomic program development; IDL generation for client codegen.
• Mythic-Project/solana-program-library — Governance programs (not in this archived repo) have moved here; fork to check latest governance implementation if updating vote logic.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add missing CI workflow for account-compression SDK TypeScript tests

The repo has comprehensive CI workflows for individual programs (pull-request-token-swap.yml, pull-request-governance.yml, etc.) but account-compression/sdk lacks a dedicated workflow. The SDK has TypeScript source code and a jest.config.js, indicating test infrastructure exists but isn't being run in CI. This is critical for a library that other programs depend on.

• [ ] Create .github/workflows/pull-request-account-compression-sdk.yml following the pattern of pull-request-js.yml
• [ ] Add npm install and npm test steps targeting account-compression/sdk
• [ ] Update CI to run linting (eslint) and type checking using account-compression/sdk/.eslintrc.js config
• [ ] Test the workflow by creating a test PR and verifying it catches regressions in the SDK

Add integration tests for concurrent-merkle-tree library with account-compression program

The concurrent-merkle-tree library (libraries/concurrent-merkle-tree) is a core dependency used by account-compression/programs/account-compression, but there are no visible integration tests verifying they work together. The canopy.rs and concurrent_tree_wrapper.rs files suggest complex merkle tree operations that would benefit from integration test coverage.

• [ ] Create account-compression/tests/integration directory with merkle_tree_integration.rs
• [ ] Write tests that instantiate ConcurrentMerkleTree, perform append/update operations, and verify state consistency
• [ ] Test edge cases like maximum tree depth, full trees, and concurrent modifications referenced in concurrent_tree_wrapper.rs
• [ ] Add integration test invocation to the pull-request-account-compression.yml workflow

Add TypeScript type definitions and SDK documentation for noop program

The noop program (account-compression/programs/noop/src/lib.rs) exists but has no corresponding SDK package or IDL, unlike the main account-compression program which has account-compression/sdk/idl/spl_account_compression.json. This makes it harder for developers to use the noop program from client code.

• [ ] Generate IDL from account-compression/programs/noop/src/lib.rs using anchor idl fetch or build
• [ ] Create account-compression/sdk/noop directory mirroring account-compression/sdk structure with package.json
• [ ] Add TypeScript client code for calling noop instruction with proper type safety
• [ ] Document the noop program's purpose in account-compression/programs/noop/README.md and add usage examples

• Add property-based tests (via proptest) to libraries/concurrent-merkle-tree for the canopy pruning logic in account-compression/programs/account-compression/src/canopy.rs—currently only unit tests exist.
• Expand TypeScript client test coverage for token-lending/cli and token-swap/program; currently many CLI commands lack integration tests against solana-test-validator.
• Document the concurrent merkle tree versioning and locking protocol in account-compression/programs/account-compression/src/concurrent_tree_wrapper.rs with inline examples—critical for contributors but not yet well-commented.

The solana-program-library repository is in an archived state as of March 2024, which is the most significant security concern. Active development and security maintenance have ended, and users are directed to program-specific repositories. While the existing codebase shows some security considerations (cryptographic dependency management, workspace structure), the archived status means no further security patches will be provided. The workspace lacks centralized security policies, comprehensive lint configurations for security, and visible automated vulnerability scanning. Organizations currently using this archived repository should prioritize migration to actively maintained program-specific repositories. For reference/fork purposes, consider adding modern security tooling and policies before production use.

• High · Repository in Archived State with Active Security Concerns — SECURITY.md, README.md. The repository is in archived/deprecated status as of 2024-03-02 with active development ended. This means security patches and updates may no longer be provided. The SECURITY.md explicitly states the repo is being archived and users are directed to individual program-specific repositories. Continued use of this archived codebase poses maintenance and security update risks. Fix: Migrate to the appropriate program-specific repositories under the solana-program organization. Update internal dependencies and references to use the actively maintained versions: associated-token-account, feature-proposal, memo, single-pool, stake-pool, token, or token-2022.
• High · Curve25519-Dalek SIMD Backend Performance Workaround — Cargo.toml [profile.dev.package.curve25519-dalek]. The Cargo.toml applies a workaround (opt-level = 3) for curve25519-dalek's slow SIMD backend performance. While this improves performance, it suggests the build environment may be optimized around a specific vulnerability or limitation rather than addressing root causes. This could mask underlying cryptographic implementation concerns or platform-specific issues. Fix: Document the specific performance issue and platform compatibility concerns. Consider updating curve25519-dalek to the latest version and re-evaluate if the workaround is still necessary. Ensure cryptographic operations are thoroughly tested across target platforms.
• Medium · Workspace Configuration Flexibility — Cargo.toml [workspace]. The workspace includes multiple member crates with varying security-critical nature (token programs, governance, lending). There is no visible centralized security policy or dependency management strategy documented in the provided configuration, which could lead to inconsistent security postures across different programs. Fix: Implement workspace-wide security policies including: mandatory security audits for cryptographic code, consistent dependency version management, shared security linting rules, and documented security review processes for high-risk programs (token-swap, token-lending, governance).
• Medium · Missing Workspace-Level Lint Configuration for Security — Cargo.toml [workspace.lints]. While the workspace defines lints for unexpected_cfgs, there are no visible workspace-level security-focused lints (e.g., for detecting unsafe code, unchecked arithmetic, or other security-critical patterns). This is especially critical for a library of Solana programs that may handle financial assets. Fix: Add workspace-level security lints including: forbid unsafe_code in non-essential crates, enable arithmetic-overflow checks, enforce bounds checking, and enable strict security-related warnings. Consider using cargo-deny for vulnerability scanning.
• Low · Version Lock File in Repository — Cargo.lock. Cargo.lock is committed to the repository. While appropriate for binary crates, this can sometimes lead to stale dependency versions if not regularly updated. For a library repo with multiple programs, this needs careful management. Fix: Ensure Cargo.lock is regularly updated through dependabot or similar automation. Document the dependency update policy. Consider implementing automated security scanning via tools like cargo-audit in CI/CD pipelines.
• Low · No Visible SBOM or Dependency Transparency — .github/dependabot.yml, Cargo.toml. While dependabot.yml is configured, there is no evidence of Software Bill of Materials (SBOM) generation or comprehensive dependency transparency mechanisms visible in the provided configuration. Fix: Implement SBOM generation in CI/CD pipelines using tools like cargo-sbom or syft. Publish SBOMs with releases to improve supply chain security visibility.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.