Only six programs that matter: a technical map of Solana's core primitives

In January 2025, Solana co-founder Anatoly Yakovenko (@toly) argued that useful smart contracts are far fewer than ecosystem discourse implies - roughly six major ones that matter - in a broader discussion of L2 design and developer optionality:

The figure six is rhetorical, not a published registry of program IDs. He later clarified the engineering claim: useful unique contracts are single-digit categories; useful variations are at most in the triple digits; the priority is a small set of immutable, well-audited primitives that compose into products.

This article maps that thesis onto the six program classes that absorb almost every serious Solana transaction: what they are, which program IDs you call, how their accounts work, and how the rest of the stack CPI's into them. Invocation share is cross-checked against ProgramWatch.

1. System Program: accounts and SOL

Program ID: 11111111111111111111111111111111

Every other program assumes the System Program exists. It owns the account lifecycle and native SOL (lamports). There is no "SOL mint" for the base asset: balances are the lamports field on accounts.

Instructions that matter in practice:

• CreateAccount / CreateAccountWithSeed - allocate space, fund rent-exempt lamports, assign an owner program ID
• Transfer - move lamports between accounts
• Assign / Allocate - change owner or resize (with constraints)
• AdvanceNonceAccount - durable nonces for offline or long-lived txs

use solana_program::system_instruction;

// Fund a new account owned by your program (size in bytes, rent-exempt lamports)
let ix = system_instruction::create_account(
    &payer,
    &new_account,
    rent_lamports,
    data_len as u64,
    &your_program_id,
);

Technical invariants worth internalizing: only the System Program can create accounts from nothing; only an account's owner can debit its data-bearing lamports (except pure lamport transfers from a signer); assigning ownership to a program is how you hand state to Token, your vault, or an AMM. On ProgramWatch's top list, System sits permanently in the top three because every ATA create and most program account inits CPI here.

2. SPL Token Program: the shared ledger

Program ID: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

This is the clearest illustration of the thesis versus Ethereum. On EVM, every ERC-20 is a new contract deploy. On Solana, one program implements the token machine; each asset is a mint account; each user balance is a token account owned by the Token program.

Core account types:

• Mint - supply, decimals, mint/freeze authority, fixed 82-byte layout
• Token account - mint, owner (wallet or PDA), amount, delegate, state (initialized / frozen)
• Multisig - M-of-N authority for mint or account ops

// Classic transfer: 3 accounts, amount in instruction data
// source (writable), destination (writable), authority (signer)
spl_token::instruction::transfer(
    &spl_token::ID,
    &source_ata,
    &dest_ata,
    &authority,
    &[],          // multisig signers if any
    amount,
)?;

Almost every DeFi program is a specialized robot that CPI's transfer, transfer_checked, mint_to, burn, or approve against this program. That is why Token routinely leads the invocation leaderboard by a wide margin: the network is not "running memecoins," it is rebalancing Token accounts under different policy programs.

Authority model to nail before you integrate anything: mint authority can inflate supply; freeze authority can lock accounts; account owner (or delegate) can move tokens. Upgradeable policy programs that hold mint authority are a different risk class than a frozen mint with revoked authorities. Check those fields on explorers and on ProgramWatch for the program that sits above the mint.

3. Associated Token Account Program: deterministic vaults

Program ID: ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL

Without ATA, wallets would invent ad-hoc token account addresses and every integration would be a directory service. The ATA program defines a canonical PDA per (wallet, token_program, mint) and an instruction to create it.

ATA = find_program_address(
  [wallet, token_program_id, mint],
  associated_token_program_id
)

import { getAssociatedTokenAddressSync, createAssociatedTokenAccountIdempotentInstruction } from "@solana/spl-token"

const ata = getAssociatedTokenAddressSync(mint, owner, true, TOKEN_PROGRAM_ID)
const ix = createAssociatedTokenAccountIdempotentInstruction(
  payer,   // pays rent
  ata,
  owner,   // ATA authority
  mint,
  TOKEN_PROGRAM_ID,
)

Internally the ATA program CPI's System (CreateAccount) and Token (InitializeAccount3). Prefer CreateIdempotent in clients so retries do not fail when the account already exists. Protocol vaults often use PDAs as the "wallet" seed so the vault's ATA is deterministic and the vault program can invoke_signed as owner.

This is program class three in the "six that matter" list because it is infrastructure for every wallet, every deposit, and every swap route. On invocation charts it is always near System and Token.

4. Token-2022: the same machine, with extensions

Program ID: TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

Token-2022 is not "a new token standard" in the ERC-20 clone sense. It is a second, extended implementation of the token program with a TLV (type-length-value) extension region on mints and accounts. Same conceptual objects (mint, token account), more optional fields.

Extensions that change integration math:

• Transfer fee - fee basis points deducted in-program; UIs must use fee-aware amount helpers
• Transfer hook - extra program CPI on every transfer (compliance, royalties, custom logic)
• Permanent delegate / default account state - institutional controls
• Metadata pointer / interest-bearing / confidential transfer - specialized asset types

// Wrong: assume classic Token program for every mint
// Right: read mint owner, pass the correct program id end-to-end
const mintInfo = await getMint(connection, mint, undefined, TOKEN_2022_PROGRAM_ID)
const ata = getAssociatedTokenAddressSync(
  mint,
  owner,
  true,
  TOKEN_2022_PROGRAM_ID,           // token program
  ASSOCIATED_TOKEN_PROGRAM_ID,
)

Failure mode we still see in production: a route builds instructions against Tokenkeg... for a mint owned by TokenzQd.... The runtime rejects the account owner check. Treat Token-2022 as its own program class in your account metas, ATA derivation, and CPI targets. For extension-level detail see Token-2022 extensions field guide and SPL Token vs Token-2022.

ProgramWatch has Token-2022 firmly in the top tier of daily invocations. It is no longer optional knowledge for anyone touching stablecoins, RWAs, or fee-on-transfer assets.

5. AMM and market programs: price discovery as a program

There is no single "the AMM program." There is a class: programs that custody two (or more) token accounts, enforce an invariant or book, and CPI Token to settle trades. Brands are variations. The class is what the scarcity thesis points at: few unique contract types, many product skins.

Patterns you will reverse-engineer on every serious DEX:

• Pool state account - mint pair, vault ATAs, fees, bump seeds, sometimes oracle config
• Vault ATAs - token accounts owned by a pool PDA
• Swap instruction - user source/dest ATAs, pool vaults, authority PDA, amount in / min out (slippage)
• Settlement - one or more Token transfer / transfer_checked CPIs, sometimes a separate fee program CPI

// Conceptual swap leg (every AMM rhymes with this)
user_source_ata  --Token::transfer-->  pool_vault_a
pool_vault_b     --Token::transfer-->  user_dest_ata
// pool PDA is the authority on vaults via invoke_signed

Concrete high-traffic examples (program IDs change by deployment; always resolve from docs or ProgramWatch):

• PumpSwap pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA - constant-product style AMM for graduated pump markets; often pairs with a fee program CPI
• Meteora DAMM v2 cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG - dynamic AMM family
• Jupiter Aggregator v6 JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4 - not an AMM itself; a router that CPI's into many market programs in one transaction

Order books (OpenBook-style, Phoenix spot, etc.) are the same class with different matching math: still custody + matching + Token settlement. Concentrated liquidity (CLMM) adds tick arrays and position NFTs or PDAs, but the settlement spine is still Token CPIs.

Integrator checklist for any market program: which Token program (classic vs 2022), who is vault authority, what is frozen vs upgradeable, is the build verified, is there an IDL on idl.solana.com, what is the slippage/oracle surface.

6. Conditional escrow: vaults, lending, perps, multisigs

The sixth class is the one people undercount because it wears many product skins. Almost every remaining high-value program is a conditional escrow: tokens move in, rules sit in program state, tokens move out only when predicates pass.

• Lending - deposit collateral, borrow against LTV, liquidate when health factor fails (Kamino-class, MarginFi-class, etc.)
• Perps / derivatives - margin escrow, funding, oracle marks, liquidation engines (e.g. Phoenix Perps EtrnLzgbS7nMMy5fbD42kXiUzGg8XQzJ972Xtk1cjWih as a high-invocation instance)
• Vaults / strategies - share mint, NAV rules, manager authorities
• Multisig / smart accounts - Squads-class: proposals, thresholds, execution CPIs as the multisig PDA
• Bonding curves / launch escrows - Pump.fun bonding curve 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P is escrow + pricing function + graduation handoff

// Pattern every escrow-style program shares
// 1. Derive vault PDA
// 2. Own vault ATAs (Token accounts owned by PDA)
// 3. User deposits: Token::transfer user -> vault (user signs)
// 4. User withdraws / liquidations: Token::transfer vault -> user
//    via invoke_signed with vault seeds
invoke_signed(
    &spl_token::instruction::transfer(
        &spl_token::ID,
        &vault_ata,
        &user_ata,
        &vault_pda,   // authority
        &[],
        amount,
    )?,
    accounts,
    &[&[b"vault", market.as_ref(), &[bump]]],
)?;

What differs between products is the predicate and the risk engine: interest indices, funding rates, oracle freshness, permission lists, M-of-N thresholds. What does not differ is the settlement layer: System for accounts, Token/Token-2022 for balances, ATAs for addresses, market programs for pricing when needed.

If you only learn one security habit for this class: map the authority graph. Who can upgrade the program? Who can change risk params? Who holds freeze/mint on related mints? A verified, frozen program with a Squads upgrade authority is a different object than a mutable program with a hot EOA upgrade key. That is the entire product surface of ProgramWatch.

How the six compose in one transaction

A typical swap-heavy transaction is not "one program." It is a stack:

ComputeBudget (set CU price/limit)
System          - maybe create ATA (via ATA program CPI)
ATA program     - create_idempotent user ATAs
Token / Token-2022 - approve or transfer legs
AMM / router    - swap, CPI Token into pool vaults
Optional fee / referral program CPI
Optional escrow program - deposit residual into vault

That composition is why Solana can keep the unique program count low while product count stays high: new products are often new clients and new CPI graphs, not new virtual machines. Cross-program invocation mechanics (account metas, invoke_signed, depth limits) are covered in Solana CPI.

What ProgramWatch shows about the thesis

Rank programs by invocations and the thesis looks less like rhetoric and more like a histogram:

• Classes 1-3 (System, Token, ATA) dominate because they are the settlement tax.
• Class 4 (Token-2022) is climbing into the same band as classic Token for modern assets.
• Class 5-6 (markets + escrows) is a short list of hot program IDs: a few AMMs, a router, a perps engine, a launch stack. Thousands of other deploys barely register.

Full annotated top ten: The 10 most-invoked Solana programs. The long tail of disposable bot programs does not contradict the scarcity claim; it supports the other half of it: infinite developer optionality that does not produce new primitives is noise.

If you write a program anyway

The non-bearish reading of the tweet is a filter for what is worth deploying:

1. Can you ship as a client over existing programs? Prefer that.
2. If not, are you introducing a new predicate or a new settlement path? If neither, you are a fork.
3. Publish an IDL, register a verified build, plan freeze or multisig upgrade authority, document authorities.
4. Optimize the hot path (CU, account layouts, Token-2022 correctness) rather than inventing a parallel token machine.

That is the engineering content of the claim: master the six classes above, compose them, and only then spend scarce audit surface on a seventh.

References

• Anatoly Yakovenko - only 6 major smart contracts that matter
• Anatoly Yakovenko - immutable primitives and composition
• ProgramWatch top programs
• idl.solana.com
• CPI mechanics, PDAs, Token-2022 extensions