What Are SPL Tokens?

In brief

SPL refers to the Solana Program Library, and Solana documentation calls assets managed by its Token Programs SPL tokens. Two program IDs are central:

• Original Token Program: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
• Token Extensions Program / Token-2022: TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

The original Token Program is immutable and widely used. Token-2022 is a separate program that preserves the original instruction layouts for base functionality and adds extension data and instructions.

A token’s mint address identifies it. Human-readable names, symbols, and images are separate metadata, so a copied ticker does not make a fake mint genuine. SOL is the native asset represented as lamports on Solana accounts; wrapped SOL is represented through a Token Program account.

The shared-program model

On Ethereum, an ERC-20 token is usually its own contract, with holder balances inside that contract’s state. On Solana, many different mints use the same Token Program instruction logic. The program operates on data accounts passed to each instruction.

That produces three objects beginners often collapse:

1. Token Program — executable logic for operations such as initializing, minting, transferring, burning, approving a delegate, and freezing.
2. Mint account — shared state and identity for one token.
3. Token account — one account’s balance of one mint.

The mint and token accounts are data accounts whose runtime owner program is either the original Token Program or Token-2022. They are not independent custom programs.

What a mint account stores

The base mint state includes:

• supply as a raw u64 amount;
• decimals as a u8;
• optional mint authority;
• optional freeze authority;
• initialization state.

Decimals are set when the mint is initialized. They tell clients how to display raw integers: with six decimals, 1_000_000 base units represents one display unit. Decimals do not create floating-point balances, and two mints can use different values.

The mint authority can create additional units. If it is absent or permanently revoked, no further units can be minted through that authority. That does not mean supply can never fall: holders or authorized delegates can still burn units when the token’s rules allow it.

The freeze authority can freeze or thaw token accounts for that mint. If no freeze authority is configured, the base Token Program has no authority that can later freeze them. Token-2022 extensions can introduce other privileged behavior, so checking only these two base authorities is not a complete risk review.

What a token account stores

A base token account records:

• the mint whose units it can hold;
• the token authority in its internal owner field;
• the raw amount;
• an optional delegate and delegated amount;
• state such as initialized or frozen;
• optional close authority;
• wrapped-native information when applicable.

One token account can hold only one mint. One wallet authority can control multiple token accounts for the same mint and needs at least one token account for each distinct mint it holds.

Solana uses “owner” in two layers. At the runtime level, the Token Program owns the account data and is allowed to modify it. Inside that data, the token account’s owner field is the authority allowed to transfer tokens. Saying “the wallet owns the account” without naming the layer can be misleading.

Associated token accounts

An ATA is an ordinary token account at a conventionally derived program address. Its derivation includes:

• token-account owner address;
• Token Program ID;
• mint address.

Including the Token Program ID matters because original-Token and Token-2022 accounts use different owning programs. The same wallet and conceptual asset inputs do not imply one shared ATA across both programs.

An ATA is the default discoverable account, not the only account an owner may use. The Associated Token Account Program can create it, and another party can pay the account-creation lamports. Token accounts must be rent-exempt while on-chain, and closing an eligible token account returns its remaining lamports to the chosen destination.

Delegates are account-scoped

The base Token Program lets a token-account owner approve one delegate with a maximum delegated amount. The delegate can transfer or burn from that specific token account up to the authorized amount. A new approval replaces the existing delegate state for that account, and Revoke removes it.

This differs from ERC-20’s usual allowance mapping keyed by token owner and spender inside one token contract. The security concept is similar—both grant spend power—but the stored object and permission scope differ. A delegate on one Solana token account does not automatically control another token account owned by the same wallet.

Token-2022: compatible base, optional extensions

Token-2022 is a separate program and a strict superset of the original Token Program’s base instruction functionality. The first 82 bytes of a mint and first 165 bytes of a token account preserve the original base layouts; extension data follows them.

Extensions can add features such as transfer fees, transfer hooks, confidential transfers, metadata pointers, non-transferability, permanent delegates, default account state, or pausing. Extensions may live on the mint or token account. Most must be selected during initialization, and some combinations are incompatible.

Integrations must inspect the mint’s actual owner program and enabled extensions. A transfer-fee extension can change the amount received; a transfer hook can invoke additional program logic; a permanent delegate changes the authority model. “It uses SPL” is not enough to assume plain-transfer behavior.

Token-2022 is not a new coin and is not “Solana’s ERC-20 contract.” It is another shared Token Program using mint and token data accounts.

Fungible tokens and NFTs use the same base machinery

Both Token Programs can manage fungible and non-fungible assets. A classic Solana NFT commonly uses a mint with zero decimals and a supply of one, plus metadata supplied through another program or, for Token-2022, an optional metadata extension.

Supply one and zero decimals are conventions, not a complete enforcement of provenance, collection membership, metadata immutability, or royalties. The live NFTs article should remain the place for those topics.

SOL and wrapped SOL

Native SOL is lamports held directly in Solana accounts, not an SPL-token balance. Wrapped SOL (WSOL) is SOL held in a token account for a Token Program’s native mint. The token account tracks an amount corresponding to lamports above its rent-exempt reserve, and SyncNative updates that token amount after lamports are transferred in.

Closing an eligible WSOL account returns its lamports, effectively unwrapping. This is a same-chain representation for Token Program compatibility, not a bridge to another network.