Solana token creation explained, one account at a time
Creating a token on Solana is a short sequence of account writes, not a contract deployment. This note walks the sequence in the order a transaction actually performs it, shows what each instruction fixes permanently, works through the rent arithmetic that decides what creation costs, and marks the three points where the process stops being reversible.
- Question
- What sequence of instructions turns an empty keypair into a token that a wallet can hold and a pool can trade?
- Programs involved
- The System program allocates and funds the account. The SPL Token program or Token-2022 initialises and mints. The Associated Token Account program derives holder accounts. Metaplex Token Metadata attaches a name.
- Permanent here
- Decimals, the owning token program, any Token-2022 extensions, and later, if taken, the revocation of either authority.
- Not covered
- Liquidity pools, pricing, tokenomics advice, and anything that would make a token appear to have properties it does not have.
- Confidence
- High on program behaviour, which is public and checkable. Illustrative on cost, because priority fees and interface fees are outside the protocol.
Steps on this page that cannot be undone
- Decimals is written by the initialise-mint instruction and there is no instruction that changes it afterwards.
- A freeze authority can only be assigned at initialisation; if it is left empty it can never be added later.
- Revoking either authority by setting it to none is final and cannot be reversed by any key.
- The owning token program and any Token-2022 extensions are fixed when the account is allocated.
What creation actually is
Solana token creation is the allocation and initialisation of one small account. That account, the mint, stores the current supply, a decimals byte and two optional authority fields. No code is deployed, because the logic already exists in a shared program that every token of the same kind uses. Creating a token is filling in a form that the program then enforces.
This is the single most useful thing to understand before anything else, because it explains why tokens on Solana cannot differ in their transfer rules under the original program, why a token has no name until a second program is involved, and why several of the values you choose in the first minute can never be edited.
The accounts involved
Four kinds of account participate, and keeping them separate in your head prevents most of the confusion that follows. The mint is the token. Token accounts hold balances. The metadata account holds display information. The payer funds all of it and signs.
| Account | Owned by | What it stores | Size under SPL Token |
|---|---|---|---|
| Mint | SPL Token or Token-2022 | Supply, decimals, mint authority, freeze authority, an initialised flag | 82 bytes |
| Token account | SPL Token or Token-2022 | Mint reference, owner, amount, delegate, state, optional native and close authority fields | 165 bytes |
| Metadata account | Metaplex Token Metadata | Name, symbol, URI, update authority, mutable flag, creators and standard fields | Fixed allocation with padding |
| Payer wallet | System program | Lamports, which fund every rent deposit and every fee in the transaction | 0 bytes of data |
The word owner is used twice on Solana and means different things. A token account has an owner in the ordinary sense, the wallet allowed to move its balance. Every account also has a program owner, the only program permitted to modify its data. Your wallet does not own the mint in the second sense; the token program does, which is why every change goes through an instruction.
The instruction sequence
Here is the order a creation transaction actually performs, with the reason each step has to come where it does. Steps one and two are always present. Steps three and four are present whenever any supply exists at launch. Steps five and six are choices.
- Create the account. The System program allocates the byte length the mint needs, transfers enough lamports to make it rent-exempt, and assigns ownership to the token program. At this point the account exists and is completely blank.
- Initialise the mint. The token program writes the decimals value, the mint authority and, optionally, the freeze authority. This instruction can only run once. The values it writes for decimals and for the presence of a freeze authority are permanent.
- Create an associated token account. The Associated Token Account program derives a deterministic address from the wallet, the token program and the mint, then creates a 165-byte account there. The payer covers its rent-exempt deposit.
- Mint the initial supply. The mint authority signs a mint-to instruction naming that token account and a raw amount. Supply on the mint increases by exactly that number of raw units.
- Create the metadata account. The Metaplex program creates an account at an address derived from the mint, and writes the name, symbol and URI, along with an update authority and a mutable flag.
- Revoke what you intend to revoke. A set-authority instruction can clear the mint authority, the freeze authority, or both. Each clearance is one-way. Nothing in the token program can restore an authority that has been set to none.
Irreversible from step two onward
Decimals is fixed by step two and there is no later instruction to change it. The presence of a freeze authority is also fixed there: if the field is left empty at initialisation, no instruction exists to add one later. If it is set, it may be cleared once, permanently.
Step six is the other one-way door. Revoking an authority is normally the intended outcome, but it should be a decision rather than a habit, because the same instruction that fixes a supply also removes your ability to correct a mistake in it.
Rent exemption and what creation costs
Every Solana account must hold a minimum lamport balance proportional to its size, or it cannot persist. That minimum is called rent exemption, and it is a deposit rather than a fee: it stays in the account and is returned if the account is ever closed. Creation cost is therefore mostly deposits, plus a small, predictable transaction fee.
The arithmetic is public. Rent exemption is calculated over the data length plus a fixed 128-byte account overhead, multiplied by the lamports-per-byte-year rate and by a two-year exemption threshold. The general documentation for these mechanics is published in the Solana developer documentation, and any RPC endpoint will confirm a figure through its minimum-balance-for-rent-exemption method.
Worked arithmetic for a standard creation
One SOL is 1,000,000,000 lamports. The rate used for rent is 3,480 lamports per byte-year and the exemption threshold is two years, so the deposit for an account is (128 + data bytes) multiplied by 3,480 and then by 2.
For the 82-byte mint: (128 + 82) = 210 bytes, times 3,480, times 2, gives 1,461,600 lamports, or about 0.00146 SOL. For a 165-byte token account: (128 + 165) = 293 bytes, times 3,480, times 2, gives 2,039,280 lamports, or about 0.00204 SOL.
Add the base transaction fee of 5,000 lamports per signature. A single-signature transaction that creates a mint and one token account therefore deposits about 0.0035 SOL and pays 0.000005 SOL in base fees. Priority fees, the metadata account deposit and any interface fee sit on top of that and vary; those are the parts a published price is really made of.
Two consequences follow. First, protocol-level creation is cheap enough that cost is never a reason to skip a step. Second, the deposits scale with holders rather than with supply: every new wallet that receives the token needs its own 165-byte account, and someone pays for it. A token held by ten thousand wallets has ten thousand of those deposits sitting on chain.
Where balances live
A mint stores a total, never a list of holders. Balances live in token accounts, each of which references exactly one mint and one owner. A wallet holding five different tokens has five separate token accounts, and each of them was created and funded by somebody.
In practice almost all of these are associated token accounts. The Associated Token Account program derives a program address from three inputs, the owner wallet, the token program and the mint, so the location of any wallet's balance for any token is deterministic and needs no lookup. Anyone can create an associated token account for anyone else, which is how airdrops reach wallets that have never interacted with a token.
Two details are worth carrying. The rent deposit belongs to whoever paid it but is refunded to the owner when the account is closed, and closing is only possible at a zero balance. And an associated token account can be created for a mint that has a freeze authority, which means the account can later be frozen without its owner doing anything at all. The mechanics of that are covered on the authorities note.
Attaching a name
Under the original SPL Token program, described in the SPL Token documentation, the mint has no field for a name, a symbol or an image. Those live in a metadata account created by the Metaplex Token Metadata program at an address derived from the mint, which is why any interface can find a token's metadata knowing only the mint address.
What is stored on chain is short: a name limited to 32 bytes, a symbol limited to 10, and a URI limited to 200. The URI points at a JSON document, usually on a permanent storage network, that carries the description and the image link. The image itself is never on chain, so a token's picture depends on a server or network staying available. The Token Metadata documentation sets out the account layout in full.
The metadata account also carries an update authority and a mutable flag. While the flag is set and the authority exists, the name, symbol and URI can be rewritten at any time by that key, including long after people have bought the token. Whether to clear the flag is a real decision with costs both ways, and it has its own note on immutable versus updatable metadata.
Deciding what stays open
By the end of the sequence you hold up to three separate powers, and they are independent of each other. The mint authority can create supply. The freeze authority can freeze and thaw individual token accounts. The update authority can rewrite the displayed name, symbol and URI. Revoking one says nothing about the other two.
You can correct mistakes, mint a reserve you forgot, or respond to a situation you did not anticipate. For a token with a genuine ongoing issuance model, keeping the mint authority is not optional, it is the model.
The cost is that every holder is trusting the key. Supply figures become statements about the present rather than guarantees, and any custody failure of that key becomes a supply failure.
The field reads as none forever. Supply becomes arithmetic rather than a promise, and a reader can verify it in one query without knowing anything about the team.
The cost is that every mistake baked in before the revocation is permanent, including a wrong initial amount, and any future plan that required issuance is now impossible without launching a different token.
There is no correct answer, only a stated one. What this workshop objects to is not either choice but the presentation of a choice as something it is not: a live mint authority described as a fixed supply, or a revocation announced but never actually signed. Both are checkable in seconds by any reader, which is the subject of the field guide.
Choosing the token program
There are two token programs on Solana. The original SPL Token program is what most tools assume. Token-2022 is a separate program with a different address, offering optional extensions such as transfer fees, transfer hooks, confidential transfers, a permanent delegate, a default frozen state for new accounts and metadata stored inside the mint itself.
The choice is structural. It is made when the account is allocated, because extensions change how many bytes the mint needs, and a live token cannot be migrated from one program to the other. Extensions themselves must be enabled during creation for the same reason. The Token-2022 documentation lists the full set and the constraints on each.
Support is the practical constraint. Not every wallet, explorer, aggregator or pool implementation handles every extension, and some extensions deliberately change behaviour that other software assumes is fixed. A transfer hook can cause a transfer to fail under conditions defined by a third program. A permanent delegate can move or burn tokens from any account indefinitely. Those are legitimate features for some designs and disqualifying for others, and either way a reader deserves to see them listed rather than discovered.
A pre-launch checklist
Run this before signing anything, on a test cluster first. Every item corresponds to a field that is either permanent or awkward to change once other people are involved.
- Decide decimals deliberately and write down the reason. It cannot be changed and it silently sets the granularity of every future amount.
- Decide whether a freeze authority will ever be wanted, because that decision only exists at initialisation.
- Decide the token program before allocation, and if it is Token-2022, decide the extension set in the same breath.
- Confirm the initial mint amount in raw units, not in display units, and check it against ten to the power of decimals.
- Decide whether the mint authority will be revoked, when, and who signs it. Announcing it and not doing it is worse than not announcing it.
- Create the metadata account before distribution rather than after, so holders are not looking at an unnamed mint.
- Host the metadata JSON and the image somewhere that will outlive your interest in the project, and check the URI resolves.
- Verify the whole result on an explorer such as Solscan from a browser that is not signed in to anything, reading the fields rather than the summary badges.
What comes after that list is a different discipline entirely. Sizing liquidity, choosing venues and deciding how much market activity a new pair needs are commercial decisions with commercial tooling behind them; a Solana volume bot is one visible part of that layer, and it belongs to the market rather than to the mint.
What this note leaves out
It leaves out everything downstream of the token existing. Pool creation, initial pricing, liquidity provider tokens and their custody, listing mechanics and market behaviour are all separate systems with their own failure modes, and none of them is decided by the fields discussed above.
It also leaves out sizing. Deciding how much liquidity to seed, or reading a claim about how much volume a token needs to stay visible on aggregator screens, is a market question that no account field answers. The workshop mentions the boundary because plenty of construction decisions are made in anticipation of it, not because it endorses any particular approach to it.
Finally, it deliberately omits the reverse of everything here. There is no section on making a live mint authority look revoked, on presenting a supply that does not match the raw amount, or on structuring metadata so that a check returns a comforting answer. Every field described above is described so a reader can look it up, and that is the only direction this workshop writes in.
Questions the workshop is asked
Is creating a Solana token the same as deploying a smart contract?
No. Nothing is deployed. The SPL Token program already exists on the network and is shared by every token that uses it. Creating a token means allocating a small account, assigning it to that program and asking the program to initialise it with your chosen values. The behaviour of your token is the behaviour of the shared program, which is why two SPL tokens cannot differ in their transfer logic.
How many transactions does it take?
It can be one. Account allocation, initialisation, creating the first associated token account and minting the initial supply are separate instructions, but they fit comfortably inside a single transaction. Metadata creation is often bundled in as well. Interfaces sometimes split the work across two or three transactions for reliability, which changes the fee count but not the result.
What does it cost to create a token?
The unavoidable part is rent exemption on the accounts you create plus the base transaction fee of 5,000 lamports per signature. The mint is 82 bytes and each token account is 165 bytes under the original token program, so both deposits are fractions of a hundredth of a SOL. Anything charged above that comes from the interface you used, not from the protocol.
Can I get the rent deposit back?
Partly. A token account can be closed by its owner once its balance is zero, and the rent-exempt lamports are returned. A mint under the original SPL Token program cannot be closed at all, so that deposit stays locked forever. Token-2022 adds an optional mint close authority, which is one of the few extensions that changes this.
Do I have to set a maximum supply?
There is no maximum supply field. The mint stores the amount currently in existence and nothing else. A fixed supply is produced by minting the amount you want and then setting the mint authority to none, which is an irreversible action. Until that happens, any supply figure is a snapshot rather than a cap.
Why does my token show no name in a wallet?
Because a name is not part of a mint under the original token program. It lives in a separate metadata account derived from the mint address, created by the Metaplex Token Metadata program. If that account was never created, the token is valid and transferable but has nothing to display, and most interfaces will fall back to showing the address.
Does revoking the mint authority make a token safe?
It makes one specific thing impossible: creating more units. It says nothing about liquidity, about who holds the existing supply, about whether metadata can still be rewritten, or about a freeze authority that may still be live. Treating a single revoked field as a safety verdict is the most common reading error this workshop sees.
Filed on the Minting bench by The Forge Notes Desk. Field values, account sizes and instruction names are taken from the token programs and the metadata standard; any arithmetic in an example is labelled as illustrative and describes no particular token. The order this workshop checks a token in is set out in the field guide.