This repo still exists in archived form. Feel free to fork any reference implementations it still contains.
The Solana Program Library repository has been broken up into separate repos for each program and set of clients, under the solana-program organization.
The following programs have been moved:
- Associated-Token-Account
- Feature Proposal
- Instruction Padding
- Libraries
- Memo
- Record
- Single Pool
- Slashing
- Stake Pool
- Token
- Token-2022
- Token-Group
- Token-Metadata
- Token-2022 Transfer Hook
The governance programs have been moved to:
https://github.com/Mythic-Project/solana-program-library/tree/master/governance
The Solana Program Library, or SPL, is a collection of on-chain programs targeting the Sealevel parallel runtime.
These programs are tested against Solana's implementation of Sealevel,
solana-runtime, and some are deployed to Mainnet Beta. As others implement
Sealevel, patches are welcome to ensure the programs remain portable across all
implementations.
For more information, see:
Only a subset of programs from the original Solana Program Library repository were deployed to Solana Mainnet Beta.
For current deployment information, refer to the corresponding migrated program repository listed above.
Historically, this included programs such as:
| Program | Repository |
|---|---|
| Token | https://github.com/solana-program/token |
| Associated Token Account | https://github.com/solana-program/associated-token-account |
| Memo | https://github.com/solana-program/memo |
| Stake Pool | https://github.com/solana-program/stake-pool |
| Token-2022 | https://github.com/solana-program/token-2022 |
This archived repository contains, or formerly contained, protocol implementations for several core Solana application standards. The canonical specifications now live with the migrated program repositories.
At a high level, SPL programs follow these protocol design principles:
- Deterministic execution under the Sealevel runtime
- Explicit account ownership and signer validation
- Instruction-driven state transitions
- Rent-aware account initialization and closure
- Canonical serialization for program state
- Checked authority changes
- Explicit error handling through
ProgramErroror program-specific errors - Arithmetic safety for lamport, token, share, fee, and supply accounting
The SPL Token and Token-2022 programs define the standard interfaces for fungible token mints, token accounts, delegated spending, multisig authorities, minting, burning, freezing, and transfers.
Canonical repositories:
Core protocol concepts include:
- Mint accounts: define token supply, decimals, mint authority, and optional freeze authority.
- Token accounts: hold balances for a specific mint and owner.
- Associated token accounts: provide deterministic token-account addresses derived from wallet, token program, and mint.
- Delegates: allow approved third parties to transfer or burn a limited amount from a token account.
- Multisig authorities: allow authority actions to require multiple signatures.
- Extensions in Token-2022: add opt-in functionality while preserving the base token model where possible.
The Associated Token Account program defines a deterministic account derivation scheme for user token accounts.
Canonical repository:
Protocol invariant:
associated_token_address = PDA( wallet_address, token_program_id, mint_address, associated_token_program_id )
This allows wallets, dApps, and programs to discover the canonical token account for a wallet and mint without off-chain coordination.
The Memo program records arbitrary UTF-8 memo data in transaction instructions.
Canonical repository:
Typical use cases include:
- Exchange deposit references
- Payment notes
- Human-readable transaction annotations
- Application-level audit trails
The Stake Pool program enables pooled stake delegation. Users deposit stake or SOL into a pool and receive pool tokens representing a proportional claim on the pool.
Canonical repository:
Core protocol concepts include:
- Pool token mint
- Validator stake accounts
- Reserve stake account
- Deposit and withdrawal authorities
- Epoch-based validator stake updates
- Share-price calculations between pool tokens and underlying stake
The governance programs have moved to:
https://github.com/Mythic-Project/solana-program-library/tree/master/governance
Governance protocols generally define:
- Realms
- Governances
- Proposals
- Vote records
- Token-owner records
- Vote thresholds
- Instruction execution after proposal success
SPL programs are financial and protocol-critical systems. Many invariants depend on arithmetic over lamports, token amounts, pool shares, fees, collateral, interest, stake, slashing amounts, and supply values.
Release-style Rust builds SHOULD enable integer overflow checks at the workspace or crate profile level.
Recommended root Cargo.toml configuration:
[profile.release] overflow-checks = true
[profile.release.build-override] overflow-checks = true
[profile.bench] overflow-checks = true
If a root Cargo.toml already contains a [profile.release] section, merge the
following setting into it:
overflow-checks = true
By default, Rust checks integer overflow in debug builds but not in optimized release builds. In release builds without overflow checks, arithmetic can wrap silently.
For example:
let new_total = old_total + deposit_amount;
In a debug build, overflow causes a panic.
In a release build without overflow checks:
u64::MAX + 1 == 0
For on-chain programs, silent wrapping can break protocol invariants and cause:
- Incorrect token mint or burn accounting
- Incorrect lamport accounting
- Underpriced or overpriced pool shares
- Broken collateral ratios
- Fee miscalculation
- Supply corruption
- Bypassed limits
- Protocol insolvency
- Denial of service through corrupted state
Profile-level overflow checks are defense in depth. Protocol code should still use explicit checked arithmetic for all consensus-critical state transitions.
Recommended pattern:
let new_total = old_total .checked_add(deposit_amount) .ok_or(ProgramError::ArithmeticOverflow)?;
Other recommended operations include:
let remaining = balance .checked_sub(withdrawal_amount) .ok_or(ProgramError::ArithmeticOverflow)?;
let fee = amount .checked_mul(fee_numerator) .and_then(|value| value.checked_div(fee_denominator)) .ok_or(ProgramError::ArithmeticOverflow)?;
Enabling release overflow checks does not replace explicit checked math and does not fix a specific known exploit by itself. It removes an entire class of silent integer wrapping behavior from optimized builds.
For accounting-heavy programs such as token, lending, stake pool, swap, governance, and slashing systems, this is a meaningful protocol-level hardening measure.
Severity: Medium
Because this repository is archived and many packages have moved, prefer the build and test instructions in the relevant migrated repository.
For repositories that still use a Cargo workspace, validate release-mode behavior with:
cargo test --workspace --release cargo build --workspace --release
For Solana SBF builds, use the repository's existing Solana build flow, for example:
cargo build-sbf
or, depending on the local Solana toolchain:
cargo build-bpf
When maintaining forks or reference implementations from this archive, follow these guidelines:
- Validate every account owner.
- Validate every required signer.
- Validate PDA seeds and bumps.
- Validate account mutability requirements.
- Validate token mint and token account relationships.
- Use explicit checked arithmetic for all state-changing math.
- Avoid unchecked casts between integer widths.
- Prefer deterministic rounding rules for fees and share conversions.
- Document all rounding behavior.
- Reject invalid authority transitions.
- Protect initialization instructions from reinitialization.
- Verify rent-exemption requirements where applicable.
- Avoid relying on client-side validation for safety.
- Keep instruction data formats stable and versioned where possible.
- Add release-mode tests for arithmetic boundary conditions.
This repository is archived and no longer serves as the canonical home for most SPL program implementations.
For active development, issues, security fixes, and protocol changes, use the corresponding migrated repository under: