Solana: SPL Token Program Architecture

The SPL Token Program is the foundation of fungible assets on Solana.

It defines how tokens are represented on-chain, how ownership is enforced, and how balances are created, transferred, and destroyed at runtime.

While most developers interact with SPL tokens through high-level SDKs, those abstractions hide important architectural details. Understanding the SPL Token program at the protocol level is essential for building reliable token flows, integrating with DeFi protocols, and debugging unexpected on-chain behavior.

This post provides a technical overview of the SPL Token program’s architecture. We’ll focus on how the program models state using accounts, how authority is enforced, and how common token operations are executed by the runtime.

In the next blogs, we’ll build on this to explore transfers, authorities and extensions.

How the SPL Token program represents

Tokens are on-chain constructs used to represent ownership and transferability of assets. Tokenization allows property rights and value to be expressed and enforced programmatically on a blockchain.

On Solana, tokens are implemented through the SPL (Solana Program Library) Token program.

This section introduces the core concepts behind how tokens are modeled and managed on Solana. For practical examples and code walkthroughs, refer to the SPL Token Basics section.

Concepts:

• Token programs define the instruction set and validation logic for creating, minting, transferring, and burning tokens on the network. The same program supports both fungible and non-fungible tokens.
• A Mint account represents a specific token type and stores global, token-wide state such as total supply, decimal precision, and mint authority (the address permitted to issue new tokens).
• A Token account represents ownership of tokens for a given mint and owner. It holds the balance and ownership metadata for that specific combination.
• An Associated Token Account (ATA) is a canonical Token account whose address is deterministically derived from the owner’s address and the mint address, ensuring a standard and predictable location for token balances.

All tokens on Solana are effectively data accounts owned by a Token Program.

Mint Account

On Solana, a token is uniquely defined by its Mint account address, which is owned by the SPL Token program. The Mint account represents the global state of a specific token and serves as the canonical source of truth for its configuration and supply.

The Mint account stores the following information:

• Supply: the total number of tokens that have been minted
• Decimals: the decimal precision used to represent fractional units
• Mint authority: the account permitted to mint new tokens and increase the total supply
• Freeze authority: the account permitted to freeze Token accounts, preventing transfers or burns

The full struct representation can be found here and looks like that:

pub struct Mint {
    pub mint_authority: COption<Pubkey>,
    pub supply: u64,
    pub decimals: u8,
    pub is_initialized: bool,
    pub freeze_authority: COption<Pubkey>,
}

For reference, here is a Solana Explorer link to the USDT Mint Account.

Token Account

To represent individual ownership, the Token program uses Token accounts. Each Token account is associated with a single Mint and is used to track the balance of that token for a specific owner.

A Token account stores the following information:

• Mint: the token type to which the account belongs
• Owner: the account authorized to transfer tokens from the Token account
• Amount: the number of token units currently held in the account

The full struct representation can be found here and looks like that:

pub struct Account {
    pub mint: Pubkey,
    pub owner: Pubkey,
    pub amount: u64,
    pub delegate: COption<Pubkey>,
    pub state: AccountState,
    pub is_native: COption<u64>,
    pub delegated_amount: u64,
    pub close_authority: COption<Pubkey>,
}

A wallet must have a dedicated Token account for each token (Mint) it intends to hold, with the wallet’s address set as the owner of that account. While a single wallet can control multiple Token accounts for the same Mint, each Token account is restricted to a single owner and can hold units of only one Mint.

Associated Token Account

Associated Token Accounts (ATAs) provide a standardized way to locate a Token account for a given Mint and owner. An ATA serves as the canonical, or default, Token account for a specific combination of owner and Mint.

In practice, An Associated Token Account is created at an address that is deterministically derived from the owner’s address and the Mint address. Functionally, an ATA is no different from any other Token account the distinction lies solely in how its address is derived.

This mechanism relies on a fundamental Solana concept: Program Derived Addresses (PDAs) that we learned here.

Cli examples

Configuring the Solana CLI for devnet

solana config set --url https://api.devnet.solana.com

Create a new keypair or use an existing one:

solana-keygen new

Verify your active configuration:

solana config get

it should look like this:

airdrop to your created account some SOL

solana airdrop 1

you should see output like this:

Install SPL CLI:

cargo install spl-token-cli

Run this to verify that it is installed successfully:

spl-token --version
// The output will look like:
// spl-token-cli 5.4.0

Creating a new token mint

spl-token create-token
// To specify decimal precision explicitly:
// spl-token create-token --decimals 6

output:

Creating a token account

spl-token create-account <MINT_ADDRESS>

output:

Minting tokens

spl-token mint <MINT_ADDRESS> 1000

output:

Check balance

spl-token balance <MINT_ADDRESS>

output:

Transferring tokens

Automatically create the recipient’s associated token account if it does not exist:

spl-token transfer <MINT_ADDRESS> 100 <RECIPIENT_WALLET_ADDRESS> --fund-recipient

output:

Summary

This article covered the foundational architecture of the SPL Token program and how tokens are represented on Solana. We examined the roles of Mint accounts, Token accounts, and Associated Token Accounts, and how they work together to model token supply and ownership on-chain.

This understanding provides the basis for analyzing token transfers, authority management, and interactions with higher-level protocols. In the next part of the series, we’ll explore how the SPL Token program enforces these rules during instruction execution.

Learn more about Solana architecture from our articles

• Architecture & Parallel Transactions
• Account Model and Transactions
• Anchor Accounts: Seeds, Bumps, PDAs
• Instructions and Messages
• Transaction, Serialization, Signatures, Fees, and Runtime Execution
• Transactions, Messages & Address Lookup Tables

Reliable Solana RPC infrastructure

Getting started with Solana on Chainstack is fast and straightforward. Developers can deploy a reliable Solana node within seconds through an intuitive Console — no complex setup or hardware management required. 

Chainstack provides low-latency Solana RPC access and real-time gRPC data streaming via Yellowstone Geyser Plugin, ensuring seamless connectivity for building, testing, and scaling DeFi, analytics, and stablecoin infrastructure. With Solana low-latency endpoints powered by global infrastructure, you can achieve lightning-fast response times and consistent performance across regions. 

Start for free, connect your app to a Solana RPC endpoint, and experience how easy it is to build and scale on Solana with Chainstack – a trusted Solana RPC provider.