DEV Community: Elizabeth Afolabi

Why One Solana Token Needs Three Different Addresses

Elizabeth Afolabi — Sun, 24 May 2026 12:06:08 +0000

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:

system checks if recipient has a token account for this mint
if not, --fund-recipient creates it
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.

Understanding Solana’s Account Model From a Web2 Perspective

Elizabeth Afolabi — Tue, 19 May 2026 22:27:50 +0000

In a previous article I posted on my #100daysofsolana journey, I wrote about how everything on Solana is an account. I spoke briefly about the difference between wallet accounts and program accounts. You can read the article here

In this article, we will go more in depth because I now have more knowledge after inspecting various accounts over the past few days.

Everything is an account. But not all accounts are the same

Unlike Ethereum, which separates wallet accounts from smart contracts, Solana uses the same model for all accounts. They all have the same five fields, but what differs is the meaning and value of those fields.

The Account's Five Fields

Every account on the Solana network has these five fields. Here's what they actually mean:

1.Lamports
This is the field that carries information on how much the account holds. Solana stores balances in lamports.

1 SOL = 1 billion lamports.

Sometimes, depending on how you are viewing the account structure, this field shows up as Balance with the value in SOL. Just know it's showing the same thing in a more human readable format.

2.Data
The data field refers to the storage space the account occupies. In Web2, this is similar to a database entry. It is stored as a raw byte array.
For example, the Token Program's data field looks like this in the raw output:

0000: 02 00 00 00 27 f1 90 b1 e8 ca df f9 f8 fc 45 cb
0010: d3 af 98 b8 8e 5f ac 42 0d 97 dd 37 ce 71 4c 44

In a more readable format, it shows up as `Length: 36 (0x24) bytes.

Wallet accounts have an empty or zero data field because they are simple SOL holders. They don't store anything beyond a balance. But program accounts, token accounts, and NFTs all have data because they store state.

This is also where something important happens:
Programs on Solana don't store their own state inside themselves. A program's executable code lives in one account, and the data it reads or writes lives in completely separate accounts. So when you see a program account with only 36 bytes, that's not where the user balances are, those live in their own individual accounts that the program manages externally.

3.Owner
This field tells us which program controls and is able to modify the account. Wallet accounts are owned by the System Program. Program accounts are typically owned by the BPF Loader. Built-in system programs, like the System Program itself, are owned by the Native Loader.
Solana has a security model in place such that a program can only write to the accounts it owns.

4.Executable
This is a boolean field that returns true or false. It tells us whether the account has a set of instructions written in code that it can run.
Program accounts have executable: true because they run programmed instructions. Other accounts like wallets and token accounts have executable: false because they don't run code, they just hold state.

5.Rent Epoch
Solana has a rent system; a cost for storing data on-chain. The rent epoch field was originally designed to show when the next rent would be deducted from the balance. Currently, accounts have been made rent-exempt by being funded with enough SOL upfront, which made this field less important.

How to think about it as a Web2 developer

We can compare Solana's account model to how a React app makes calls to a backend REST API in Web2. Stay with me.

The Solana program is like a backend API, and accounts are the databases the API reads or writes to. The frontend sends a request, and the backend(the program), executes what changes need to happen. On Solana, that request is called a transaction. Just like a REST API hits a POST or PUT endpoint, a Solana transaction invokes a specific program instruction.

The main thing to remember is that neither system stores information inside the request handler. Instead, data is stored separately, in a database in Web2, or in accounts on Solana. These accounts are like rows in a database. Each one holds some information about the application, identified by a special key.

So when you look at a Solana account, you can think of it like a record in a database:

The public key is like the identifier for the record
The data field is the actual information in the record
The lamports field is like a balance or credit attached to the record
The owner field is the service that is allowed to make changes to the record

Solana's ownership rules

Like I mentioned earlier, in Solana only the owner of an account can modify it. This sounds straightforward, but let's drive it home from both a Web2 and Solana perspective.

Only the owner can modify an account, but anyone can credit it. Meaning anyone can send SOL to any account. This is the security model Solana enforces at the protocol level.

Just like in a REST API system, only the backend service that owns a database table is allowed to modify the rows. Other services can request to read the data, but they can't write to it unless they're authorized. Solana enforces the same idea, only the owner program is allowed to mutate the account's data.

So if a token account is owned by the Token Program, no other program can directly edit its balance. They must go through the Token Program's instructions, just like a frontend must go through the correct API endpoint instead of writing directly to the database.

What are rent exemptions?

I mentioned that recently, accounts have been made rent-exempt. What does that actually mean?

In Solana, every account is like data stored on-chain, and you have to pay some amount to keep it there. That's rent. For a basic account with no extra data, it's roughly 0.00089 SOL.
But it's not a fixed amount, it's calculated based on the size of the data an account holds using the rent calculation formula.

In older versions of the model, this rent was collected periodically. When an account didn't have enough lamports, the network would reclaim it.But now, instead of paying periodically, you just fund the account with enough SOL to meet the minimum balance threshold. That makes it permanently rent-exempt. The SOL isn't spent, it's held as a deposit. Close the account, and you get it back.

You can check the rent exemption amount two ways:

Using the RPC method: getMinimumBalanceForRentExemption

Or through the CLI:

solana rent <DATA_SIZE>

Conclusion

When I started this journey, fields like owner, executable, and rent epoch were a bit abstract to me. I was staring at output I couldn't read.

Now I can look at any account on Solana and tell you exactly what it is and what it does just from those five fields. That's the account model, and if you've followed along to this point, you can too.

Everything on Solana is an account. What differs is just the configuration. That's it. That's the whole foundation.
Once that lands, a lot of other Solana concepts start making sense on their own.

If you want to make it stick, don't just take my word for it. Run this yourself:

solana account $(solana adress)

Then try it on the Token Program, then the System Program. See the same five fields show up every time. That's the moment it clicks.

What Failed Transactions Taught Me About Solana

Elizabeth Afolabi — Mon, 11 May 2026 17:44:10 +0000

A few days ago, Solana transactions still felt abstract to me.

I understood the general idea:
sign a transaction -> send it to the network -> it gets processed.

But during this phase of the challenge, things started becoming more concrete.

Especially when I began inspecting transaction confirmations, experimenting with transfer tooling, and intentionally triggering failed transactions.

That’s when Solana stopped feeling like “crypto magic” and started feeling more like engineering.

My Initial Mental Model

At first, I thought of transactions almost like simple requests:

send SOL from A -> B

And that was basically it.

But after exploring transaction anatomy more deeply, I realized a Solana transaction is much more structured than that.

It’s:

a signed request
containing instructions
executed by programs
against accounts
processed by a distributed validator network

The official Solana transaction docs also helped clarify how signatures, instructions, and accounts are structured internally:
https://solana.com/docs/core/transactions

That mental shift changed how I started looking at the system.

One thing that made transactions easier to understand was comparing them to requests in traditional applications.

Not exactly the same, but close enough to create a mental bridge.

You construct a request, send it to a distributed network, wait for processing, and eventually receive confirmation back.

But unlike a normal API request:

transactions require signatures
they expire after some time
validators participate in confirming them
and failure can still cost money

Failed Transactions Changed My Perspective

I intentionally triggered an insufficient funds error expecting the transaction to simply reject without consequences.

Instead, I learned something important:

failed transactions can still consume fees.

That caught me off guard.

Even though the transfer failed, validators still processed the transaction and performed work, so fees were still deducted.

That completely changed how I thought about blockchain transactions.

In most frontend workflows, a failed action usually just returns an error.

Here, failure still has a cost.

And suddenly concepts like validation, simulation, balance checks and transaction design started feeling much more important.

Confirmation States Made More Sense Than I Expected

Another concept that stood out to me was transaction confirmation.

I learned that transactions move through stages like:

Processed
Confirmed
Finalized

At first, these looked like simple status labels.

But they actually represent increasing confidence from the network.

A validator first processes the transaction, then the network reaches supermajority agreement.

Then enough blocks are added afterward that reversal becomes practically impossible.

I still don’t fully understand concepts like polling and finality yet, but this was the first time transaction processing started feeling like a real distributed system instead of just a black box.

One Detail That Really Stuck With Me

Another thing that genuinely surprised me was learning this:

Creating a wallet does not automatically create an on-chain account.

The address exists immediately because it’s derived from a keypair.

But the actual account only exists on-chain once it’s funded.

That distinction felt subtle at first, but it changed how I think about accounts on Solana.

Storage and state feel much more explicit here than I initially expected.

What Changed for Me

The more I explored transactions, the less Solana felt like “just sending crypto.”

It started feeling more like interacting with a distributed system with strict rules around state, validation, execution and confirmation.

I also became much more aware of the complexity underneath even simple transfers.

Before this, a transaction felt like:

click send and wait

Now I see:

validators processing requests
confirmation stages
execution rules
signatures
fees
and failure handling

all happening underneath something that initially looked simple.

I still don’t fully understand every part of the system yet, but transactions no longer feel abstract to me anymore.

And honestly, that’s probably the biggest shift from this week.

Day 16 of my 100 Days of Solana

Elizabeth Afolabi — Thu, 07 May 2026 02:11:51 +0000

Today I sent a SOL transfer on devnet and inspected the transaction on Solana Explorer.

One thing that really stood out to me was the

--allow-unfunded-recipient flag.

It helped me understand that on Solana, creating a wallet address does not automatically mean an on-chain account exists.

The address exists immediately after generating a keypair, but the actual account only exists once it’s funded.

So in this transaction, I wasn’t just sending SOL; the network was also creating the recipient account on-chain.

Very different from Ethereum’s “just send” model.

When “Wallet” Stopped Meaning Wallet - My Solana Journey.

Elizabeth Afolabi — Tue, 05 May 2026 13:07:20 +0000

I already had some exposure to Ethereum, so I thought I understood what a blockchain account was.

In my head, it was simple:
A decentralized version of a traditional account; no central authority, no company controlling it. You own it, you control it, end of story.

That mental model worked… until Day 11 of the 100daysofsolana.

What I Thought

I saw accounts like this:

Wallet = my personal account (stores and sends money)
Programs = shared logic (like smart contracts)

Even though I knew they were both “accounts,” I still treated them very differently.

Wallet felt like mine. Programs felt like tools.

What Changed

I started inspecting accounts directly using the CLI:

solana account <address>

That’s when things started to feel different.

I wasn’t just seeing balances anymore. I was seeing fields like:

owner
executable
data length And I had questions immediately.

The Confusing Part

Some accounts had:

executable: true
others had executable: false

So I started wondering:

Why can some accounts execute and others can’t?
What actually makes a program different from a wallet under the hood?

Then there was data length.

At first, I thought it had something to do with transactions… but it didn’t.
Now I understand it relates to how much storage space an account uses on-chain, but I’m still not fully clear on how it’s managed.

And then there’s rent.

Right now, my understanding is:

a cost for storing data on-chain

But I still didn’t fully understand:

how it’s calculated
when it is actually paid
what happens if an account can’t cover it

What I understand now

The biggest shift for me was this:

A wallet is not just a wallet. It’s an account with structure.

That structure includes:

who controls it (owner)
whether it can run code (executable)
how much data it stores (data length)

What helped things click further is realizing that “owner” doesn’t mean one thing in Solana.

There’s a difference between:

human ownership - who signs and authorizes transactions with a private key
program ownership - which program is allowed to modify the account’s data

So a wallet can be controlled by a user through signing, while still being governed at the protocol level by a program.

That separation made the system feel a lot more structured than I expected.

And suddenly, the line between “wallet” and “program” became thinner.

They’re not completely different things. They’re different types of accounts.

Finally

Day 11 didn’t give me full clarity, but it changed the way I look at the system.

I came in thinking in terms of wallets and smart contracts.

I left realizing it’s all just accounts with different rules, permissions, and structure layered on top.

That shift alone made everything I was seeing start to make more sense, even the parts I still don’t fully understand.

How Identity Works on Solana (vs Web2)

Elizabeth Afolabi — Sat, 02 May 2026 17:03:39 +0000

I recently joined the 100 Days of Solana challenge, and in the first few days I did some pretty basic things:

Generated a wallet
Funded it using devnet
Connected it to apps
Sent transactions

Sounds simple, right?

But it raised a bigger question for me:

If there’s no email/password… how does identity even work here?

If you're coming from Web2, this part can feel confusing at first. Let me break it down based on what I've learnt.

Web2 Identity (What We’re Used To)

In Web2, identity is straightforward:

You sign up with email + password
Your details are stored in a database
When you log in, the server verifies you
A session or token keeps you logged in

So basically, the server is responsible for knowing who you are.

The Shift: No Central Authority

On Solana, that model changes completely. The best way to think about it is:

Using a Solana wallet is like logging in with OAuth, except there’s no Google or Facebook verifying you. Identity is proven cryptographically by your wallet.

There’s no central server in charge of identity. Instead, identity is tied to your wallet.

Your Wallet = Your Identity

A wallet (like Phantom) is built on something called a keypair:

Public key - your wallet address (like a username)
Private key - used to approve actions (kept secret)

So when we say, “This is my identity on Solana”. What we really mean is “I control this wallet address.”

Signing = Authentication

This is the most important part. In Web2, you send your password to prove who you are
In Solana, you sign a message or transaction

Here’s what actually happens:

You interact with a dApp
The app asks your wallet to approve an action
Your wallet prompts you
You approve
Your wallet signs using your private key

That signature is the proof. You don’t log in with a password, you prove who you are by signing.

Also important:

Your private key is never exposed. It stays inside the wallet.
The password you enter in your wallet is not what proves it’s you, it only unlocks your wallet locally.

When you connect your wallet to an app, The app gets your public address. It never gets your private key.
That’s why wallet connections are considered secure.

A Real Flow (From My Experience)

Here’s a typical flow based on what I’ve been building:

I click “Connect Wallet”
My wallet (Phantom) asks me to approve
The app gets my public key
The app uses RPC to fetch my balance
I enter an amount to send
I click send
My wallet asks me to sign
I approve, transaction goes through

Where RPC Comes In

RPC (Remote Procedure Call) is just how apps talk to the blockchain. It fetches balances, sends transactions and reads data. It does not know who you are or manage identity. It just responds to requests.

So What Replaces Sessions?

In Web2, you log in once and session persists.

In Solana, there’s no real “session”. Your identity is simply your connected wallet. Your ability to sign when needed. If you disconnect, that’s it. No session stored somewhere.

Conclusion

At first, it feels strange not having a login system.

But once you understand this:

Identity = wallet
Authentication = signature

Everything starts to make sense.

If you're just getting into Solana like I am, this is one of the most important concepts to understand early.

It makes everything else easier.