Why One Solana Token Needs Three Different Addresses

If you’re new to Solana, one of the most confusing things about SPL tokens is why a single token interaction can involve multiple addresses.
This post breaks down the difference between mint addresses, wallet addresses, and token accounts, and why understanding that distinction makes the Solana CLI suddenly start making sense.

When I first started working with SPL tokens, I kept running into the same problem. Every action seemed to require a different address. I wasn’t just dealing with “a token.”
I was dealing with a mint address, a wallet address and a token account address.
But the more I used the CLI, the more I realized something:

I wasn’t interacting with one system. I was interacting with three different responsibilities.

Where the Address Model Starts Becoming Important

What made things confusing was that different commands kept expecting different kinds of addresses.

spl-token create-token

This gives you a mint address.

Then I would move to:

spl-token create-account <MINT_ADDRESS>

Now I have a token account.

And finally:

spl-token transfer <MINT_ADDRESS> 100 <RECIPIENT_WALLET_ADDRESS>

This is where things started to feel inconsistent.

• Why is the mint address used here?
• Why is the wallet used here?
• And where exactly is the token actually stored?

The key idea I was missing

What helped everything click was this:

A wallet does not hold tokens on Solana.

That sounds simple, but it changes everything.
Because if wallets don’t hold tokens… then something else must. That “something else” is the token account.

The three-address model

Once I mapped everything properly, the system became much clearer.

1.Mint Address — the token identity

This is created when you run:

spl-token create-token

The mint defines what the token is, its rules and its supply. It doesn’t hold tokens, it defines the token itself.

2.Wallet Address — the owner identity

This is your actual account (keypair). It:

• signs transactions
• authorizes actions
• represents the user

But it does not store token balances, it only provides authority.

3.Token Account — the balance container

This is where things actually live.

Created using:

spl-token create-account <MINT_ADDRESS>

A token account stores:

• balance
• association to one mint
• ownership by a wallet

So the real structure is:

one wallet → many token accounts → one per mint relationship

Why balance requires BOTH wallet and mint

This was one of the most confusing parts for me:

spl-token balance --owner <WALLET_ADDRESS> <MINT_ADDRESS>

Why both?

Because:

• wallet = who owns the tokens
• mint = which token we are talking about

A wallet can hold:

• USDC
• custom tokens
• NFTs
• multiple SPL tokens

So the CLI needs both inputs to find the correct token account. Under the hood, it:

• derives the associated token account (ATA) for that wallet + mint pair
• then reads the balance from it

That’s why both are required.
Associated Token Accounts are derived automatically from a wallet + mint pair using Solana’s ATA standard.

Why transfers feel “indirect”

This command made more sense after understanding the model:

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

The key detail is:

tokens are not sent to wallets directly

They are sent to token accounts. So what actually happens is:

1. system checks if recipient has a token account for this mint
2. if not, --fund-recipient creates it
3. tokens are then transferred into that account

That’s why the wallet address is enough, but only because the system can derive the token account from it.

Token-2022 and programmable assets

One of the most interesting parts of this journey was Token-2022.

Unlike standard SPL tokens, Token-2022 introduces extensions that add behavior directly at the protocol level.
Solana’s Token Extensions documentation explains how these extensions allow tokens to enforce behavior directly at the protocol level.

Examples include transfer fees, non-transferable tokens, metadata extensions, custom rules enforced by the token program itself

What stood out to me is this:

These rules must be defined when the mint is created. They cannot be added later.

That changes how I think about tokens entirely. They are no longer just balances. They are programmable assets.

What actually changed for me

At first, the CLI felt inconsistent because I was thinking in terms of:

• “a token”
• “a wallet”
• “a transfer”

But Solana doesn’t structure it that way. Instead, it separates responsibilities:

• mint => defines what exists
• wallet => defines who controls actions
• token account => defines what is owned

Once I saw that pattern, the system stopped feeling fragmented. It started feeling intentional, even elegant.

The biggest shift for me was realizing this:

Solana doesn’t store tokens in wallets. It stores relationships between identities, assets, and balances.

Now that the address model finally makes sense to me, I’m starting to see Token-2022 less as “tokens with extra features” and more as programmable assets with rules built directly into the protocol.

I’m curious to see how far that model can go as the challenge continues.