I'm trying to mentally put together the relationship between the various types of accounts involved in SPL tokens according to the Solana Cookbook: The cookbook says:

This mint account is later used to mint tokens to a token account and create the initial supply.

Additionally Solana Token Creator docs say:

Creating a Solana token requires the following steps:

  • Creating a new Mint account

  • Creating an associated token account

  • Minting an amount of the token to the associated token account

  • Adding the token metadata to the mint account

My understanding is that this means:

  • Every Token mint has:

    • Mint account - used to mint tokens (but does not store tokens)
    • Token Account - where new tokens are created. Associated Token Accounts are the most common way of making token accounts.
  • Every user account has

    • A native Sol balance
    • 0 or more Associated token accounts (at lease one for every token type that belongs to this user account)

The documentation mentions that transferChecked() moves tokens between two token accounts, but doesn't state what those accounts would typically be.

I have guessed the following: after I have created tokens into the mint's token account, token are sent to users from the mint's token account (which may be an ATA) to the user's Token Account (which may also be an ATA).

Is this correct? Or are tokens minted directly to user's token accounts?


1 Answer 1


To answer your main question: no, that's not per se typical. Technically, you could create an ATA for a Mint account, but that comes with some considerations.

How SPL Tokens Work

Put simply, a Mint represents a token, and an associated token account is just a counter that stores a user's balance of that token.

You can think of it like a double-pointer with a counter (balance) value:

Associated token account:
     --- What mint (token) does this correspond?
     --- What wallet does this correspond to?
     --- Balance

Every token Mint is a Mint account - It stores basic data related to an SPL token mint. A Mint is an entity in and of itself.

Mint: The new token M

When you create a new Mint its supply is 0.
In the cookbook page you linked, that's done at the top with createMint(); the only number provided is decimals.

Associated token accounts (ATAs) store which mint account and which user account they are associated with, and simply keep a balance.
In your cookbook link, that's done with createAssociatedTokenAccount() using the public keys of Alice and the Mint.

ATA: Person P has X balance of mint M

It can get confusing when you "mint to" someone's ATA, but all "mint to" really means is:

Mint To: increment the balance of the ATA for person P of mint M by X

In the cookbook example you linked, notice the only associated token account we introduce (before the transfer example) is Alice's ATA. We then mint to her ATA using mintChecked().

Lastly, a transfer is similar to "mint to":

Transfer: Decrease Alice's ATA balance and increase Bob's ATA balance for mint M by X

Token supply is basically every ATA's balance of that token mint.

Using the Mint to Create an ATA

If you simply create an ATA for the Mint itself, like described above, it would look like this:

ATA: Person P has X balance of mint M   where P = M

Then you could use "mint to" just like above to mint tokens to that ATA.

However, the biggest thing to consider is: who owns the Mint account?

  • If the Mint is a generated keypair, for example, you'd have to keep that private key handy if you ever wanted to sign off on a transfer out of the Mint's ATA.
  • If your program owns the Mint, then your program can sign off on those transfers instead; but then anyone can conduct a transfer without certain safeguards in place.

This might be useful if you wanted to keep a certain supply of a token mint locked up in a "vault" so to speak. However, the typical practice is to create a new Mint and use a Mint Authority to dictate who can mint new tokens and when.

Hope that clears things up a bit.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.