← Solana Foundations

Basic · LESSON 04 OF 06

4. Accounts, mints, and token balances

By the end, you can distinguish a wallet address, a mint, and a token account.

In this lesson7 field notes · practice · sources · checkpoint
Relationship map: a mint and token program identify a token account; its program owner controls account data, while the internal owner or delegate authorizes token actions. Raw units use mint decimals for display.
Relationship map: a mint and token program identify a token account; its program owner controls account data, while the internal owner or delegate authorizes token actions. Raw units use mint decimals for display.Open full-size visual ↗
Read a text version of this diagram

The mint and selected token program identify the token definition. A token account points to exactly one mint and stores its raw amount, internal owner, optional delegate, and state. Its runtime owner program controls account-data changes; the stored owner or an approved delegate can authorize permitted token actions. Raw units are formatted using the mint’s decimals. A frozen account can retain a nonzero balance while transfers are blocked.

  1. TOKEN MINT + PROGRAM
  2. ONE-MINT TOKEN ACCOUNT
  3. PROGRAM OWNER
  4. OWNER / DELEGATE / STATE
  5. RAW UNITS + DECIMALS
FIELD NOTE 01

Read an account record precisely

A Solana account is found by its public address and contains lamports, data, an owning program ID, and other runtime fields. The address tells you which record you queried; it does not tell you which person may use every value in that record. Under runtime rules, the owning program may modify the account data and debit its lamports. A token account therefore shows the Token Program or Token Extension Program as its runtime owner, even when a learner’s wallet is recorded inside the token data as the authority for token actions. Do not shorten these separate facts to “the wallet owns it.” Name the address, program owner, and internal token authority separately when reading explorer or RPC output.

FIELD NOTE 02

Match a token account to its mint

A mint address identifies one token configuration, including its decimals, supply, and authorities. Each token account stores units for exactly one mint and records an internal authority. The account address is not the mint address, and one wallet can have token accounts for many mints. An associated token account (ATA) is the standard deterministic address derived from a wallet, mint, and token program; it is a convention that helps apps find a default account, not the only valid place for that wallet’s units. A separately created token account can also be valid. When identifying an asset, compare both the exact mint address and the token program. Symbols, names, logos, and search results are labels that can be copied and do not prove token identity.

FIELD NOTE 03

Separate data ownership from token authority

The token account’s stored owner is the authority that can authorize token operations such as transferring or delegating units. That is different from the runtime owner program, which controls modification of the account data. The stored owner may approve a delegate for a limited amount; a delegate can act only within the recorded allowance and does not become the account’s program owner or permanently replace its owner authority. Before deciding whether a person or program can move tokens, inspect the internal owner, any delegate and delegated amount, and the exact instruction being considered. A wallet’s ability to sign a message does not let it edit token-account bytes directly.

FIELD NOTE 04

Check state before calling a balance spendable

A token account can hold a nonzero amount while being frozen by an authorized freeze authority. The raw balance still exists, but a transfer from that account is blocked until an authorized thaw changes its state. Read the token-account state and the relevant mint authorities; a wallet display or explorer balance by itself does not prove that a token can currently move. Token-2022 can also add mint or account extensions that change requirements or behavior, so do not assume every token follows only the classic token-account rules. Inspect the extension state relevant to the operation or state that the behavior has not been checked.

FIELD NOTE 05

Follow a repeatable balance-inspection workflow

Start by recording the cluster and observation slot so another learner can reproduce the read. Identify the intended asset by mint address and token program, then locate token accounts for the wallet and that mint instead of assuming the ATA is the only account. For each matching account, record its address, runtime owner program, internal owner, delegate and allowance, state, and raw integer amount. Read decimals from the mint and calculate the display amount from the raw units. Keep the original values beside the formatted result so rounding does not hide a small balance. This workflow establishes what the selected RPC response reported at its context; it does not prove future transfer success, market value, or that a provider returned the newest possible view.

FIELD NOTE 06

Keep account funding and close refunds separate

Creating a token account requires a payer to fund its on-chain storage minimum and a transaction fee payer to cover the transaction fee; these roles can belong to different addresses, and either can differ from the token-account owner. Closing sends the account’s remaining lamports, including refundable storage funds, to the destination named by the close instruction. The original creation payer does not automatically receive them. To close an ordinary token account, its token balance must be zero; transfer or burn the units first. Wrapped SOL accounts are the exception and can close with a token balance to reclaim the underlying SOL. The token-account owner or a configured close authority must authorize the close and select the destination. Some Token-2022 extensions impose additional close checks.

FIELD NOTE 07

Convert raw units without losing precision

Token balances are stored as integer base units. Divide the raw amount by ten raised to the mint’s decimals to format it: 125 raw units with two decimals display as 1.25, and 2,500 units with three decimals display as 2.500. Read the mint’s decimals instead of assuming a scale, and avoid converting large integers through floating-point arithmetic when exact accounting matters. Keep the raw integer and the formatted value together in reports. Decimals explain presentation; they do not establish asset value, transferability, or identity. A reproducible balance record therefore keeps the cluster, mint, token program, token-account address, raw amount, decimals, authority fields, and account state together.

MAKE THE CONNECTION

A detail worth keeping.

Token account addresses are state containers; token mint addresses identify the token definition. Several token programs exist, so a complete identity includes the program as well as the mint. Applications should reject a lookalike token even when its symbol is identical. A delegate receives scoped authority without replacing the account owner; a frozen token account may have a visible balance that cannot be transferred.

Work through an example

With three decimals, 2,500 raw units are 2.500 display units. The raw integer is still authoritative. Account creation storage is funded by a payer who may differ from the token owner; closing sends the refundable lamports to the instruction’s specified destination, not automatically the original payer.

Create a balance report with the cluster and context slot, mint address and token program, token-account address, runtime owner program, internal owner, delegate and allowance, account state, raw integer amount, mint decimals, and display amount. Include one associated and one separately created token account for the same wallet and mint. Explain why both may be valid, why a frozen balance is not necessarily transferable, and how the account-creation payer differs from the close refund destination. Calculate 2,500 raw units with three decimals without discarding the raw value.

GUIDED PRACTICE · BASIC

Do the work, one step at a time.

Use fictional addresses and disposable test data. Do not enter a recovery phrase or private key. Most exercises work on paper or with a local test; only a lesson that clearly says “read-only Devnet” makes a public network request.

  1. Read the displayed mint and token program.
  2. Inspect mint decimals, owner authority, delegate, and account state.
  3. Compare the integer balance with its formatted display. Run the downloadable read-only workbook against a public Devnet mint and token account; record the program owner, internal authority, raw units, mint decimals, extension names, and context slot, then explain what each observation does and does not prove.
  4. Draw the wallet, mint, token account, program owner, owner authority, and delegate as separate nodes; label the field that supports each role.
  5. Mark the frozen state and trace the storage payer separately from the close instruction refund destination.

Before you move on, check your reasoning

  • Calculate 2,500 raw units using three mint decimals.
  • Name the token-account identity and authority fields you would verify before accepting a deposit.
  • Explain why a token ticker is not an address, and distinguish the account-creation payer from the close refund destination.

OPEN SELF-CHECK · UNGRADED

Pause and test your reasoning

A token account’s runtime owner is the Token Program, and its internal owner field names a wallet. Which statement is accurate?

  1. The Token Program owns the account data at runtime; the internal owner field identifies the token authority, subject to account state and applicable delegates.
  2. The wallet in the internal owner field is the runtime owner program.
  3. The account’s creator remains its only possible token authority forever.
Reveal one best answer and its explanation

One best answer: The Token Program owns the account data at runtime; the internal owner field identifies the token authority, subject to account state and applicable delegates.

Runtime ownership controls which program may modify account data. Token authority is a separate field interpreted by the token program; delegates and extensions can add scoped authority, and frozen state can restrict transfers.

Sources: Accounts · Create a Token Account

This practice is not scored, saved, or part of a certificate. Account-based lesson checkpoints and level exams remain separate.

Never enter a recovery phrase or private key into a learning site or lesson exercise.

DOWNLOADABLE DEVELOPER LAB · READ ONLY

Inspect a mint or token account on Devnet.

This Solana Kit workbook decodes public account data from the classic Token Program or Token-2022. Compare the account’s program owner with its internal token authority and delegate, inspect raw supply or balance fields, and see the RPC observation slot. The workbook has no wallet connection, signing, transaction submission, key loading, or Mainnet selector.

Download Builder workbook 01

Requires Node.js 20+. Unzip the package, run npm ci, then npm test. For a public Devnet read, use npm run inspect-token -- --mint <PUBLIC_MINT_ADDRESS> or npm run inspect-token -- --token-account <PUBLIC_TOKEN_ACCOUNT_ADDRESS>. Compare token-account amountRaw with the mint’s decimals. The public RPC may be unavailable or rate-limited.

READ THE SOURCE

Go deeper in the official docs

Reviewed on 2026-09-28. Protocol documentation can change; check the linked page’s current version as you use this material.

  1. Accounts ↗
  2. Create a Token Mint ↗
  3. Create a Token Account ↗
  4. Close a Token Account ↗
  5. Token Extensions ↗
  6. Official JavaScript SDK ↗

Report an issue with this lesson

OPEN LEARNING

Keep learning at your own pace.

This lesson, its guided practice, and all six course lessons are open to everyone. Account-based checkpoints, exams, and saved progress will open when free accounts are ready.

Continue to the next lesson ↗