Anchor SPL Token Program: Creating Mints, Token Accounts, and Transfer Instructions

Solana's token model has no concept of token balances inside wallets. They're separate accounts. Once you understand this, everything else clicks.

You've built a basic Solana program. You can flip a boolean, increment a counter, and maybe even manage a simple vault. Now you want to mint a token—your protocol's governance token, a meme coin, a stablecoin pegged to developer frustration. You reach for the SPL Token program, Anchor's spl_token crate, and immediately faceplant into a wall of AccountInfo structs, PDAs, and the soul-crushing error: Program failed to complete: account data too small. Your shiny new RTX 4090 is crying tears of silicon—it's trying to run Llama 3.1 70B alone, but you're stuck debugging account space allocation.

This guide is for the developer who knows a PDA from a program-derived address but gets tangled in the three-account dance of mints, token accounts, and authorities. We'll cut through the abstraction with runnable Anchor code, explain why associated token accounts exist, and show you how to transfer tokens without setting your compute budget on fire.

SPL Token Architecture: It's All Separate Accounts

Forget Ethereum. In Solana, a wallet (a keypair) doesn't "have" SOL or USDC. It owns accounts that have data and lamports. SOL lives in a "system program" account. Tokens follow the same model but are managed by the SPL Token program.

Three core account types govern everything:

1. Mint Account: Defines the token itself. It holds the metadata: supply, decimals, and the public keys of the mint and freeze authorities. It's the source of truth for "what is this token?" Creating a new token type means creating a new mint account.
2. Token Account: Holds the balance of a specific token for a specific owner. It stores: the mint it's associated with, the owner's public key, and the amount. One user will have a separate token account for USDC, another for BONK, and another for your token.
3. Owner: The wallet (or program) that controls the token account. The owner can delegate authority or transfer tokens. The mint and freeze authorities are separate concepts for controlling the mint itself.

This separation is why Solana can process 3,000–5,000 TPS in production (Solana Beach, 2025)—transactions can touch independent token accounts in parallel. The trade-off is complexity: you must create and manage these accounts explicitly.

Associated Token Account: The PDA That Solves Discovery

If a user needs a new token account for every mint, how do you find it? You could derive it from the owner and mint addresses. That's exactly what the Associated Token Account Program (ATA) does.

An ATA is a PDA derived from [owner_address, token_program_id, mint_address]. It's a canonical address. The get_associated_token_address function gives you the same address every time. This solves the discovery problem: "What is Alice's token account for the USDC mint?" There's one definitive answer.

Crucially, the ATA is owned by the Token program, and its address is a PDA of the ATA program. This design means you can create it via a CPI, guaranteeing it's the correct account. Always use ATAs in your protocols unless you have a specific reason not to (like a shared vault).

Creating a Mint in Anchor: initialize_mint2 and Constraints

Let's create a mint. In Anchor, you don't manually pack data. You define a struct with accounts and let the framework handle serialization. Here’s a minimal instruction to create a new mint with a fixed supply.

use anchor_lang::prelude::*;
use anchor_spl::token::{Mint, Token};

declare_id!("YourProgramIdHere");

#[program]
pub mod token_minter {
    use super::*;

    pub fn create_mint(ctx: Context<CreateMint>) -> Result<()> {
        // CPI to the token program's initialize_mint2 instruction.
        // This sets up the mint account we just created.
        anchor_spl::token::initialize_mint2(
            CpiContext::new(
                ctx.accounts.token_program.to_account_info(),
                anchor_spl::token::InitializeMint2 {
                    mint: ctx.accounts.mint.to_account_info(),
                    rent: ctx.accounts.rent.to_account_info(),
                },
            ),
            9, // Decimals
            &ctx.accounts.payer.key(), // Mint Authority
            Some(&ctx.accounts.payer.key()), // Freeze Authority (set to `None` if not needed)
        )?;

        msg!("Mint created successfully at: {}", ctx.accounts.mint.key());
        Ok(())
    }
}

#[derive(Accounts)]
pub struct CreateMint<'info> {
    /// CHECK: We are creating this account. The token program will initialize it.
    #[account(
        init,
        payer = payer,
        mint::decimals = 9,
        mint::authority = payer.key(),
        mint::freeze_authority = payer.key(),
    )]
    pub mint: Account<'info, Mint>,
    #[account(mut)]
    pub payer: Signer<'info>,
    pub rent: Sysvar<'info, Rent>,
    pub token_program: Program<'info, Token>,
    pub system_program: Program<'info, System>,
}

The #[account(init, ...)] macro does the heavy lifting: it allocates space for the mint account, pays the rent, and sets its owner to the token program. The constraints (mint::decimals, mint::authority) add the required data to the initialization instruction. If you get the size wrong, you'll hit the classic error: Program failed to complete: account data too small. The fix is to ensure you're using the correct account type (Account<'info, Mint>) which Anchor knows the size of, or if defining a custom account, recalculate space with 8 (discriminator) + size_of::<YourStruct>().

Minting Tokens: CPI Into the Token Program

A mint with zero supply is useless. To mint tokens, you perform a CPI to the token program's mint_to instruction. You need the mint account, the destination token account (where the tokens will go), and the mint authority (which must sign).

pub fn mint_tokens(ctx: Context<MintTokens>, amount: u64) -> Result<()> {
    // CPI to the token program to mint tokens to the destination ATA.
    anchor_spl::token::mint_to(
        CpiContext::new(
            ctx.accounts.token_program.to_account_info(),
            anchor_spl::token::MintTo {
                mint: ctx.accounts.mint.to_account_info(),
                to: ctx.accounts.destination.to_account_info(),
                authority: ctx.accounts.mint_authority.to_account_info(),
            },
        ),
        amount,
    )?;
    Ok(())
}

#[derive(Accounts)]
pub struct MintTokens<'info> {
    #[account(mut)]
    pub mint: Account<'info, Mint>,
    #[account(mut)]
    pub destination: Account<'info, TokenAccount>, // The recipient's ATA
    pub mint_authority: Signer<'info>, // Must be the key defined in the mint account
    pub token_program: Program<'info, Token>,
}

This CPI increases the mint's supply and credits the destination token account. The mint_authority signer check is enforced by the token program itself.

Transfer Instruction: Validating Ownership

Transferring between users is another CPI. The critical security check is ensuring the source token account's owner is the authority (the sender) and is a signer.

pub fn transfer_tokens(ctx: Context<TransferTokens>, amount: u64) -> Result<()> {
    anchor_spl::token::transfer(
        CpiContext::new(
            ctx.accounts.token_program.to_account_info(),
            anchor_spl::token::Transfer {
                from: ctx.accounts.source.to_account_info(),
                to: ctx.accounts.destination.to_account_info(),
                authority: ctx.accounts.authority.to_account_info(),
            },
        ),
        amount,
    )?;
    Ok(())
}

#[derive(Accounts)]
pub struct TransferTokens<'info> {
    #[account(mut)]
    pub source: Account<'info, TokenAccount>,
    #[account(mut)]
    pub destination: Account<'info, TokenAccount>,
    pub authority: Signer<'info>, // Must match source.owner
    pub token_program: Program<'info, Token>,
}

Anchor's Account<'info, TokenAccount> type validates the account is owned by the token program. However, verifying that authority.key() == source.owner is often done by the token program CPI. If you pre-validate it in your account struct for safety, you'd add a constraint: #[account(address = source.owner)] on the authority field.

Testing with Bankrun: Creating Mints and Token Accounts

Unit testing token logic requires a simulated environment. solana-bankrun is excellent for this. Let's write a test that creates a mint and an associated token account.

import { BankrunProvider } from '@anchor-library/bankrun';
import * as anchor from '@coral-xyz/anchor';
import { createMint, getAssociatedTokenAddressSync } from '@solana/spl-token';

describe('token_minter', () => {
  const provider = BankrunProvider.default();
  anchor.setProvider(provider);
  const program = anchor.workspace.TokenMinter;

  it('Creates a mint and mints tokens!', async () => {
    const payer = provider.wallet.payer;
    const mintKeypair = anchor.web3.Keypair.generate();

    // 1. Create the Mint Account
    await program.methods
      .createMint()
      .accounts({
        mint: mintKeypair.publicKey,
        payer: payer.publicKey,
      })
      .signers([mintKeypair])
      .rpc();

    // 2. Get the payer's ATA for the new mint
    const ata = getAssociatedTokenAddressSync(mintKeypair.publicKey, payer.publicKey);

    // 3. Create the ATA if it doesn't exist (often done client-side)
    // ... (CPI to create_associated_token_account or use @solana/spl-token)

    // 4. Mint tokens to the ATA
    await program.methods
      .mintTokens(new anchor.BN(1000 * 10 ** 9)) // 1000 tokens with 9 decimals
      .accounts({
        mint: mintKeypair.publicKey,
        destination: ata,
        mintAuthority: payer.publicKey,
      })
      .rpc();
  });
});

Testing with Bankrun is faster than solana-test-validator and integrates into CI/CD. If your test fails with Transaction simulation failed: Blockhash not found, the fix is to ensure your testing framework fetches a fresh blockhash before every transaction. Bankrun handles this, but raw @solana/web3.js tests need explicit connection.getLatestBlockhash().

Freeze Authority and Burn: Advanced Controls

For protocol tokens, you need more control than simple transfers.

• Freeze Authority: An address (can be a PDA) that can freeze token accounts for a specific mint. A frozen account cannot transfer, mint to, or burn from. Useful for compliance. Set it during initialize_mint2. A CPI to token::freeze_account requires this authority.
• Burn: Destroying tokens reduces the total supply. It's a CPI to token::burn, requiring the token account owner's signature. Useful for buy-and-burn mechanics.

When implementing these, you'll likely bump into compute limits. An SPL token transfer uses ~5,000 compute units, but a transaction with multiple CPIs (create ATA, mint, transfer) can hit the default 200,000 limit. The fix: exceeded CU limit (200,000 default) — add ComputeBudgetProgram.setComputeUnitLimit(400_000) instruction at the start of your transaction, and profile with solana-test-validator --log.

Performance & Cost Reality Check

Why go through this complexity? The numbers justify it.

With Solana DeFi TVL at $12B in Q1 2026 and Jupiter handling $2B daily volume, the infrastructure is proven. Over 2,000 Anchor programs are on mainnet because the framework tames this account complexity.

Next Steps: From Mint to Protocol

You've created a mint, understood ATAs, and transferred tokens. Where next?

1. Make the Mint Authority a PDA: Your program should control the mint, not a developer wallet. Change the mint::authority to a PDA derived from your program ID in the CreateMint instruction. Then, only your program can sign for mint_to.
2. Integrate with Jupiter SDK: For any swap functionality, don't build your own AMM. Use the Jupiter SDK for on-chain routing. It's how the big players achieve that $2B daily volume.
3. Profile with Real RPCs: Move from public RPCs to a dedicated endpoint like Helius for 45ms p50 latency. Your bot or frontend needs the reliability.
4. Explore Token Extensions: For enterprise-grade features (transfer hooks, confidential transfers), dive into the Token-2022 program. It's the next evolution of SPL tokens.

The mental shift from "balances in a wallet" to "token accounts owned by a program" is the final boss of early Solana development. Beat it, and you unlock the ability to build protocols that are not just feasible but radically efficient, leveraging a chain that charges fractions of a cent to move value. Now go mint something.