✳ STONKBUILDER LEARNING PASSPORT
← Solana Foundations

Basic · LESSON 04 OF 08

4. Accounts, mints, and token balances

By the end, you can distinguish wallet, mint, and token-account roles, and explain token-2022 extension design constraints.

Look up Solana terms in the glossary

In this lesson8 field notes · practice · sources · checkpoint
Separate mint, program, and token authority; plan extensions early and include transfer-hook accounts. Frozen balances may be nonzero but cannot transfer; raw units use mint decimals.
Separate mint, program, and token authority; plan extensions early and include transfer-hook accounts. Frozen balances may be nonzero but cannot transfer; raw units use mint decimals.Open full-size visual ↗
Read a text version of this diagram

The mint and selected token program identify the token definition. Each token account belongs to one mint and stores raw amount, internal owner, delegate, and state; the runtime owner program controls its data. PermanentDelegate is mint-level and cannot be revoked by an individual account owner. Plan Token-2022 extensions before initialization: some cannot be added later and some combinations conflict. A transfer hook runs on every transfer and requires extra client accounts; missing accounts fail the transfer. Frozen accounts can retain a nonzero balance while transfers and burns are blocked. Mint decimals format raw units.

  1. TOKEN MINT + PROGRAM
  2. ONE-MINT TOKEN ACCOUNT
  3. PROGRAM OWNER
  4. OWNER / DELEGATE / MINT EXTENSION
  5. RAW UNITS + DECIMALS
The client checks mint extensions, resolves hook accounts, builds the transfer, and supplies them to Token-2022; missing accounts fail the transfer.
Plan and resolve a transfer-hook transaction. The client checks mint extensions, resolves hook accounts, builds the transfer, and supplies them to Token-2022; missing accounts fail the transfer.Open full-size visual ↗
Read a text version: Plan and resolve a transfer-hook transaction

The five lanes show a transfer-hook integration, not a real transaction. The client inspects the mint, resolves the current ExtraAccountMetaList into the accounts required by the hook, and builds the transfer with those accounts. Token-2022 invokes the configured hook program. The hook receives the original transfer accounts as read-only; the sender’s signer privilege does not propagate. Missing or incorrect required accounts make the transfer fail on-chain rather than silently bypassing the hook. Test the exact client flow in a safe environment before requesting a signature. This visual and its companion planner do not inspect chain state or prove wallet support.

  1. Check mint and required extension
  2. Resolve ExtraAccountMetaList
  3. Build transfer with required accounts
  4. Token-2022 invokes configured hook
  5. Valid supplied accounts pass · missing accounts fail
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 an ordinary delegate for a limited amount; that delegate can act only within the recorded allowance, and the owner can revoke it. Token-2022 also has an optional mint-level PermanentDelegate extension: its authority can transfer or burn tokens across accounts for that mint, and an individual token-account owner cannot revoke it. The mint authority can rotate the permanent delegate. Before deciding whether a person or program can move tokens, inspect the internal owner, any ordinary delegate and allowance, the mint extensions and permanent delegate, and the exact instruction and account state. 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 transfers, burns, and delegate changes are 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. In particular, a PermanentDelegate is a mint-level authority, not the account’s ordinary revocable delegate; it can authorize transfers or burns for accounts of that mint, while a frozen account still blocks those operations. Inspect the extension state relevant to the operation or state that the behavior has not been checked.

FIELD NOTE 05

Design Token-2022 extensions before creating the mint

Token-2022 extensions add behavior to a mint or its token accounts, but some choices must be made during initialization and generally cannot be added after the account is created. Some combinations are incompatible; for example, NonTransferable and TransferFeeConfig cannot be enabled together on the same mint. Turn the product requirements into an extension plan before creation, check each feature’s authority and account-level state, and test the exact combination. A transfer hook adds another integration requirement: every transfer invokes the configured hook program and needs its required extra accounts. A wallet or application that omits those accounts cannot transfer the token; the on-chain transfer fails instead of silently bypassing the hook. For a fictional allow-listed token, verify the mint’s hook program, resolve the current ExtraAccountMetaList, include the required accounts, and simulate the transfer before asking a user to sign. This inspection does not prove that every wallet or venue supports the token.

FIELD NOTE 06

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, ordinary delegate and delegated amount, state, and raw integer amount. Inspect the mint’s extensions separately, including whether it names a PermanentDelegate that the account owner cannot revoke. 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 07

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 08

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, ordinary delegate and allowance, mint extensions including any PermanentDelegate, 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, why an account owner cannot revoke a mint-level PermanentDelegate, 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. Then design a fictional Token-2022 mint for allow-listed transfers: identify which choices must be made before initialization, reject an incompatible NonTransferable plus TransferFeeConfig combination, and list the hook program and extra accounts a client must resolve before simulating a transfer. Extract Token Extension Planner Lab 01 and run the authority, incomplete hook, and conflicting JSON examples followed by its local Node test suite. Never mark checklist fields true without gathering the evidence they claim; the planner does not confirm on-chain state. Use no real wallet, funds, or private keys.

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.
  6. Use the interactive Token-2022 planner on this lesson to compare an incompatible extension pair with an incomplete transfer-hook plan. Then open Token Extension Planner Lab 01 for repeatable offline CLI tests: run the authority example, record the missing checks in the transfer-hook example, try the conflicting-extension example (exit code 1 is expected), and run `node --test token-extension-planner.test.mjs`. Both paths use fictional inputs and need no wallet, RPC, or SOL.

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

Practice 1 of 3

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 the answer and 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

Practice 2 of 3

A wallet holds two token accounts for the same mint. Where is each token quantity recorded?

  1. The mint stores every wallet balance in a separate mint-level field rather than in token accounts.
  2. Each token account stores its own amount.
  3. A wallet interface alone stores token quantities; on-chain token accounts contain no balances.
Reveal the answer and explanation

One best answer: Each token account stores its own amount.

Token accounts hold units for one mint and authority. The mint tracks properties such as supply and decimals, so inspect the matching token accounts to understand a wallet’s holdings.

Sources: Create a Token Mint · Create a Token Account

Practice 3 of 3

A token account is closed successfully. Which rule determines where its remaining lamports go?

  1. They always return to the creator.
  2. The original funder is automatically selected to receive all remaining lamports, irrespective of the close instruction.
  3. The validated close destination receives remaining lamports.
Reveal the answer and explanation

One best answer: The validated close destination receives remaining lamports.

Closing is an explicit state transition with a destination. Validate that destination and the account’s close conditions; do not infer a refund target from who originally paid.

Sources: Close a Token Account · Accounts

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-10-01. 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. SPL Token Basics ↗
  6. Permanent Delegate ↗
  7. Token Extensions ↗
  8. Transfer Hook Integration ↗
  9. Official JavaScript SDK ↗

Report an issue with this lesson

YOUR PROGRESS, SAVED

Ready for the checkpoint?

Make a free account to save your progress and unlock the quizzes.

Create free account