Token accounts and ATAs: where Solana tokens are recorded

One mint describes the asset; holding accounts record quantities

A mint contains issuance-level information such as supply and decimals. A token account refers to that mint and records a quantity, holder authority and other applicable state.

Imagine Alice has one account holding 5 units of a token and another holding 7 units of the same mint. Her total holding is 12 units across those two accounts. A wallet can aggregate them, but a transfer instruction still acts on particular source accounts.

A token account holds one mint. Alice's USDC and another token therefore use separate holdings. Her ordinary wallet address identifies an authority and can receive native SOL; it is not a single token-account container with a separate column for every token.

This model explains why token discovery queries return a list of accounts. To build a complete view, validate each account's mint, authority and owning token program, then group compatible quantities as appropriate.

An ATA gives senders a predictable default

The Associated Token Program derives an address from the wallet authority, token program address and mint. This lets compatible applications agree where a default holding should be without asking the recipient to generate a new random account for every asset.

The derivation is a PDA under the Associated Token Program. After creation, the resulting holding account is owned at the base level by the relevant token program, with the intended wallet authority stored inside its data. Deriving program and base owning program are different concepts.

The token program belongs in the derivation. An application must choose the correct program for the mint rather than blindly using the original Token Program for every asset.

Calculating an ATA address does not create the account. A lookup can find that no state exists there yet. Creation is an additional network operation that allocates and initialises the expected account.

Someone funds and creates the holding account

A sender or application can create the recipient's ATA as part of a supported payment flow. The payer supplies the required lamports for account storage and pays the transaction's processing costs.

The payer is not automatically the token holder. For example, Alice can fund creation of Bob's ATA, with Bob as the token authority. Paying setup does not grant Alice the ability to spend Bob's received tokens.

Builders should use the account size and required minimum balance for the actual configuration. Token-2022 extensions can change required space and related setup. A historical fixed reserve for a simple account is not a universal quote.

For a first transfer, setup and token movement can share one transaction. On a later transfer, the holding may already exist and setup may be unnecessary. This is one reason two payments of the same token amount can have different total SOL requirements.

One wallet can hold a mint in several accounts

Handle an existing ATA without a creation race

Two users or workers can both observe that a destination ATA is missing and prepare creation. By the time the second request executes, the first may already have created it. A read-then-create check alone does not eliminate this race.

The Associated Token Program provides a supported idempotent creation path for this kind of construction. When the expected account already exists in the correct state, that path can handle it according to its contract. An incorrect existing account is not silently accepted as the intended holding.

Validate the resulting account's program, mint and authority. A builder needs those checks even if an address was deterministic. Deterministic location and correct current state are separate properties.

Do not solve a setup race by asking the user to send tokens to a guessed alternative address. The application's construction should match the recipient's supported route and the relevant program's account rules.

Multiple accounts affect sending and discovery

Return to Alice's 5-unit and 7-unit holdings. A wallet may display 12, while one selected source account can fund only 5. Sending 8 units can require selecting another source, consolidating or composing multiple supported actions.

The ATA is a default, not a complete list of every account that authority can control. Protocols, temporary workflows and older wallet activity can use other accounts. Querying only the ATA can undercount a holding.

When reading history, keep each source and destination account identity. A transfer between Alice's own accounts changes their individual balances while leaving her aggregate token quantity unchanged, apart from any applicable token-specific mechanics.

Portfolio displays should also keep token quantities separate from their market valuation. Grouping by a display ticker can accidentally combine unrelated mints.

Closing a holding changes storage, not the token’s mint

An ordinary token account generally needs its token amount emptied and its closure conditions satisfied before it can close. The authorised close operation sends remaining lamports to the chosen destination.

Closing one holding does not delete the mint or other users' holdings. A later supported payment can create an appropriate account again. Current lookup and historical evidence can therefore differ: an account visible in an earlier transaction may now be closed.

Wrapped-SOL accounts have special native-token closure behaviour. Read the wrapped-SOL guide rather than applying an ordinary token account's zero-balance rule to every native case.

A useful account inventory lists mint, token program, holding address, authority, amount and relevant extension or close state. That inventory supports both a correct balance view and a deliberate cleanup operation.

Common questions