Make Immutable: Locking a Solana Token's Brand Forever
Solana has three different ways to lock a token forever: metadata, mint, and freeze. This guide explains which button to press, when, and what you give up.
Making a Solana token immutable is welding shut every key to its identity. There are three keys (the supply key, the freeze key, the display info key) and going immutable means throwing all three into the volcano at the same moment. Once they hit the lava, there is no recall, no spare copy, no reset button. That permanence is exactly why communities treat the action as the strongest possible trust signal a launcher can send. The trap is that most teams treat the three keys as one thing, throw them in the wrong order, and wake up inside a mistake that cannot be unmade.
What "immutable" actually means on Solana
Solana's token system holds three separate powers behind every token. The supply power (mint authority) creates new tokens out of nothing. The freeze power (freeze authority) can stop a specific wallet from moving its balance, useful in a hack-response situation. The display info power (update authority) controls the token's name, symbol, and logo URL; this one is stored inside the token's display info system rather than on the mint itself. Each power sits in its own slot. Each can be marked "empty" on its own. Once marked empty, no wallet, no explorer, no developer tool can put it back. Solana does not have an admin proxy pattern the way Ethereum does, so there is no upgrade hatch, no governance multisig, no clever workaround.
The question "is the token immutable?" therefore does not have one answer. A token with locked display info still has a live supply key, so the team can quietly mint another billion next week. A token with capped supply but mutable display info can be silently rebranded overnight. Locking all three together is the only state that freezes the token as a finished product.
Three different locks, three different outcomes
Here is what each j.tools action actually does, side by side. They look like cousins; the decisions behind them are very different.
| Action | What it locks | Fee | Right call when |
|---|---|---|---|
| the display info update tool for last fixes, then revoke separately | Display info (name, symbol, logo URL) | 0.1 SOL | Brand is final but you still need supply or freeze flexibility |
| the supply key revoke tool | Supply cap (no new tokens can ever be minted) | 0.1 SOL | Initial distribution is done and supply should freeze forever |
| the freeze key revoke tool | Ability to halt transfers from any wallet | 0.1 SOL | Decentralization signal, usually saved for last |
| the one-click immutable tool | All three keys, single atomic signature | 0.2 SOL | Maximum trust signal, you accept zero ops flexibility forever |
Make Immutable packs what would otherwise be three separate steps into a single signature. One click, three keys zeroed in the same block. Running them separately is also fine; the bundling does not save much fee. It saves the much more expensive thing, which is the chance of half-completing the lock and leaving a single door open that you forget about for three weeks.
No undo: Each of these three steps is one-way. After your signature lands on chain, no wallet, no oracle, no third-party tool will bring the key back. Try the same flow on devnet once before you do it on mainnet. It is not paranoia, it is the cheapest insurance you can buy on this network.
Order matters
There is a practical sequence here and most projects who get burned skipped one of the early steps. The common failure mode looks like this. A team locks the display info key before checking whether the logo actually rendered in Phantom and Solscan. The wallet displays "Unknown" forever, the logo never loads, nobody can fix it because the key is gone. Try this order instead:
- Confirm the logo, symbol, and social links render correctly in Phantom and on Solscan. Use the display info update tool for any last-minute corrections.
- Host the display info file on a permanent store, either Arweave or paid-pin IPFS. If your host goes offline, the token's name and logo go blank everywhere on chain.
- Revoke the display info key. Brand is now permanent.
- Finish the initial distribution: airdrops, liquidity pool seed, presale claims. Then revoke the supply key.
- Revoke the freeze key last. Freeze is the only emergency brake you have on Solana; if a wallet holding stolen funds shows up tomorrow, freeze is what lets you temporarily pause it. Some teams hold this one the longest for exactly that reason.
If you want all of it sealed in one motion, the one-click immutable tool handles the three revokes inside one signature. The catch: you still have to clear steps 1 and 2 before pressing it. Skipping the logo sanity check does not become safer because you bundled the lock; it becomes much worse, because now you cannot fix it.
Make Immutable: one button, three keys
The one-click immutable tool on j.tools wraps three separate steps into a single transaction. Phantom shows one pop-up. You sign once. When the transaction confirms, all three keys are gone in the same block: the supply key, the freeze key, the display info key. The flat fee is 0.2 SOL. Running the three revokes one at a time costs 0.3 SOL total, so the bundling saves you a tenth of a SOL. That is real, but it is not why you choose the bundled path. You choose it because the bundling removes the chance of forgetting one revoke and leaving an open back door behind a finished token.
For a launcher, the practical meaning is sharp: the moment the signature lands, the circulating supply is frozen at exactly what is out there, no wallet can ever be frozen by you again, and the name and logo are permanent. If your token becomes immutable, you can never mint an extra million tokens later, you can never change the logo, and you can never freeze a wallet that turns out to be holding stolen funds. That is the deal.
Is locking only some of the keys ever the right call?
Sometimes, yes. Two real scenarios:
Scenario A. A community-run memecoin. Holder count is past five thousand, distribution is long done, the liquidity pool is locked, the team is anonymous. Branding is final, there is no operational path forward that needs the supply or freeze key. Make Immutable here matches the message perfectly: maximum trust signal, because there really is nothing left to administer.
Scenario B. A game token where circulating supply grows over the next eighteen months through vesting unlocks. Marketing has a brand refresh planned for the holiday season. Here, revoking only the freeze key via the freeze key revoke tool early clears the centralization concern without breaking anything. The display info key and the supply key stay with the team because they both have real work left to do this year. Reaching for Make Immutable in this scenario quietly breaks the product roadmap.
When you are choosing, ask yourself one question. "In the next twelve months, will I need any of these keys to do my actual job?" If the answer is yes, do not throw that key into the volcano. A trust signal you bought by breaking your own roadmap is a trust signal you will burn through in a week of community questions you cannot answer.
Where the display info actually lives: When the display info key is revoked, the link your token points at is frozen forever, but the file that link points to has to stay reachable. A display info file hosted on a free Vercel project disappears the day your team forgets to renew the domain, and every explorer silently shows an empty name from then on. Use Arweave or pinned IPFS. Once you are immutable, this is the only thing keeping your token's identity alive long term.
Verifying the lock
Do not close the tab until you have confirmed the mint with your own eyes. The token snapshot tool pulls the mint details and shows all three slots empty in one screen, which gives you a clean output to share with the team. For the manual check, open the token's mint address on Solscan. The "Mint Authority" and "Freeze Authority" fields should both read "None". On the display info side, the "Is Mutable" row should read "false". When those three reads agree, the lock has taken.
One more step before you announce it. Open the link your token points at in a plain browser tab. The display info file should load, the logo URL inside it should resolve, and the JSON should not be a 404. If it is hosted on permanent storage, you are safe. If it turns out to be on a temporary host, you are too late to swap it, but you can still limit the damage by reducing circulating supply with the token burn tool or by launching cleanly on a new token. Better to know now than three months from now when the host disappears.
For more breakdowns of token mechanics and launcher decisions, browse the j.tools guides category or filter by Solana-tagged posts. If you are starting from scratch and want a clean key setup from day one, the j.tools token creator walks the whole flow before any of these locks come up, so you can choose what to keep and what to revoke at the moment of birth instead of patching it later.
When you are ready, sign the transaction. Just be sure the key you are giving up is one you genuinely will not need twelve months from now. On Solana, irreversible means actually irreversible, and the volcano does not give anything back.
