Mint authority and freeze authority, explained properly
A mint account carries two optional keys. One can create supply out of nothing for as long as it exists. The other can stop an individual holder from moving their balance. They are independent, they are read separately, and revoking either one is permanent. This note covers what each can actually do, how the revocation instruction behaves, and the readings people wrongly take from a field that says none.
- Question
- What powers survive a token launch, who holds them, and what does a revoked authority field actually guarantee?
- Fields involved
- mintAuthority and freezeAuthority on the mint account, both optional, both readable by anyone with the mint address.
- Permanent here
- Any revocation. Also the absence of a freeze authority at initialisation, which can never be reversed by adding one.
- Not covered
- Liquidity locks, pool ownership, team wallets, and any method of making an authority appear to be in a state it is not in.
- Confidence
- High. Both fields are stored in the mint and returned by any RPC or explorer, so every claim here is directly checkable.
Steps on this page that cannot be undone
- Setting the mint authority to none permanently ends the ability to create new units of the token.
- Setting the freeze authority to none permanently ends the ability to freeze or thaw any account for that mint.
- A mint initialised without a freeze authority can never have one added, under any later instruction.
- Token-2022 mint extensions that grant authority-like powers must be chosen at creation and cannot be removed by revocation alone.
The two keys in one paragraph
The mint authority is a key that may create new units of the token, without limit, for as long as the field holds a value. The freeze authority is a key that may freeze and thaw individual holder accounts for that token. They are stored in the same account, they are entirely independent, and either can be permanently removed by writing an empty value into its field.
Everything else in this note follows from those two sentences. The common errors are treating the two as one thing, treating a supply number as a cap while the mint authority is still live, and treating a revoked field as a general statement about a project rather than as the narrow technical fact that it is.
What the mint authority does
Mint-to is an instruction on the token program. It takes a mint, a destination token account and a raw amount, and it requires a signature from the key currently stored in the mint authority field. When it succeeds, the destination balance rises and the mint's supply field rises by the same number of raw units. Nothing is transferred; the units did not exist a moment earlier.
There is no ceiling. The mint account has a supply field and no maximum-supply field, so the program has nothing to compare a new mint against. Any statement that a token has a hard cap while the mint authority is live is a statement about intention, not about enforcement, and the difference is exactly the thing a reader needs to see.
The authority can also be transferred rather than revoked. Set-authority with a new key hands the power to a different address, which might be a multisig, a program-derived address controlled by a governance program, or another wallet. That is a meaningful improvement in custody and it is not the same as revocation: the power still exists and someone still has it.
Illustrative arithmetic on why the cap language matters
Suppose a token has 9 decimals and a displayed supply of 1,000,000. The raw supply is 1,000,000 multiplied by ten to the ninth, which is 1,000,000,000,000,000 raw units. A single mint-to instruction naming the same amount again would double the displayed supply in one transaction, costing the base fee of 5,000 lamports plus whatever priority fee is attached.
The point is not that this happens often. It is that the cost of doing it is a fraction of a cent and the only thing preventing it is the intention of a keyholder. These figures describe no particular token and are here to show the shape of the exposure.
What the freeze authority does
Freeze-account and thaw-account are instructions that change the state field on an individual token account. A frozen account cannot transfer out, cannot burn, and cannot be closed. Its balance is untouched and visible, and it becomes usable again the moment the same authority thaws it.
It is worth being precise about what this is not. The freeze authority cannot take tokens, cannot redirect them, and cannot pause the token globally in a single instruction: freezing is per account. It also cannot prevent an account from receiving tokens under the original token program. It is a hold, applied one holder at a time, by a key that anyone can read from the mint.
Legitimate reasons to hold one exist. Regulated issuers of asset-backed tokens frequently need the ability to freeze an account to comply with an order. Some ecosystems freeze accounts during a migration to prevent double-claiming. Those designs are real, and the honest position is that the power is dangerous in general and necessary in specific cases, which is why the field is optional rather than absent.
The asymmetry that catches people out
A freeze authority can only be assigned while the mint is being initialised. If the field is left empty at that moment, no later instruction can fill it, and the token is permanently incapable of freezing anyone. If it is set, it can be cleared once, and that clearance is permanent too.
So the field has three lifetimes and only two transitions: never existed, exists, and revoked. There is no path back from revoked, and no path forward from never existed.
How revocation actually works
Revocation is not a special instruction. It is set-authority, called with an authority type and an empty new-authority value, signed by the key that currently holds the authority being changed. The same instruction is used to hand the power to someone else, which is why reading a transaction as a revocation requires looking at the argument rather than at the instruction name.
Three properties of that instruction matter to a reader. It must be signed by the current authority, so nobody else can revoke on a project's behalf. It affects one authority type at a time, so revoking the mint authority leaves the freeze authority untouched. And it writes an empty option, which the program treats as final, because no code path in the token program writes a key into an empty authority field.
The behaviour is documented in the SPL Token program documentation, and it is identical in principle under Token-2022 for the equivalent fields. Reading the program documentation rather than an interface's description is worth the ten minutes, because interfaces routinely use one word, such as renounce or lock, for several different underlying actions.
Reading the four possible states
Because the two fields are independent, a mint is always in one of four states. The table below gives the plain reading of each, without any inference about the people involved, which is deliberate.
| Mint authority | Freeze authority | What is possible | Reasonable reading |
|---|---|---|---|
| Set | Set | Supply can grow at any time and any holder account can be frozen | Maximum ongoing control. Appropriate for a regulated issuer, alarming for a token presented as fixed and permissionless |
| Set | None | Supply can grow; no account can ever be frozen | An issuance model is still live. Any published cap is a promise, not an enforced limit |
| None | Set | Supply cannot grow; individual holders can still be frozen | The supply guarantee is real and the transfer guarantee is not. Frequently missed because attention stops at the first field |
| None | None | Neither power exists for anyone | Both guarantees are real and permanent. It says nothing whatever about liquidity, metadata, holders or conduct |
The third row is the one worth staring at. A reader who checks the mint authority, sees none, and stops there has verified half of the picture and will describe the token as safe on that basis. The two fields sit next to each other in every explorer view, and reading both takes no additional effort.
What a revoked field proves
A revoked mint authority proves that no new units of this token can be created by anyone, ever. That is a strong, permanent and verifiable guarantee, and it is the whole of what it proves.
It does not prove that the existing supply is distributed. It does not prove liquidity will stay in the pool, because pool tokens are a separate asset with separate custody. It does not prove the name and image cannot change, because metadata is a different account under a different program. It does not prove the absence of a freeze authority, and under Token-2022 it does not prove the absence of a permanent delegate.
Anyone routing sustained flow through a new pair has the same interest in these fields as a holder does. An operator configuring an automated Solana volume bot against a token whose mint authority is still live is trading against a float that can change underneath the campaign, which is a construction fact with a direct market consequence. That is the honest reason authority state gets checked outside the workshop as well as inside it.
Authority-like powers in Token-2022
Token-2022 adds optional mint extensions, several of which grant powers that are not visible in either classic authority field. Checking mintAuthority and freezeAuthority on a Token-2022 mint and stopping there is an incomplete read.
- Permanent delegate. An address permitted to transfer or burn tokens from any account for that mint, indefinitely. It is the strongest of the extensions and it is not removed by revoking either authority.
- Default account state. New token accounts can be created in a frozen state, meaning a holder must be thawed before they can transact at all.
- Transfer hook. Every transfer calls into a third-party program, which can cause transfers to fail under conditions defined outside the token program.
- Transfer fee. A configurable proportion of every transfer is withheld and later collected by a withdraw authority.
- Mint close authority. The mint account itself can be closed, which is impossible under the original token program.
- Non-transferable. The token cannot be moved once received, which is intentional for credentials and fatal for anything expected to trade.
The extension list for a mint is public and shown by explorers and by the Token-2022 documentation tooling. Extensions are not a warning sign in themselves; several of them exist to make regulated and enterprise use cases workable. They are a reason to read the mint fully rather than to read two fields.
When keeping an authority is right
Revocation has become a signal, and signals attract cargo-cult behaviour. There are designs where keeping a mint authority is not merely acceptable but required, and pretending otherwise pushes teams into revoking a power they will need and then launching a second token to get it back.
A token with ongoing issuance: staking rewards, an emission schedule, a redeemable claim on something off chain, or a stablecoin whose supply must track deposits.
A token in a migration window, where a mistake in the initial distribution still needs correcting and the holder set is small and informed.
In both cases the correct move is usually to transfer the authority to a multisig or a program, and to publish which one, rather than to leave it on a single hot key.
A token whose entire proposition is a fixed supply, where the authority has no future use and its presence only creates doubt that a reader has to resolve.
A token where the key is held by one person on one machine, which makes the power a liability regardless of intent, because a compromise becomes an unlimited mint.
In both cases revocation converts a promise into arithmetic, which is a genuine and permanent improvement in what a stranger can verify.
Custody is the other half
An authority that exists is only as safe as the key holding it, and the mint account records the address, not the arrangement behind it. A single wallet, a hardware wallet, a two-of-three multisig and a program-derived address all appear the same way in the field: as a public key.
That means a reader can see who holds the power but cannot see how well it is held. The useful practice for a project is to publish the arrangement and to make it checkable, for instance by pointing at a multisig whose members and threshold are visible on chain. The useful practice for a reader is to treat an unexplained authority address as a single key until shown otherwise, because that is the conservative assumption.
It also means transfer of authority is a moment worth watching. Set-authority to a new key is an ordinary transaction, and a token that moved its mint authority to a fresh address a week after launch has done something that its published description probably does not mention. Explorers show the transaction history of a mint, so this is observable rather than inferential.
What this note does not claim
It does not claim that any state is good or bad in general. The four states in the table have legitimate members, and the interpretation depends entirely on what the token claims to be. A stablecoin with no mint authority would be broken; a fixed-supply community token with one is under-specified.
It does not claim these fields are sufficient for a decision. They cover supply and account freezing. They do not cover liquidity custody, holder concentration, metadata mutability, or the extension set on a Token-2022 mint, and a reading that stops here is incomplete by construction.
And it does not, anywhere, describe how to make an authority state look different from what it is. There is no technique here for presenting a live authority as revoked, for timing a revocation to a screenshot, or for structuring a mint so that a check returns a comforting answer. Every field in this note is described so that a reader can look it up, which is the only use this workshop supports.
Questions the workshop is asked
What is mint authority in simple terms?
It is a public key stored in the mint account that is allowed to sign mint-to instructions. Whoever controls that key can create new units of the token at any time, in any amount, and send them anywhere. It is not limited by the current supply, by a cap, or by any schedule, because the mint account has no field for a cap or a schedule.
Can a revoked mint authority be restored?
No. The set-authority instruction writes an empty option into the field, and the token program has no path that writes a key back into an authority field once it is empty. This is by design: the guarantee is only worth something if it cannot be withdrawn. Anyone offering to restore it is describing something the program does not do.
What can a freeze authority actually do?
It can freeze and thaw individual token accounts for that mint. A frozen account cannot transfer, burn or be closed until it is thawed by the same authority. It does not seize balances, it does not move tokens, and it does not affect the mint itself. The effect is a hold placed on a specific holder rather than a global pause.
Why can a freeze authority not be added later?
Because the field is written by the initialise-mint instruction, which runs once, and no other instruction in the token program sets an authority that is currently empty. Set-authority changes or clears an existing authority; it does not create one from nothing. So a mint launched without a freeze authority is permanently free of that power.
Does a token with both authorities revoked have a fixed supply?
It has a supply that can no longer grow. It can still shrink, because holders can burn their own tokens, and the mint field will reflect that. So the accurate statement is that supply is capped at its current value and may decrease, not that it is frozen at a number forever.
Are these fields visible without technical tools?
Yes. Any public explorer displays both fields for a mint address, and any RPC endpoint returns them from a single account query. There is nothing privileged about the information. The only prerequisite is knowing the correct mint address, which is why the field guide on this site starts there rather than at the ticker.
Does revoking authorities make a token trustworthy?
It removes two specific powers and nothing else. Liquidity can still be withdrawn, metadata can still be rewritten if it is mutable, the existing supply can still be concentrated in a few accounts, and a Token-2022 extension can still grant powers that neither authority field describes. Trust is not a property that any single account field can carry.
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.